From report at bugs.python.org  Mon Nov  1 00:11:18 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 31 Oct 2010 23:11:18 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1288566678.68.0.614164140528.issue10254@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/issue10254>
_______________________________________

From report at bugs.python.org  Mon Nov  1 00:12:46 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 31 Oct 2010 23:12:46 +0000
Subject: [issue10263] "python -m site" does not print path details
In-Reply-To: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>
Message-ID: <1288566766.72.0.953372226026.issue10263@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

For me, python2.6 exhibits the same behavior as python2.7, using either Distribute 0.6.14 or 0.6.10 for both (this is on OS X with a stock framework build but that should not be significant). Perhaps you have a file permissions problem with your 2.6 site-packages or sys.path isn't what you expect?  Try adding a print in the distribute site.py to verify whether it is being executed at startup time.

----------

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

From report at bugs.python.org  Mon Nov  1 00:21:54 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 23:21:54 +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: <1288567314.87.0.829144467176.issue10242@psf.upfronthosting.co.za>


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

I'll fix this in 2.7.

For 3.2, may remove the method entirely (for the reasons discussed on python-dev).

----------
assignee: michael.foord -> rhettinger

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

From report at bugs.python.org  Mon Nov  1 01:00:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 00:00:41 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288569641.92.0.283107571638.issue7061@psf.upfronthosting.co.za>


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

?Python? is lower-cased only when referring to the executable (as a file) itself.  When talking about the language, the implementation or the VM in an abstract way (not a file), It think it?s always ?Python?.

----------

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

From report at bugs.python.org  Mon Nov  1 01:01:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 00:01:35 +0000
Subject: [issue775964] fix test_grp failing when NIS entries present
Message-ID: <1288569695.19.0.525305880351.issue775964@psf.upfronthosting.co.za>


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


----------
versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.3

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

From report at bugs.python.org  Mon Nov  1 01:02:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Nov 2010 00:02:10 +0000
Subject: [issue9977] TestCase.assertItemsEqual's description of differences
In-Reply-To: <1285704922.32.0.659854668668.issue9977@psf.upfronthosting.co.za>
Message-ID: <1288569730.09.0.531150812342.issue9977@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/issue9977>
_______________________________________

From report at bugs.python.org  Mon Nov  1 01:13:42 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Nov 2010 00:13:42 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>


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

* Dedocument assertSetEqual, assertDictEqual, assertListEqual, and assertTupleEqual.  These are all automatically dispatched from assertEqual.  The user need not call any of these directly.  These methods should not have been exposed in the docs.

* Add new names and dedocument old names for assertLess, assertLessEqual, assertGreater, assertGreaterEqual.   The new names are modeled after the gt, le, lt convention used elsewhere in the language.  This avoids to problems remembering the current spelling quirks (dropping the Than in LessEqual, pluralization, camel casing, being too long, etc).  New names will be assertLE, assertLT, assertGE, and assertGT.

* Add news names and dedocument assertRegexpMatches and assertNotRegexpMatches.  These names haves have multiple issues (they actually do a re.search not a re.match, they are long, the pluralization is inconsistent with the assertEqual convention, they don't agree with the names used in other unittest implementations such as PHPunit and Junit).  The new names will be assertRegexp and assertNotRegexp.

* Remove the assertItemsEqual method (which is new in 3.2).  Its semantics are not obvious from its name (i.e. duplicates matter, order does not matter, expects elements not items, has O(n**2) behavior after an impending bug fix, uses on equality for matching not hashing or ordering).  In most common cases, it is more explicit and flexible to use assertEqual after casting to a set, a list, or sorted list.  Also note that other unittest implementations such as PHPunit and JUnit do not have this method.  See http://mail.python.org/pipermail/python-dev/2010-October/105073.html 

* Recombine the package into a single file.  See http://mail.python.org/pipermail/python-dev/2010-October/105025.html and http://mail.python.org/pipermail/python-dev/2010-October/104887.html

* We need to review the camel cased spelling on two methods that are new in 3.2.  Should it be assertIsinstance or assertIsInstance?
 assert

----------
assignee: rhettinger
messages: 120100
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Clean-up Unittest API
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 01:15:16 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Nov 2010 00:15:16 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288570516.17.0.380727686507.issue10273@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti, michael.foord

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

From report at bugs.python.org  Mon Nov  1 01:18:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Nov 2010 00:18:10 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288570690.28.0.638277176384.issue10273@psf.upfronthosting.co.za>


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

I would prefer assertRegex to assertRegexp.

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

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

From report at bugs.python.org  Mon Nov  1 01:31:07 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Nov 2010 00:31:07 +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: <1288571467.02.0.410161462729.issue10242@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/issue10242>
_______________________________________

From report at bugs.python.org  Mon Nov  1 02:16:34 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 01 Nov 2010 01:16:34 +0000
Subject: [issue7059] 'checking getaddrinfo bug' doesn't output the result
	during ./configure
In-Reply-To: <1254703921.37.0.174838855875.issue7059@psf.upfronthosting.co.za>
Message-ID: <1288574194.61.0.58472903893.issue7059@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

The attached patch fixes output of `configure`.

----------
keywords: +patch
nosy: +Arfrever, benjamin.peterson
Added file: http://bugs.python.org/file19452/python-configure-getaddrinfo.patch

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

From report at bugs.python.org  Mon Nov  1 02:44:47 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Nov 2010 01:44:47 +0000
Subject: [issue7059] 'checking getaddrinfo bug' doesn't output the result
	during ./configure
In-Reply-To: <1254703921.37.0.174838855875.issue7059@psf.upfronthosting.co.za>
Message-ID: <1288575887.2.0.711630900341.issue7059@psf.upfronthosting.co.za>


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

r86075

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

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

From report at bugs.python.org  Mon Nov  1 03:52:17 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 01 Nov 2010 02:52:17 +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: <1288579937.65.0.456085172657.issue10242@psf.upfronthosting.co.za>


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


----------
assignee: rhettinger -> michael.foord

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

From report at bugs.python.org  Mon Nov  1 03:56:57 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 01 Nov 2010 02:56:57 +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: <1288580217.57.0.209916082582.issue10242@psf.upfronthosting.co.za>


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

As this has been released in 2.7 (and unittest2) I don't think it can be just removed in 3.2 - it would make porting code from Python 2 to 3 more painful. Very happy for you to fix in Python 2.7. Please let me know when it goes in so that I can keep unittest2 up to date.

----------
assignee: michael.foord -> rhettinger

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

From report at bugs.python.org  Mon Nov  1 04:13:21 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 01 Nov 2010 03:13:21 +0000
Subject: [issue10164] Add an assertBytesEqual to unittest and use it for bytes
	assertEqual
In-Reply-To: <1287665297.21.0.48545376383.issue10164@psf.upfronthosting.co.za>
Message-ID: <1288581201.09.0.360156829262.issue10164@psf.upfronthosting.co.za>


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

David - would you get a good approximation of what you want simply with:

    self.assertEqual(ascii(first), ascii(second))

(This actually returns "b'first'" "b'second'" so you may want a convenience function that chops the leading and trailing b'/')

As ascii returns unicode it would automatically delegate to assertMultilineEqual.

The obvious way to hook this up by default for assertEqual is having the split-character as '\n'. This would not be meaningful for using assertEqual to compare bytes that *aren't* text.

----------

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

From report at bugs.python.org  Mon Nov  1 04:32:34 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 01 Nov 2010 03:32:34 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288582354.76.0.203918274668.issue10273@psf.upfronthosting.co.za>


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

In general *none* of this should be done until there is clear consensus on Python-dev and it isn't clear that this is the case.

* On the deocumenting: barry warsaw objects to public apis that aren't documented and gregory smith asserts (natch) that it *can* be useful to call these methods directly for the explicit type checking they do. Let's see how this discussion pans out.

* For the greater / less comparison methods (etc) they would have to be new names as Python 2.7, 3.1 and unittest2 have the old names. This makes the TestCase even *bigger*. Let's see if we can get any consensus on this on Python-dev. Like Antoine I prefer assertRegex to assertRegexp.

* Note that assertItemsEqual is not new in 3.2 it is new in 2.7. If we remove it we make porting code using Python 2.7 (or earlier with unittest2) unnecessarily hard. The functionality is still useful but I agree that making the slow path more efficient would be good.

* Recombining the package into a single file *will not* happen without a BDFL pronouncement. unittest is massively easier to maintain now.

* Review the camel casing on assertIsInstance - isn't this just bike shedding?

----------
assignee: rhettinger -> michael.foord

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

From report at bugs.python.org  Mon Nov  1 04:45:45 2010
From: report at bugs.python.org (david)
Date: Mon, 01 Nov 2010 03:45:45 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1288583145.3.0.287732339061.issue1589@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

So I know the current patch doesn't support IP addresses but I thought I would link to what mozilla considered a security problem(just for future reference):

CVE-2010-3170: http://www.mozilla.org/security/announce/2010/mfsa2010-70.html

"Security researcher Richard Moore reported that when an SSL certificate was created with a common name containing a wildcard followed by a partial IP address a valid SSL connection could be established with a server whose IP address matched the wildcard range by browsing directly to the IP address. It is extremely unlikely that such a certificate would be issued by a Certificate Authority."

----------

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

From report at bugs.python.org  Mon Nov  1 04:55:33 2010
From: report at bugs.python.org (david)
Date: Mon, 01 Nov 2010 03:55:33 +0000
Subject: [issue10274] imaplib should provide a means to validate a remote
	server ssl certificate(s)
In-Reply-To: <1288583733.85.0.123923377362.issue10274@psf.upfronthosting.co.za>
Message-ID: <1288583733.85.0.123923377362.issue10274@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

imaplib should provide a means to validate a remote server ssl certificate(s).

So currently imaplib allows you to do the following:

import imaplib
conn = imaplib.IMAP4_SSL("imap.gmail.com")

#the following should fail
conn = imaplib.IMAP4_SSL("74.125.39.109")
conn = imaplib.IMAP4_SSL("i.broke.the.internet.and.all.i.got.was.this.t-shirt.phreedom.org",
443)
conn = imaplib.IMAP4_SSL("insert_self_signed_imap_server_here")
However, only the first call("imap.gmail.com") should *NOT* result in an error being raised (if the certificate is being checked :) ).

I wasn't able to find a way to get imaplib.IMAP4_SSL to take the certificate for the remote server without wanting a private cert (which wasn't / isn't desired ).

If an option is added / method added that takes in an optional parameter to validate the remote IMAP's ssl certificate has been signed by a trusted certificate authority this would be a good solution.

----------
components: None
messages: 120108
nosy: db
priority: normal
severity: normal
status: open
title: imaplib should provide a means to validate a remote server ssl certificate(s)
type: security
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 05:32:56 2010
From: report at bugs.python.org (py.user)
Date: Mon, 01 Nov 2010 04:32:56 +0000
Subject: [issue8555] tkinter doesn't see _tkinter
In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>
Message-ID: <1288585976.72.0.857364473898.issue8555@psf.upfronthosting.co.za>


Changes by py.user <port139 at yandex.ru>:


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

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

From report at bugs.python.org  Mon Nov  1 05:41:35 2010
From: report at bugs.python.org (py.user)
Date: Mon, 01 Nov 2010 04:41:35 +0000
Subject: [issue10275] how to know that a module is a module,
	a function is a function ?
In-Reply-To: <1288586495.6.0.985445158981.issue10275@psf.upfronthosting.co.za>
Message-ID: <1288586495.6.0.985445158981.issue10275@psf.upfronthosting.co.za>


New submission from py.user <port139 at yandex.ru>:

>>> import os
>>> m = os
>>> type(m)
<class 'module'>
>>> isinstance(m, module)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'module' is not defined
>>> n = 1
>>> type(n)
<class 'int'>
>>> isinstance(1, int)
True
>>>

----------
components: Interpreter Core
messages: 120109
nosy: py.user
priority: normal
severity: normal
status: open
title: how to know that a module is a module, a function is a function ?
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Mon Nov  1 05:45:53 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 01 Nov 2010 04:45:53 +0000
Subject: [issue10275] how to know that a module is a module,
	a function is a function ?
In-Reply-To: <1288586495.6.0.985445158981.issue10275@psf.upfronthosting.co.za>
Message-ID: <1288586753.09.0.190164565222.issue10275@psf.upfronthosting.co.za>


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

See the "types" module, specifically types.ModuleType. Compare that to your "type(os)" result.

This is not a support channel. Please see python-list for these types of questions.

----------
nosy: +brian.curtin
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Nov  1 05:46:13 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 01 Nov 2010 04:46:13 +0000
Subject: [issue8555] tkinter doesn't see _tkinter
In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>
Message-ID: <1288586773.42.0.190321274481.issue8555@psf.upfronthosting.co.za>


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

Not sure, why changed the resolution. It is an invalid bug report. You could have resolved it by a little research or by asking around.

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

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

From report at bugs.python.org  Mon Nov  1 09:30:16 2010
From: report at bugs.python.org (py.user)
Date: Mon, 01 Nov 2010 08:30:16 +0000
Subject: [issue8555] tkinter doesn't see _tkinter
In-Reply-To: <1272419255.64.0.530413038247.issue8555@psf.upfronthosting.co.za>
Message-ID: <1288600216.51.0.703885183499.issue8555@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

I thought this will put the topic from unresolved to resolved
Now I see this is for bugs only

----------

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

From report at bugs.python.org  Mon Nov  1 10:18:17 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Mon, 01 Nov 2010 09:18:17 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288603097.61.0.165840188122.issue10227@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I find it a lot easier to appreciate patches that implement a single change than those that mix different changes. There are three different things in your patch, which I would like to see in at least three different commits. I'd be happy if you could separate the changes into more readable feature patches. That makes it easier to accept them.

I'm generally happy about the slice changes, but you will have to benchmark the equivalent changes in Py3.2 to prove that they are similarly worth applying there.

----------
nosy: +scoder

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

From report at bugs.python.org  Mon Nov  1 10:46:05 2010
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 01 Nov 2010 09:46:05 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

zlib.crc32() and zlib.adler32() in Modules/zlibmodule.c don't handle buffers of >=4GB correctly. The length of a Py_buffer is of type Py_ssize_t, while the C zlib functions take length as an unsigned integer. This means that on a 64-bit build, the buffer length gets silently truncated to 32 bits, which results in incorrect output for large inputs.

Attached is a patch that fixes this by computing the checksum incrementally, using small-enough chunks of the buffer.

A better fix might be to have Modules/zlib/crc32.c use 64-bit lengths. I tried this, but I couldn't get it to work. It seems that if the system already has zlib installed, Python will link against the existing version instead of compiling its own.

Testing this might be a bit tricky. Allocating a 4+GB regular buffer isn't practical. Using a memory-mapped file would work, but I'm not sure having a unit test create a multi-gigabyte file is a great thing to do.

----------
components: Library (Lib)
files: zlib-checksum-truncation.diff
keywords: patch
messages: 120114
nosy: nvawda
priority: normal
severity: normal
status: open
title: zlib crc32/adler32 buffer length truncation (64-bit)
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19453/zlib-checksum-truncation.diff

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

From report at bugs.python.org  Mon Nov  1 10:51:05 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 01 Nov 2010 09:51:05 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288605065.1.0.992352753127.issue10227@psf.upfronthosting.co.za>


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

The benchmarks are from 3.2
Also, I'll do a more relevant profiling session for 3.2.  This patch is based on profiling results from 2.7 so there might be more relevant optimization cases in 3.2

----------

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

From report at bugs.python.org  Mon Nov  1 10:51:45 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Nov 2010 09:51:45 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <1288605105.64.0.416534470635.issue10276@psf.upfronthosting.co.za>


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

I find your approach fine; there isn't a need (IMO) to have the underlying functions change.

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

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

From report at bugs.python.org  Mon Nov  1 10:52:06 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 01 Nov 2010 09:52:06 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288605126.04.0.269916104105.issue10227@psf.upfronthosting.co.za>


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

In case I'm not clear enough:
The patch is for 3.2, the benchmarks are 3.2, but it was created based on 2.7 results, which may not fully apply for 3.2

----------

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

From report at bugs.python.org  Mon Nov  1 12:05:42 2010
From: report at bugs.python.org (Brian Brazil)
Date: Mon, 01 Nov 2010 11:05:42 +0000
Subject: [issue10277] sax leaks a fd if source is a filename
In-Reply-To: <1288609541.61.0.0926473508051.issue10277@psf.upfronthosting.co.za>
Message-ID: <1288609541.61.0.0926473508051.issue10277@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

If saxutils.prepare_input_source is passed a filename or url, it'll end up leaking an fd via IncrementalParser.parse and ExpatParser.parse. This can be seen by enabling resource warnings and running test_sax.

This should be fixed.

----------
components: Library (Lib)
messages: 120118
nosy: bbrazil
priority: normal
severity: normal
status: open
title: sax leaks a fd if source is a filename
versions: Python 3.3

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

From report at bugs.python.org  Mon Nov  1 12:10:55 2010
From: report at bugs.python.org (qpatata)
Date: Mon, 01 Nov 2010 11:10:55 +0000
Subject: [issue9919] gdbinit lineno result is one line in excess
In-Reply-To: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>
Message-ID: <1288609855.62.0.0201300444784.issue9919@psf.upfronthosting.co.za>


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

Hi,

Thanks for the fix.

I'm wondering if it is valid to add a "\n" in the "lineno" print. This macro is called by other ones, like pyframe, that have their own format specifiers.

Kind regards.

----------

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

From report at bugs.python.org  Mon Nov  1 13:12:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 01 Nov 2010 12:12:11 +0000
Subject: [issue9919] gdbinit lineno result is one line in excess
In-Reply-To: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>
Message-ID: <1288613531.61.0.0508761879535.issue9919@psf.upfronthosting.co.za>


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

If you look at the commit, you'll see that I already added that newline.  Thanks anyway :)

----------

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

From report at bugs.python.org  Mon Nov  1 13:46:30 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Nov 2010 12:46:30 +0000
Subject: [issue10277] sax leaks a fd if source is a filename
In-Reply-To: <1288609541.61.0.0926473508051.issue10277@psf.upfronthosting.co.za>
Message-ID: <1288615590.0.0.263038153377.issue10277@psf.upfronthosting.co.za>


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

It is now.

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

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

From report at bugs.python.org  Mon Nov  1 13:46:37 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 01 Nov 2010 12:46:37 +0000
Subject: [issue10277] sax leaks a fd if source is a filename
In-Reply-To: <1288609541.61.0.0926473508051.issue10277@psf.upfronthosting.co.za>
Message-ID: <1288615597.51.0.335262431788.issue10277@psf.upfronthosting.co.za>


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


----------
resolution: fixed -> out of date
status: pending -> closed

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

From report at bugs.python.org  Mon Nov  1 14:07:05 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Mon, 01 Nov 2010 13:07:05 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1288583145.3.0.287732339061.issue1589@psf.upfronthosting.co.za>
Message-ID: <4CCEBB70.9050303@kiilerich.com>


Mads Kiilerich <mads at kiilerich.com> added the comment:

> So I know the current patch doesn't support IP addresses

Not exactly. The committed patch do not consider IP addresses - 
especially not iPAddress entries in subjectAltName. But Python only 
distinguishes resolvable names from IP addresses at a very low level. At 
the ssl module level the name and IP is considered the same, so we 
actually do support IP addresses if specified in commonName or 
subjectAltName DNS. We are thus "vulnerable" to this issue. (AFAIK AFAICS)

(It seems like IP in commonName isn't permitted by the RFCs, but I think 
it is quite common, especially for self-signed certificates.)

> CVE-2010-3170: http://www.mozilla.org/security/announce/2010/mfsa2010-70.html

For reference, the actual report can be found on 
http://www.securityfocus.com/archive/1/513396

FWIW, I don't think it is critical at all. Granted, it is a deviation 
from the specification, and that is not good in a security critical 
part. But we do not claim to implement the full specification, so I 
don't think this deviation makes any difference.

Further, this issue will only have relevance if one the trusted CAs 
create invalid certificates. But if the trusted CAs create invalid 
certificates the user has lost anyway and things can't get much worse.

----------

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

From report at bugs.python.org  Mon Nov  1 14:13:21 2010
From: report at bugs.python.org (David Joy)
Date: Mon, 01 Nov 2010 13:13:21 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1227644194.32.0.230924221438.issue4431@psf.upfronthosting.co.za>
Message-ID: <1288617201.96.0.596169409449.issue4431@psf.upfronthosting.co.za>


David Joy <videan42 at gmail.com> added the comment:

Hi Marc,

Well, I fried my original server install trying to trace this.  My new fresh install can still reproduce the problem with mysql-python, but I can't recreate the issue with PyOpenSSL anymore.  Grabbing packages at random from PyPi hasn't given me a single issue so far, so I'm going to say this is an issue with mysql-python only and redirect my efforts there.

Thanks for your help,
-David

----------

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

From report at bugs.python.org  Mon Nov  1 14:21:50 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Nov 2010 13:21:50 +0000
Subject: [issue9796] Add summary tables for unittest API
In-Reply-To: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>
Message-ID: <1288617710.03.0.407109661236.issue9796@psf.upfronthosting.co.za>


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

The attached patch adds a table with the most common assert* methods and their explanation at the top of the doc.

There are however a few things that should imho be changed, but that will require some re-organization in the unittest doc:

1) now the table is on the third "screen" and it's necessary to scroll down to reach it. It would be better to move it in an higher position or add a link at the top of the doc to the assert* methods section with the tables;
2) all the assert methods should be in a table. More tables can be used, e.g.:
  * one with the common methods (the ones in the patch);
  * one with other "comparison" methods like assertLess and friends, assert[Not]AlmostEqual (these could be included in the first table though);
  * one for exceptions and warnings (assertRaises, assertWarn, assertRaisesRegexp, ...);
  * one for "advanced" methods (assertItemsEqual, assertDictContainsSubset, assertSequenceEqual, ...);
  * one for the type-specific methods used by assertEqual (assertSetEqual, assertListEqual, ...), saying that they are used automatically by assertEqual and possibly that they shouldn't be used directly.
3) the doc of the methods should be right after the table that lists them;
4) other non-assert methods shouldn't be mixed with the assert* methods -- the assert* methods should have their own section;
5) other methods could be grouped in tables too (setUp, tearDown, ...; skip*);

----------
keywords: +patch
type:  -> feature request
Added file: http://bugs.python.org/file19454/issue9796.diff

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

From report at bugs.python.org  Mon Nov  1 14:25:30 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 01 Nov 2010 13:25:30 +0000
Subject: [issue9981] let make_buildinfo use a temporary directory on windows
In-Reply-To: <1285741718.07.0.0571419018875.issue9981@psf.upfronthosting.co.za>
Message-ID: <1288617930.8.0.615126895806.issue9981@psf.upfronthosting.co.za>


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

Yes, I took the liberty of removing the superfluous build configuration as well, thereby simplifying the .sln and the build dependency graph.
The patch is for python 2.7.  Even though it's technically not a python patch but a build patch, I'll rework it for 3.2 and submit it.

----------

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

From report at bugs.python.org  Mon Nov  1 14:54:13 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 01 Nov 2010 13:54:13 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>
Message-ID: <1288619653.62.0.00608557304492.issue10260@psf.upfronthosting.co.za>


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

The wait_for() method is basically a distillation of the Semaphore.acquire() method, which tries to intelligently handle a non-trivial timeout.
With this method it is now possible to simplify Semaphore.acquire, although I didn't want to do so in this patch to keep its scope smaller.

----------

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

From report at bugs.python.org  Mon Nov  1 15:01:21 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Nov 2010 14:01:21 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288620081.44.0.928647349583.issue10273@psf.upfronthosting.co.za>


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

* I would leave assert<type>Equal documented and specify that they should be called directly only if the type should be checked, otherwise (if the type doesn't matter or it's already tested elsewhere) using assertEqual is enough (see also the suggestions in msg120124). -0.5 about dedocumenting, +1 on better documentation, possibly in an "advanced" section of the doc (I also find useful to know how assertEqual works and that I can register new functions like assert<type>Equal).

* assertLT and friends wouldn't match with assertEqual and assertNotEqual (assertEQ, assertNE?). Also these names don't seem more obvious or readable than assertLess, and will just add confusion and duplication of names, so -1.

* FWIW I like 'Regex' more than 'Regexp' too, assuming that it's worth renaming these methods and deprecate the old names (they are already in 2.7). Having a 'Match' or 'Search' suffix might clarify what the method does -- if it does what it says. +0 on the renaming (and +1 to 'Regex' if the rename happens).

* as I said on IRC, assertItemsEqual provides an useful functionality, and even if the name is not 100% clear, I'd rather double-check the doc than having to reimplement the functionality myself (or having a clumsy long-but-clear name). -1 on the removal, +1 on better documentation/performance.

* I think assertIsInstance is fine, however I wonder why the opposite is not assertIsNotInstance. Anyway it's probably not worth creating more confusion and adding new names just to change the spelling (they are in 2.7 too).

----------

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

From report at bugs.python.org  Mon Nov  1 15:01:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Nov 2010 14:01:24 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>
Message-ID: <1288620084.91.0.923201953926.issue10260@psf.upfronthosting.co.za>


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

This looks useful indeed.

----------
nosy: +jyasskin, pitrou

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

From report at bugs.python.org  Mon Nov  1 15:22:39 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 01 Nov 2010 14:22:39 +0000
Subject: [issue9553] test_argparse.py: 80 failures if COLUMNS env var set to a
	value other than 80
In-Reply-To: <1281405802.56.0.0746900619959.issue9553@psf.upfronthosting.co.za>
Message-ID: <1288621359.85.0.47699509334.issue9553@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Fixed with a variant of Denver's last patch in r86080 for 3.X and r86083 for 2.7.

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

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

From report at bugs.python.org  Mon Nov  1 16:00:13 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Nov 2010 15:00:13 +0000
Subject: [issue9754] assertWarns and assertWarnsRegexp
In-Reply-To: <1283511017.36.0.0507272422338.issue9754@psf.upfronthosting.co.za>
Message-ID: <1288623613.35.0.608023757451.issue9754@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/issue9754>
_______________________________________

From report at bugs.python.org  Mon Nov  1 16:10:10 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 01 Nov 2010 15:10:10 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

If measuring time across blocking calls, such as thread synchronization, one currently must time.time().  This is because time.clock() measures cpu seconds on unix.  On windows, however, time.clock() would be more appropriate because it measures wall-clock time.

To avoid having to put platform clauses everywhere, this patch adds time.wallclock().
The current implementation is a simple alias to time.clock on windows and time.time otherwise.  Future improvements may add a better implementation on those non-windows platforms that support it.

----------
components: Interpreter Core
files: wallclock.patch
keywords: patch
messages: 120130
nosy: krisvale
priority: normal
severity: normal
status: open
title: add time.wallclock() method
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19455/wallclock.patch

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

From report at bugs.python.org  Mon Nov  1 16:11:52 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 01 Nov 2010 15:11:52 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1288624312.65.0.145449780726.issue10278@psf.upfronthosting.co.za>


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

+1

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

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

From report at bugs.python.org  Mon Nov  1 16:17:20 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Nov 2010 15:17:20 +0000
Subject: [issue9669] regexp: zero-width matches in MIN_UNTIL
In-Reply-To: <1282655524.54.0.725053060384.issue9669@psf.upfronthosting.co.za>
Message-ID: <1288624640.21.0.473365369084.issue9669@psf.upfronthosting.co.za>


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


----------
nosy: +mrabarnett

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

From report at bugs.python.org  Mon Nov  1 16:19:38 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 01 Nov 2010 15:19:38 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1288624778.24.0.422058722528.issue6706@psf.upfronthosting.co.za>


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

Fixed in r86084 (2.7) and r86085 (3.1).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
type: behavior -> security
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Mon Nov  1 16:22:51 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 01 Nov 2010 15:22:51 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>
Message-ID: <1288624971.7.0.093072983961.issue10260@psf.upfronthosting.co.za>


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

* This method will confuse some people who will think that cond.wait(pred) will wake up when pred becomes true regardless of whether they call cond.notifyAll(). You should warn them about this in the documentation. (This confusion happens inside Google, despite our documentation, but the method's worth having even though not everyone will read the docs.) You should also mention that 'predicate' runs with the Condition acquired.

Then +1 whether or not you do anything in response to the below comments.

* There's a small risk of confusion with C++0x's wait_for method, which behaves like the current Condition.wait (waiting for a timeout). They used "wait_for" because they also have a "wait_until" that waits until a deadline. I don't think this potential confusion is a big deal.

* This expands the interface needed to duck-type as a Condition. Maybe you could also add a threading.wait_for(Condition, predicate, timeout) that implements the same thing using just the Condition's .wait() method? I'm not certain that'll be the best name as a threading method, but I don't have a better proposal.

----------

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

From report at bugs.python.org  Mon Nov  1 16:26:52 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 01 Nov 2010 15:26:52 +0000
Subject: [issue9353] argparse __all__ is incomplete
In-Reply-To: <1279895111.13.0.483513856318.issue9353@psf.upfronthosting.co.za>
Message-ID: <1288625212.22.0.0776670665929.issue9353@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Fixed in 3.X in r86086 and in 2.7 in r86087.

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

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

From report at bugs.python.org  Mon Nov  1 16:28:02 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 01 Nov 2010 15:28:02 +0000
Subject: =?utf-8?q?=5Bissue4640=5D_optparse_doesn=E2=80=99t_disallow_adding_one-da?=
	=?utf-8?b?c2ggbG9uZyBvcHRpb25zICjigJwtb3B0aW9u4oCdKQ==?=
In-Reply-To: <1229091283.09.0.553967635356.issue4640@psf.upfronthosting.co.za>
Message-ID: <1288625282.75.0.368816666365.issue4640@psf.upfronthosting.co.za>


Changes by Steven Bethard <steven.bethard at gmail.com>:


----------
nosy:  -bethard

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

From report at bugs.python.org  Mon Nov  1 17:01:01 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 01 Nov 2010 16:01:01 +0000
Subject: [issue9352] argparse eats characters when parsing multiple merged
	short options
In-Reply-To: <1279894704.35.0.264649777176.issue9352@psf.upfronthosting.co.za>
Message-ID: <1288627261.56.0.139162625146.issue9352@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Patches applied in r86090 (3.X) and r86091 (2.7). Thanks for your help Catherine, and sorry it took me so long to apply these.

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

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

From report at bugs.python.org  Mon Nov  1 17:31:23 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 01 Nov 2010 16:31:23 +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: <1288629083.78.0.847007425874.issue9355@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Committed in r86092 (3.X) and r86093 (2.7). Thanks for the patches!

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

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

From report at bugs.python.org  Mon Nov  1 17:34:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 01 Nov 2010 16:34:05 +0000
Subject: [issue10279] test_gc failure on Windows x64
In-Reply-To: <1288629245.88.0.812868116264.issue10279@psf.upfronthosting.co.za>
Message-ID: <1288629245.88.0.812868116264.issue10279@psf.upfronthosting.co.za>


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

======================================================================
FAIL: test_garbage_at_shutdown (test.test_gc.GCTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "c:\python-dev\py3k\lib\test\test_gc.py", line 500, in test_garbage_at_shutdown
    b"shutdown; use", stderr)
AssertionError: b'ResourceWarning: gc: 2 uncollectable objects at shutdown; use'
 not found in b'sys:1: ResourceWarning: gc: %Id uncollectable objects at shutdow
n; use gc.set_debug(gc.DEBUG_UNCOLLECTABLE) to list them'


%Id isn't being replaced with the number in the format string. I only briefly looked into it, not sure why it would be Windows x64 specific (this doesn't happen on Win 32-bit or any *nix buildbots).

----------
messages: 120137
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gc failure on Windows x64
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 17:38:07 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 01 Nov 2010 16:38:07 +0000
Subject: [issue9779] argparse.ArgumentParser not support unicode in print help
In-Reply-To: <1283672170.42.0.322683308746.issue9779@psf.upfronthosting.co.za>
Message-ID: <1288629487.04.0.121295102447.issue9779@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Closing as invalid, as to me this looks like a classic terminal encoding issue and not an argparse issue, and there was no response from the user who filed the issue. If someone still thinks this is an argparse issue, please provide a test and reopen the issue.

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

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

From report at bugs.python.org  Mon Nov  1 17:48:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 01 Nov 2010 16:48:09 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288204661.42.0.184844735996.issue10199@psf.upfronthosting.co.za>
Message-ID: <AANLkTikPL=Lriajb-S8etQaoJEFMsf2RowJphimG3xfx@mail.gmail.com>


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

On Wed, Oct 27, 2010 at 2:37 PM, Gregor Lingl <report at bugs.python.org> wrote:
..
> Imho it is very important to clarify the name convention for demoscripts to be added to the demo before committing
> (or at least before the apperance of beta1). It decides about adding scripts to the Examples Menu of the viewer.
>

I would rather separate move under Lib and any other changes.  However
since files are moved anyways, we can use this opportunity for name
changes.

> We all know, that things once they have found their way into Lib cannot be changed easily afterwards. Guido's
> argument on backwards compatibility applies. So now is the only point in time to decide about this.
>

I don't really expect people to import turtledemo.xyz modules in their
programs.  These are designed as stand-alone scripts and I am not
proposing to change that.  We can further warn users about that in the
documentation, but I think it is obvious that demo scripts are not
supposed to be used as production components.

> Should we
> - stick with the tdemo_ prefix or
> - change to another pre- or postfix (like eg. bytedesign_demo)
> - or should we allow for arbitrary *.py filenames with some exception (e.g. filenames that contain an underscore)
>  to mark files that are not meant as demos for the viewer?
>

In the long run, I would like to add a separate template that will
determine the choice of modules for the viewer and allow menu choices
to be different from module names and the order to be different from
alphabetical.  For not, however, I am going to allow any name except
those starting with an underscore or "two_canvases".

----------

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

From report at bugs.python.org  Mon Nov  1 17:53:20 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Mon, 01 Nov 2010 16:53:20 +0000
Subject: [issue10263] "python -m site" does not print path details
In-Reply-To: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>
Message-ID: <1288630400.32.0.289364647183.issue10263@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

Adding a print to the site.py in Distribute's egg shows it is being run when I use 'python -m site'.  However, when I run 'python -c "import site; print site.__file__"' I get the version from the stdlib, as expected.

I guess the module finding mechanism for -m is different from the import code?

----------

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

From report at bugs.python.org  Mon Nov  1 17:54:41 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Mon, 01 Nov 2010 16:54:41 +0000
Subject: [issue10263] "python -m site" does not print path details
In-Reply-To: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>
Message-ID: <1288630481.49.0.805642508898.issue10263@psf.upfronthosting.co.za>


Changes by Doug Hellmann <doug.hellmann at gmail.com>:


----------
nosy: +tarek

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

From report at bugs.python.org  Mon Nov  1 18:03:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 01 Nov 2010 17:03:16 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1288630996.63.0.375428953014.issue10278@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/issue10278>
_______________________________________

From report at bugs.python.org  Mon Nov  1 18:12:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 01 Nov 2010 17:12:07 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1288631527.45.0.336530086946.issue10278@psf.upfronthosting.co.za>


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

Why does this need to be in stdlib?

AFAICT, the proposed patch is just:

if <appropriate test>:
   wallclock = time.clock
else:
   wallclock = time.time

which is easy enough to stick in your measuring code or a project's utilities module.

If others really want to see this in stdlib, I would prefer to place it in a more specialized module such as profile.

----------

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

From report at bugs.python.org  Mon Nov  1 18:24:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 17:24:34 +0000
Subject: [issue10276] zlib crc32/adler32 buffer length truncation (64-bit)
In-Reply-To: <1288604765.69.0.684600327936.issue10276@psf.upfronthosting.co.za>
Message-ID: <1288632274.97.0.0500155049266.issue10276@psf.upfronthosting.co.za>


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


----------
components: +Extension Modules -Library (Lib)
versions:  -Python 2.5, Python 2.6, Python 3.3

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

From report at bugs.python.org  Mon Nov  1 18:24:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 17:24:55 +0000
Subject: [issue10274] imaplib should provide a means to validate a remote
	server ssl certificate(s)
In-Reply-To: <1288583733.85.0.123923377362.issue10274@psf.upfronthosting.co.za>
Message-ID: <1288632295.91.0.876598772434.issue10274@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Nov  1 18:31:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 17:31:22 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1288632682.95.0.947787733968.issue10278@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/issue10278>
_______________________________________

From report at bugs.python.org  Mon Nov  1 18:31:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Nov 2010 17:31:47 +0000
Subject: [issue10274] imaplib should provide a means to validate a remote
	server ssl certificate(s)
In-Reply-To: <1288583733.85.0.123923377362.issue10274@psf.upfronthosting.co.za>
Message-ID: <1288632707.5.0.114703163306.issue10274@psf.upfronthosting.co.za>


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

Right, IMAP_SSL should first accept an additional context argument as noted in issue10274. Then it can be patched to optionally call ssl.match_hostname on the server certificate. That second part can mimick what is done by HTTPSConnection:
http://code.python.org/hg/branches/py3k/file/tip/Lib/http/client.py#l1052

----------
dependencies: +imaplib should provide a means to validate a remote server ssl certificate(s)
stage:  -> needs patch
type: security -> feature request
versions: +Python 3.3

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

From report at bugs.python.org  Mon Nov  1 18:32:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Nov 2010 17:32:54 +0000
Subject: [issue10274] imaplib should provide a means to validate a remote
	server ssl certificate(s)
In-Reply-To: <1288583733.85.0.123923377362.issue10274@psf.upfronthosting.co.za>
Message-ID: <1288632774.24.0.73980968518.issue10274@psf.upfronthosting.co.za>


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

Sorry, the actual issue number is issue8808.

----------
dependencies: +imaplib should support SSL contexts -imaplib should provide a means to validate a remote server ssl certificate(s)

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

From report at bugs.python.org  Mon Nov  1 18:43:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Nov 2010 17:43:18 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1288633398.27.0.455727731436.issue10278@psf.upfronthosting.co.za>


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

Well, the problem is that the "appropriate test" is not easy to guess a priori, so it would be useful for the stdlib to provide the right tool for the job.
As for where it should live, I have no strong opinion, but it's true that the time module looks appropriate.

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

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

From report at bugs.python.org  Mon Nov  1 18:43:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 01 Nov 2010 17:43:30 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288633410.25.0.261405481976.issue10199@psf.upfronthosting.co.za>


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

Committed in revision 86095.  I included only those demo scripts that are described in the current manual.  I am open to making further improvements prior to bata 1, and will open separate issues to track those.

----------
stage: commit review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Nov  1 18:50:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 17:50:27 +0000
Subject: [issue10262] Add --disable-abi-flags option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1288633827.92.0.843660917278.issue10262@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/issue10262>
_______________________________________

From report at bugs.python.org  Mon Nov  1 18:55:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 01 Nov 2010 17:55:44 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288633398.27.0.455727731436.issue10278@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Oauu2q1z5dYembm+ARz_y3ifdYLxODq_D9F_b@mail.gmail.com>


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

On Mon, Nov 1, 2010 at 1:43 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
> Well, the problem is that the "appropriate test" is not easy to guess a priori, so it would
> be useful for the stdlib to provide the right tool for the job.

This sounds like an argument against this feature, not for it.  If it
is hard for the application code to implement an appropriate test "a
priori", what is the chance to get it right in stdlib?

> As for where it should live, I have no strong opinion, but it's true that the time module looks appropriate.

Having time.time and time.clock is already confusing enough.  Having
the third function which is either the first or the second depending
on some unspecified criterion does not strike me as a clean design.

----------

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

From report at bugs.python.org  Mon Nov  1 19:00:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 01 Nov 2010 18:00:16 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288634416.41.0.9245857293.issue10221@psf.upfronthosting.co.za>


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

Raymond,

Did you mean to exclude unit test additions from your commit?  See issue10221-with-tests.diff.

----------

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

From report at bugs.python.org  Mon Nov  1 19:03:10 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 01 Nov 2010 18:03:10 +0000
Subject: [issue10263] "python -m site" does not print path details
In-Reply-To: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>
Message-ID: <1288634590.45.0.481462414565.issue10263@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Nick is the authority on -m so perhaps he can confirm this but I believe the execution of -m is carried out by the runpy standard library module and the runpy module essentially goes through the process of finding a module from scratch by searching through the modules in sys.path, thus bypassing the altered sys.path which the setuptools/Distribute site module "bootstrapped" and removed itself from.  So runpy will always find the setuptools/Distribute site module first since it is first on sys.path (until it executes and removes itself from sys.path).  It seems you've found one case where the sys.path manipulations of setuptools/Distributes make a difference: when trying to run site itself.  You can see which site module is found by runpy by trying:
  import runpy
  runpy.run_module("site")

----------

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

From report at bugs.python.org  Mon Nov  1 19:09:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Nov 2010 18:09:52 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <AANLkTi=Oauu2q1z5dYembm+ARz_y3ifdYLxODq_D9F_b@mail.gmail.com>
Message-ID: <1288634987.11453.9.camel@localhost.localdomain>


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

> > Well, the problem is that the "appropriate test" is not easy to guess a priori, so it would
> > be useful for the stdlib to provide the right tool for the job.
> 
> This sounds like an argument against this feature, not for it.  If it
> is hard for the application code to implement an appropriate test "a
> priori", what is the chance to get it right in stdlib?

The point of a standard library is to bring together competence and
experience to build a common ground of useful functions. If we
restricted ourselves to easy things then 75% of the stdlib should be
ripped out.

> > As for where it should live, I have no strong opinion, but it's true that the time module looks appropriate.
> 
> Having time.time and time.clock is already confusing enough.  Having
> the third function which is either the first or the second depending
> on some unspecified criterion does not strike me as a clean design.

The problem is time.clock(), since it does two wildly different things
depending on the OS.
I would suggest to deprecate time.clock() at the same time as we add
time.wallclock(). For the Unix-specific definition of time.clock(),
there is already os.times() (which gives even richer information).

----------

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

From report at bugs.python.org  Mon Nov  1 19:13:23 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 01 Nov 2010 18:13:23 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288635203.3.0.260095333734.issue10221@psf.upfronthosting.co.za>


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

We don't usually test the content of error messages because they are not a guaranteed behavior.

----------

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

From report at bugs.python.org  Mon Nov  1 19:23:04 2010
From: report at bugs.python.org (Ivan Razumov)
Date: Mon, 01 Nov 2010 18:23:04 +0000
Subject: [issue10259] Entry text not set if all of 'Font',
	'Foreground' and 'Justify' are set
In-Reply-To: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>
Message-ID: <1288635784.57.0.619649575272.issue10259@psf.upfronthosting.co.za>


Ivan Razumov <iarspider at gmail.com> added the comment:

The bug doesn't seem to be Windows-specific - tested on Ubuntu 10.10 (Python 2.6.6)

----------

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

From report at bugs.python.org  Mon Nov  1 19:29:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 01 Nov 2010 18:29:21 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288635203.3.0.260095333734.issue10221@psf.upfronthosting.co.za>
Message-ID: <AANLkTimZHW3YW=en+HT50ZhAz+9eM5=q=vxGJ=nz=Vxn@mail.gmail.com>


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

On Mon, Nov 1, 2010 at 2:13 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
..
>
> We don't usually test the content of error messages because they are not a guaranteed behavior.
>
I recall that when I asked about this on #python-dev, someone pointed
to places where content of error messages is tested in python unit
tests.  I also asked whether such tests should be marked as cpython
details, and the answer was know.  Unfortunately I don't remember who
was telling me that, but it sounded reasonable enough that I submitted
the tests.

I think if testing error messages is a grey area, in this case it is
reasonable to have a test for at least two reasons:

1. It was reported as a bug, so users already expect this behavior.

2. There is no prose in the error message, just the key, so it is not
as arbitrary as other error messages.

Note that in my tests I deliberately tested only e.args[0] and not
str(e) or e.args[1:].

----------

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

From report at bugs.python.org  Mon Nov  1 19:32:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 01 Nov 2010 18:32:40 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288634987.11453.9.camel@localhost.localdomain>
Message-ID: <AANLkTinBGirXR59BO4b_0_BuYvJuWCLuMdEVodAWM7+5@mail.gmail.com>


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

On Mon, Nov 1, 2010 at 2:09 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
>> > Well, the problem is that the "appropriate test" is not easy to guess a priori, so it would
>> > be useful for the stdlib to provide the right tool for the job.
>>
>> This sounds like an argument against this feature, not for it. ?If it
>> is hard for the application code to implement an appropriate test "a
>> priori", what is the chance to get it right in stdlib?
>
> The point of a standard library is to bring together competence and
> experience to build a common ground of useful functions. If we
> restricted ourselves to easy things then 75% of the stdlib should be
> ripped out.
>

It looks like I misunderstood what you said.  I thought "a priory"
meant without knowing the details of the application rather than "by a
novice."

----------

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

From report at bugs.python.org  Mon Nov  1 19:55:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 01 Nov 2010 18:55:37 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288634987.11453.9.camel@localhost.localdomain>
Message-ID: <AANLkTimHSkhcxDsZT4ncrJT=abPW34RZ2YkLwPLQ2Jne@mail.gmail.com>


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

On Mon, Nov 1, 2010 at 2:09 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
> The problem is time.clock(), since it does two wildly different things
> depending on the OS.
> I would suggest to deprecate time.clock() at the same time as we add
> time.wallclock(). For the Unix-specific definition of time.clock(),
> there is already os.times() (which gives even richer information).

+1, but doing something like that should be discussed on python-ideas
first.  We should also weigh this against other proposals such as
exposing gettimeofday.

----------

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

From report at bugs.python.org  Mon Nov  1 20:39:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 19:39:48 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1288640388.76.0.330268441154.issue10252@psf.upfronthosting.co.za>


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

Thanks for the patch, I?ll review it and commit it soon.

----------
assignee: tarek -> eric.araujo
status: open -> pending
title: Fix resource warnings in distutil tests -> Fix resource warnings in distutils

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

From report at bugs.python.org  Mon Nov  1 20:53:15 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 19:53:15 +0000
Subject: [issue10280] nntp_version set to the most recent advertised version
In-Reply-To: <1288641195.29.0.702249344241.issue10280@psf.upfronthosting.co.za>
Message-ID: <1288641195.29.0.702249344241.issue10280@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

The NNTP version is currently defined as follows in the source code:

self.nntp_version = int(caps['VERSION'][0])

However, Section 3.3.2 of RFC 3977 mentions:

   VERSION
      This capability MUST be advertised by all servers and MUST be the
      first capability in the capability list; it indicates the
      version(s) of NNTP that the server supports.  There must be at
      least one argument; each argument is a decimal number and MUST NOT
      have a leading zero.  Version numbers are assigned only in RFCs
      that update or replace this specification; servers MUST NOT create
      their own version numbers.

There can be more than one version.
See the example in Section 5.2.3:

      [S] VERSION 2 3

I believe the best thing to do would be to take the max of the numbers, that is to say:

self.nntp_version = max(map(int, caps['VERSION']))

----------
components: Extension Modules
messages: 120156
nosy: jelie
priority: normal
severity: normal
status: open
title: nntp_version set to the most recent advertised version
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 20:55:13 2010
From: report at bugs.python.org (Robert Lerche)
Date: Mon, 01 Nov 2010 19:55:13 +0000
Subject: [issue10232] Tkinter issues with Scrollbar and custom widget list
In-Reply-To: <1288366788.46.0.695886030233.issue10232@psf.upfronthosting.co.za>
Message-ID: <1288641313.54.0.538832216052.issue10232@psf.upfronthosting.co.za>


Robert Lerche <ral at msbit.com> added the comment:

Terry, I tried posting to python-list and all I got was "why are you doing that?  Use Tix instead."

Maybe it's good advice but it doesn't address the issue.  And Tix is yet one more component I'd have to build (the Python distribution comes with Tix interface code but Tix itself is yet another .dll).

I haven't decided how to proceed yet but if you have any suggestions please let me know.  Thanks again.

----------

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

From report at bugs.python.org  Mon Nov  1 20:58:24 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 19:58:24 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

Following the first example of the documentation:

import nntplib

s = nntplib.NNTP('news.trigofacile.com')
resp, count, first, last, name = s.group('fr.comp.lang.python')
print('Group', name, 'has', count, 'articles, range', first, 'to', last)
resp, overviews = s.over((last - 9, last))
for id, over in overviews:
    print(id, nntplib.decode_header(over['subject']))
s.quit()


An exception is raised:
"OVER/XOVER response doesn't include names of additional headers"


I believe the issue comes from the fact that the source code does not
handle the case described in Section 8.3.2 of RFC 3977:

   For all fields, the value is processed by first removing all CRLF
   pairs (that is, undoing any folding and removing the terminating
   CRLF) and then replacing each TAB with a single space.  If there is
   no such header in the article, no such metadata item, or no header or
   item stored in the database for that article, the corresponding field
   MUST be empty.

   Example of a successful retrieval of overview information for a range
   of articles:

      [C] GROUP misc.test
      [S] 211 1234 3000234 3002322 misc.test
      [C] OVER 3000234-3000240
      [S] 224 Overview information follows
      [S] 3000234|I am just a test article|"Demo User"
          <nobody at example.com>|6 Oct 1998 04:38:40 -0500|
          <45223423 at example.com>|<45454 at example.net>|1234|
          17|Xref: news.example.com misc.test:3000363
      [S] 3000235|Another test article|nobody at nowhere.to
          (Demo User)|6 Oct 1998 04:38:45 -0500|<45223425 at to.to>||
          4818|37||Distribution: fi
      [S] 3000238|Re: I am just a test article|somebody at elsewhere.to|
          7 Oct 1998 11:38:40 +1200|<kfwer3v at elsewhere.to>|
          <45223423 at to.to>|9234|51
      [S] .

   Note the missing "References" and Xref headers in the second line,
   the missing trailing fields in the first and last lines, and that
   there are only results for those articles that still exist.






Also please note that nntplib should also work in case the database is not consistent.  Some news servers might be broken and do not follow the MUST NOT...

   The LIST OVERVIEW.FMT command SHOULD list all the fields for which
   the database is consistent at that moment.  It MAY omit such fields
   (for example, if it is not known whether the database is consistent
   or inconsistent).  It MUST NOT include fields for which the database
   is inconsistent or that are not stored in the database.  Therefore,
   if a header appears in the LIST OVERVIEW.FMT output but not in the
   OVER output for a given article, that header does not appear in the
   article (similarly for metadata items).

----------
components: Extension Modules
messages: 120158
nosy: jelie
priority: normal
severity: normal
status: open
title: Exception raised when an NNTP overview field is absent
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 21:02:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Nov 2010 20:02:43 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288641763.19.0.171394420598.issue10281@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/issue10281>
_______________________________________

From report at bugs.python.org  Mon Nov  1 21:03:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Nov 2010 20:03:24 +0000
Subject: [issue10280] nntp_version set to the most recent advertised version
In-Reply-To: <1288641195.29.0.702249344241.issue10280@psf.upfronthosting.co.za>
Message-ID: <1288641804.72.0.575825174732.issue10280@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/issue10280>
_______________________________________

From report at bugs.python.org  Mon Nov  1 21:16:07 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:16:07 +0000
Subject: [issue10282] IMPLEMENTATION token differently delt with in NNTP
	capability
In-Reply-To: <1288642567.32.0.7785411032.issue10282@psf.upfronthosting.co.za>
Message-ID: <1288642567.32.0.7785411032.issue10282@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

I believe the case of "IMPLEMENTATION" should be treated differently.
It is not helpful at all to split the argument.  It is meant to be a
text string and ['INN', '2.6.0', '(20101101', 'prelease)'] does not
have much meaning...

Suggestion:

            if line.startswith("IMPLEMENTATION"):
                 name, *tokens = line.split(None, 1)
            else:
                 name, *tokens = line.split()

or something else, though I do not believe another keyword will begin with "IMPLEMENTATION"...

Besides, shouldn't it be checked that the line is not empty, before splitting it?

----------
components: Extension Modules
messages: 120159
nosy: jelie
priority: normal
severity: normal
status: open
title: IMPLEMENTATION token differently delt with in NNTP capability
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 21:21:04 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:21:04 +0000
Subject: [issue10283] New parameter for an NNTP newsgroup pattern in LIST
	ACTIVE
In-Reply-To: <1288642864.21.0.311033761057.issue10283@psf.upfronthosting.co.za>
Message-ID: <1288642864.21.0.311033761057.issue10283@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

NNTP.list(*, file=None)

Couldn't a "grouppattern" argument be added?
LIST ACTIVE handles a newsgroup pattern (and it would then answer
less groups -- also useful for the test suite of nntplib)


Something like that:


--- nntplib.py.OLD      2010-11-01 19:04:10.000000000 +0100
+++ nntplib.py  2010-11-01 19:57:50.000000000 +0100
@@ -568,14 +568,18 @@
         cmd = 'NEWNEWS {0} {1} {2}'.format(group, date_str, time_str)
         return self._longcmdstring(cmd, file)

-    def list(self, *, file=None):
+    def list(self, *, group_pattern=None, file=None):
         """Process a LIST command. Argument:
         - file: Filename string or file object to store the result in
         Returns:
         - resp: server response if successful
         - list: list of (group, last, first, flag) (strings)
         """
-        resp, lines = self._longcmdstring('LIST', file)
+        if group_pattern is not None:
+            command = 'LIST ACTIVE ' + group_pattern
+        else:
+            command = 'LIST'
+        resp, lines = self._longcmdstring(command, file)
         return resp, self._grouplist(lines)

     def _getdescriptions(self, group_pattern, return_all):





Then, you could perhaps re-activate the LIST test in the test suite...

    # Disabled with gmane as it produces too much data
    test_list = None



In the documentation:

- .. method:: NNTP.list(*, file=None)
+ .. method:: NNTP.list(*, grouppattern=None, file=None)

and describe it the same way grouppattern is described
in the following command (LIST NEWSGROUPS).

----------
components: Extension Modules
messages: 120160
nosy: jelie
priority: normal
severity: normal
status: open
title: New parameter for an NNTP newsgroup pattern in LIST ACTIVE
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 21:22:40 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:22:40 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

> +# - all commands are encoded as UTF-8 data (using the "surrogateescape"
> +#   error handler), except for raw message data (POST, IHAVE)
> +# - all responses are decoded as UTF-8 data (using the "surrogateescape"
> +#   error handler), except for raw message data (ARTICLE, HEAD, BODY)

It does not seem to work on my news server (news.trigofacile.com):

print(s.descriptions('*'))

Exception raised with an UnicodeEncodeError.  I do not know what is happening.
The same command works fine with Python 2.7 and 3.0.



Also, for AUTHINFO, be careful that nntplib should not send an UTF-8 string but a byte string.  (I have not tested.)
The username and the password are byte strings.

----------
components: Extension Modules
messages: 120161
nosy: jelie
priority: normal
severity: normal
status: open
title: Exception raised when decoding NNTP newsgroup descriptions
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 21:25:23 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:25:23 +0000
Subject: [issue10285] Other status field flags in documentation for NNTP LIST
	command
In-Reply-To: <1288643123.11.0.762395184057.issue10285@psf.upfronthosting.co.za>
Message-ID: <1288643123.11.0.762395184057.issue10285@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

> +.. method:: NNTP.list(*, file=None)
> +
> +   Send a ``LIST`` command.  Return a pair ``(response, list)`` where *list* is a
> +   list of tuples representing all the groups available from this NNTP server.
> +   Each tuple has the form ``(group, last, first, flag)``, where
> +   *group* is a group name, *last* and *first* are the last and first article
> +   numbers, and *flag* is ``'y'`` if posting is allowed, ``'n'`` if not,
> +   and ``'m'`` if the newsgroup is moderated.  (Note the ordering: *last*, *first*.)

There are other values:  'x', 'j', and '=' followed by the name of a newsgroup (alias).

I believe the best would be to use what INN mentions in its documentation!  (Or otherwise, RFC 3977 and RFC 6048.)

    http://www.eyrie.org/~eagle/software/inn/docs/active.html


It would then give:

-------------------------------------------------------------------------------------
... and *flag* usually takes one of these values:

    y         Local postings and articles from peers are allowed.
    m         The group is moderated and all postings must be approved.
    n         No local postings are allowed, only articles from peers.
    j         Articles from peers are filed in the junk group instead.
    x         No local postings, and articles from peers are ignored.
    =foo.bar  Articles are filed in the group foo.bar instead.

If *flag* has another value, then the status of the newsgroup should be considered
to be unknown.
-------------------------------------------------------------------------------------


Can a bullet list be used in the documentation, to properly indent the flag values?

----------
assignee: docs at python
components: Documentation, Extension Modules
messages: 120162
nosy: docs at python, jelie
priority: normal
severity: normal
status: open
title: Other status field flags in documentation for NNTP LIST command
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 21:25:49 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:25:49 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288643149.62.0.457757332266.issue10284@psf.upfronthosting.co.za>


Changes by Julien ?LIE <julien at trigofacile.com>:


----------
components: +Unicode

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

From report at bugs.python.org  Mon Nov  1 21:26:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Nov 2010 20:26:56 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288643216.86.0.694294182137.issue10284@psf.upfronthosting.co.za>


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

What's the exception?  If there were any escaped bytes in the string returned by descriptions, you would get an error when you try to print them.

This could be a design problem.

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

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

From report at bugs.python.org  Mon Nov  1 21:28:26 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Mon, 01 Nov 2010 20:28: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: <1288643306.98.0.821731043696.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101101.zip is a new version of the regex module.

I hope it's finally fixed this time! :-)

----------
Added file: http://bugs.python.org/file19456/issue2636-20101101.zip

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

From report at bugs.python.org  Mon Nov  1 21:28:55 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 01 Nov 2010 20:28:55 +0000
Subject: [issue10286] URLOpener => URLopener x2 in fix_urllib.py
In-Reply-To: <1288643335.41.0.951306369167.issue10286@psf.upfronthosting.co.za>
Message-ID: <1288643335.41.0.951306369167.issue10286@psf.upfronthosting.co.za>


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

Lib/lib2to3/fixes/fix_urllib.py, near the top, has
'''
MAPPING = {'urllib':  [
                ('urllib.request',
                    ['URLOpener', 'FancyURLOpener', 'urlretrieve',
'''
'Opener' should by 'opener' in BOTH cases.

Non-fix of URLopener reported on python-list by Chris McDonald.

----------
components: 2to3 (2.x to 3.0 conversion tool)
keywords: easy
messages: 120165
nosy: benjamin.peterson, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: URLOpener => URLopener x2 in fix_urllib.py
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Mon Nov  1 21:30:10 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:30:10 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288643410.83.0.589736191962.issue1926@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

Regarding these two possibilities, please note that the first one is discouraged (per RFC 4642).
STARTTLS is the preferrable way to start a TLS session.


   In some existing implementations, TCP port 563 has been dedicated to
   NNTP over TLS.  These implementations begin the TLS negotiation
   immediately upon connection and then continue with the initial steps
   of an NNTP session.  This use of TLS on a separate port is
   discouraged for the reasons documented in Section 7 of "Using TLS
   with IMAP, POP3 and ACAP" [TLS-IMAPPOP].

----------
nosy: +jelie

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

From report at bugs.python.org  Mon Nov  1 21:46:50 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 01 Nov 2010 20:46:50 +0000
Subject: [issue10232] Tkinter issues with Scrollbar and custom widget list
In-Reply-To: <1288366788.46.0.695886030233.issue10232@psf.upfronthosting.co.za>
Message-ID: <1288644410.45.0.276578343868.issue10232@psf.upfronthosting.co.za>


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

For me, with a standard Python install, 'use tix' would be a good answer. After thanking the respondent, you could try answering 'why' ('I am using a custom build.'). Just remember that python-list and mirrors are like the Wild West: you may get a mix of bullets and beans. I am adding gpolo to nosy in case he can say something.

----------
nosy: +gpolo

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

From report at bugs.python.org  Mon Nov  1 21:50:12 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:50:12 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288644612.25.0.575505223196.issue10284@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

Traceback (most recent call last):
  File "nntplib-test.py", line 10, in <module>
    print(s.descriptions('*'))
  File "C:\Program Files\Python32\lib\encodings\cp850.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode characters in position 3285-3287: character maps to <undefined>


The code was previously working fine with Python 3.1.



Looking more in details:

(resp, descs) = s.descriptions('*')

clefs = list(descs.keys())
clefs.sort()
for clef in clefs:
    print(clef), print(b[clef])



Traceback (most recent call last):
  File "nntplib-test.py", line 14, in <module>
    print(clef), print(b[clef])
  File "C:\Program Files\Python32\lib\encodings\cp850.py", line 19, in encode
    return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\u0152' in position 0: character maps to <undefined>


That is another error.  It corresponds to a description containing ?????, yet in UTF-8.

So you mean the issue comes from the MS-DOS console I am using.
Well, that seems right.
No problem in the Python IDLE!

Maybe this issue should be closed then?

(Yet, something changed because print() worked fine with the previous version...)

----------

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

From report at bugs.python.org  Mon Nov  1 21:52:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 20:52:02 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288644722.38.0.0367202204483.issue10284@psf.upfronthosting.co.za>


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

FTR, a UTF-8 string *is* a byte string.

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

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

From report at bugs.python.org  Mon Nov  1 21:58:20 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 20:58:20 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288645100.64.0.513264190287.issue10284@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

Yes, you're right.
I meant to say that AUTHINFO is not expecting a UTF-8-encoded string.

For instance:

AUTHINFO USER ?ric

is valid and should not always be transformed by nntplib to:

AUTHINFO USER ??ric


News servers do a byte-string comparison (as specified in RFC 4643).  So if ???ric?? is the expected user name, then it is this very name that is expected!

----------

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

From report at bugs.python.org  Mon Nov  1 22:00:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 01 Nov 2010 21:00:02 +0000
Subject: [issue8805] urllib should support SSL contexts
In-Reply-To: <1274717044.09.0.580152326927.issue8805@psf.upfronthosting.co.za>
Message-ID: <1288645202.39.0.0698756562208.issue8805@psf.upfronthosting.co.za>


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

In #10050 you suggest deprecating *URLopener (not *Opener, the misspelling also in fix_urllib.py #10286) and other stuff. Which do you actually prefer, upgrade or degrade?

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Mon Nov  1 22:00:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 21:00:12 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288645212.05.0.297761811486.issue10284@psf.upfronthosting.co.za>


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

But ? cannot be transferred as is.  It needs to be encoded to bytes using some encoding.  What encoding is correct?

----------

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

From report at bugs.python.org  Mon Nov  1 22:01:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Nov 2010 21:01:35 +0000
Subject: [issue10184] tarfile touches directories twice
In-Reply-To: <1287860800.8.0.977653393639.issue10184@psf.upfronthosting.co.za>
Message-ID: <1288645295.91.0.942975266342.issue10184@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/issue10184>
_______________________________________

From report at bugs.python.org  Mon Nov  1 22:01:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 21:01:45 +0000
Subject: [issue10050] urllib.request still has old 2.x urllib primitives
In-Reply-To: <1286536471.26.0.454336144311.issue10050@psf.upfronthosting.co.za>
Message-ID: <1288645305.73.0.35025801839.issue10050@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/issue10050>
_______________________________________

From report at bugs.python.org  Mon Nov  1 22:05:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 01 Nov 2010 21:05:57 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288645557.53.0.853779009347.issue10284@psf.upfronthosting.co.za>


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

?ric: UTF-8 (IIUC the RFC says "SHOULD be UTF-8").

Julien: yes, there are differences in the way printing to the console works between 2.x and 3.x, and this has caused some surprises for Windows users, where the default console codec is a bit limited.  So yes I'm going to close this issue.  Reopen it if you find it is not a windows console problem.

----------
components: +Library (Lib) -Extension Modules, Unicode
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Mon Nov  1 22:14:09 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 01 Nov 2010 21:14:09 +0000
Subject: [issue9635] Add Py_BREAKPOINT and sys.breakpoint hooks
In-Reply-To: <1282175005.37.0.905894818052.issue9635@psf.upfronthosting.co.za>
Message-ID: <1288646049.17.0.895490980864.issue9635@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Adding updated version of patch, which adds documentation to sys.rst and adds a unit test.

I'm a little wary of this: it seems useful but also too much like a self-destruct button for my taste.

----------
Added file: http://bugs.python.org/file19457/py3k-add-breakpoint-2010-11-01-001.patch

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

From report at bugs.python.org  Mon Nov  1 22:15:03 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 01 Nov 2010 21:15:03 +0000
Subject: [issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks
In-Reply-To: <1282175005.37.0.905894818052.issue9635@psf.upfronthosting.co.za>
Message-ID: <1288646103.51.0.978988377987.issue9635@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I renamed it from sys.breakpoint to sys._breakpoint, since this is CPython-specific

----------
title: Add Py_BREAKPOINT and sys.breakpoint hooks -> Add Py_BREAKPOINT and sys._breakpoint hooks

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

From report at bugs.python.org  Mon Nov  1 22:16:49 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 01 Nov 2010 21:16:49 +0000
Subject: [issue9926] Wrapped TestSuite subclass does not get __call__ executed
In-Reply-To: <1285252368.31.0.189981048833.issue9926@psf.upfronthosting.co.za>
Message-ID: <1288646209.34.0.313078725192.issue9926@psf.upfronthosting.co.za>


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

Committed to py3k in revision 86101. Needs porting to Python 2.7 (and unittest2).

----------

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

From report at bugs.python.org  Mon Nov  1 22:18:27 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 21:18:27 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288646306.99.0.777709989379.issue10284@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

David:  no, the RFC does not mention UTF-8 about AUTHINFO.
Please note the subtlety:

   command =/ authinfo-sasl-command /
        authinfo-user-command /
        authinfo-pass-command

   authinfo-sasl-command = "AUTHINFO" WS "SASL" WS mechanism
        [WS initial-response]
   authinfo-user-command = "AUTHINFO" WS "USER" WS username
   authinfo-pass-command = "AUTHINFO" WS "PASS" WS password

   initial-response = base64-opt
   username = 1*user-pass-char
   password = 1*user-pass-char
   user-pass-char = B-CHAR

   ;   U- means based on UTF-8, excluding NUL CR and LF
   ;   B- means based on bytes, excluding NUL CR and LF
   U-CHAR     = CTRL / TAB / SP / A-CHAR / UTF8-non-ascii
   B-CHAR     = CTRL / TAB / SP / %x21-FF


That is not for nothing that B-CHAR are explicitly mentioned.  And *not* U-CHAR.
That is why I insist on that fact, and I fear the new nntplib implementation using UTF-8 is breaking the NNTP protocol at some places...

----------

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

From report at bugs.python.org  Mon Nov  1 22:22:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 01 Nov 2010 21:22:18 +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: <1288646538.49.0.783891079831.issue6011@psf.upfronthosting.co.za>


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

I reproduced the problem with the following commands:

cd py3k
export LANG=C
export LC_ALL=C
make distclean
./configure --with-pydebug --prefix=/home/haypo/tmp/py3k?
make

It looks like the problem is that srcdir environment variable of Makefile.pre is ".". In this case, VPATH environment variable is not set and so calculate_path() fails to retrieve the source code directory.

configure script contains a strange comment (whereas i cannot find "VPATH" in configure.in):

# VPATH may cause trouble with some makes, so we remove sole $(srcdir),
# ${srcdir} and @srcdir@ entries from VPATH if srcdir is ".", strip leading and
# trailing colons and then remove the whole line if VPATH becomes empty
# (actually we leave an empty line to preserve line numbers).

----------

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

From report at bugs.python.org  Mon Nov  1 22:28:29 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 21:28:29 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288646909.66.0.445791226319.issue10284@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

?ric:  there is no notion of encoding in a few NNTP commands.
Regarding AUTHINFO, the real string that I should have written is:

AUTHINFO USER \xC9ric

7-bit bytes are considered to be encoded in ASCII.
8-bit bytes are just 8-bit bytes.  No encoding.

The news client and the news server have to agree on the setting.  Authentification occurs between them.
I can imagine the news client in ISO-8859-1 and the news server in ISO-8859-15, and a password with a ????? sign in.  Then the password will not be the "same" (when entered on the keyboard), but will match in bytes!


I hope my explanation was clear enough now.
No encoding, just byte strings here!

----------

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

From report at bugs.python.org  Mon Nov  1 22:29:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 01 Nov 2010 21:29:54 +0000
Subject: [issue9796] Add summary tables for unittest API
In-Reply-To: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>
Message-ID: <1288646994.3.0.694037737501.issue9796@psf.upfronthosting.co.za>


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

I implemented 2) and 3) in issue9796-2.diff.

----------
assignee: eric.araujo -> ezio.melotti
Added file: http://bugs.python.org/file19458/issue9796-2.diff

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

From report at bugs.python.org  Mon Nov  1 22:37:36 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 21:37:36 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288647456.7.0.65162701785.issue10284@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

Maybe the bug should be reopened -- or the subject changed -- because the real issue is when I read:

# Incompatible changes from the 2.x nntplib:
# - all commands are encoded as UTF-8 data (using the "surrogateescape"
#   error handler), except for raw message data (POST, IHAVE)
# - all responses are decoded as UTF-8 data (using the "surrogateescape"
#   error handler), except for raw message data (ARTICLE, HEAD, BODY)

# UTF-8 is the character set for all NNTP commands and responses: they
# are automatically encoded (when sending) and decoded (and receiving)
# by this class.

That is not true.
What for XOVER/OVER answers?  They contain raw message data.  Why aren't they excluded?
And XHDR/HDR answers?
(As I see that HEAD is excluded, then so should OVER and HDR...)

And AUTHINFO, as I have just explained in the comments here.

----------

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

From report at bugs.python.org  Mon Nov  1 22:39:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Nov 2010 21:39:41 +0000
Subject: [issue10184] tarfile touches directories twice
In-Reply-To: <1287860800.8.0.977653393639.issue10184@psf.upfronthosting.co.za>
Message-ID: <1288647581.1.0.431926068139.issue10184@psf.upfronthosting.co.za>


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

This is now committed as r86102. I opted to call the parameter set_attrs.

----------

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

From report at bugs.python.org  Mon Nov  1 22:39:48 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 01 Nov 2010 21:39:48 +0000
Subject: [issue10184] tarfile touches directories twice
In-Reply-To: <1287860800.8.0.977653393639.issue10184@psf.upfronthosting.co.za>
Message-ID: <1288647588.84.0.651646165488.issue10184@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Mon Nov  1 22:56:32 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Mon, 01 Nov 2010 21:56:32 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>


New submission from Julien ?LIE <julien at trigofacile.com>:

RFC 4643:

   The server MAY list the AUTHINFO capability with no arguments, which
   indicates that it complies with this specification and does not
   permit any authentication commands in its current state.  In this
   case, the client MUST NOT attempt to utilize any AUTHINFO commands,
   even if it contains logic that might otherwise cause it to do so
   (e.g., for backward compatibility with servers that are not compliant
   with this specification).

Yet, nntplib attempts to authenticate.


self.capabilities() should be sent at startup.

If "READER" is advertised, no need to send a "MODE READER" command at all...

If "MODE-READER" is advertised, then "MODE READER" (if wanted) can be sent.
Then, self.capabilities() should be sent again.  Capabilities changed!

Then authentication if "AUTHINFO USER" is advertised with NNTP version >=2.  If "AUTHINFO" without "USER", no authentication at all.

And after authentication, self.capabilities() should be sent again.



Please note that the readermode_afterauth variable I see in the source code should normally not be used by a client...  RFC 4643 mentions:

   o  the MODE READER command MUST NOT be used in the
      same session following successful authentication.

----------
components: Library (Lib)
messages: 120183
nosy: jelie
priority: normal
severity: normal
status: open
title: NNTP authentication should check capabilities
versions: Python 3.2

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

From report at bugs.python.org  Mon Nov  1 23:12:45 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 01 Nov 2010 22:12:45 +0000
Subject: [issue9926] Wrapped TestSuite subclass does not get __call__ executed
In-Reply-To: <1285252368.31.0.189981048833.issue9926@psf.upfronthosting.co.za>
Message-ID: <1288649565.92.0.592144597519.issue9926@psf.upfronthosting.co.za>


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

Committed to release27-maint in revision 86104.

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

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

From report at bugs.python.org  Mon Nov  1 23:41:47 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 01 Nov 2010 22:41:47 +0000
Subject: [issue10288] Remove
In-Reply-To: <1288651306.95.0.100885156034.issue10288@psf.upfronthosting.co.za>
Message-ID: <1288651306.95.0.100885156034.issue10288@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

Issue 5793 rationalized all usage of C "character" handling to use "Py_"-prefixed locale-unaware macros, at the "char" level.

In particular, this comment was added in two places to Include/bytes_methods.h in r72044:
http://svn.python.org/view/python/branches/py3k/Include/bytes_methods.h?view=diff&r1=72043&r2=72044

  /* These are left in for backward compatibility and will be removed
  in 2.8/3.2 */

Given that 3.2 is coming soon, is it time to remove these?  (also, the reference to "2.8" caught my eye)

Attached is a patch to py3k which removes them, and fixes up various users that were still in the source tree.

Am I right in thinking that the undef and redefinition of the various lower-case macros from <ctype.h> was already intended to be removed? (given that this messes about with a standard C library)

----------
files: py3k-remove-old-char-compat-macros.patch
keywords: patch
messages: 120185
nosy: dmalcolm, eric.smith, mark.dickinson
priority: normal
severity: normal
stage: patch review
status: open
title: Remove
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19459/py3k-remove-old-char-compat-macros.patch

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

From report at bugs.python.org  Mon Nov  1 23:42:11 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 01 Nov 2010 22:42:11 +0000
Subject: [issue10288] Remove deprecated C "character" handling macros
	ISUPPER() etc
In-Reply-To: <1288651306.95.0.100885156034.issue10288@psf.upfronthosting.co.za>
Message-ID: <1288651331.36.0.173923832876.issue10288@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
title: Remove -> Remove deprecated C "character" handling macros ISUPPER() etc

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

From report at bugs.python.org  Tue Nov  2 00:03:35 2010
From: report at bugs.python.org (py.user)
Date: Mon, 01 Nov 2010 23:03:35 +0000
Subject: [issue10275] how to know that a module is a module,
	a function is a function ?
In-Reply-To: <1288586495.6.0.985445158981.issue10275@psf.upfronthosting.co.za>
Message-ID: <1288652615.84.0.086761573252.issue10275@psf.upfronthosting.co.za>


py.user <port139 at yandex.ru> added the comment:

Ok, thanks, I thought this is some kind of a bug

----------

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

From report at bugs.python.org  Tue Nov  2 00:05:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Nov 2010 23:05:20 +0000
Subject: [issue8805] urllib should support SSL contexts
In-Reply-To: <1274717044.09.0.580152326927.issue8805@psf.upfronthosting.co.za>
Message-ID: <1288652720.62.0.892113005545.issue8805@psf.upfronthosting.co.za>


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

Degrade; this old implementation (urllib vs urllib2) shoud be phased out IMO. This issue shows that I was myself fooled by the urllib.request documentation.

----------

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

From report at bugs.python.org  Tue Nov  2 00:06:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Nov 2010 23:06:28 +0000
Subject: [issue10287] NNTP authentication should check capabilities
In-Reply-To: <1288648592.72.0.261739190945.issue10287@psf.upfronthosting.co.za>
Message-ID: <1288652788.98.0.59223148383.issue10287@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/issue10287>
_______________________________________

From report at bugs.python.org  Tue Nov  2 00:34:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 01 Nov 2010 23:34:02 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288654442.42.0.114502418368.issue10273@psf.upfronthosting.co.za>


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

Just my 2 cents:

- I think dedocumenting the type-specific methods is fine (it doesn't mean removing them, though); or perhaps relegate them to some advanced section

- It's unfortunate that the renaming suggestion comes so late; I'm not sure it's a good idea to rename lots of things after they were introduced (although I really don't like assertRegexpMatches)

- assertIsInstance looks more natural to me than the alternative

- I don't think there's any point in undoing the package splitting, since it makes Michael's work easier and other people didn't object (not people who actively contribute to unittest, that is)

----------

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

From report at bugs.python.org  Tue Nov  2 00:54:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 01 Nov 2010 23:54:57 +0000
Subject: [issue10289] Document magic methods called by built-in functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

At the top of Doc/library/functions.rst, which documents built-in functions like abs, getattr or hash, a comment reads ?document all delegations to __special__ methods?.

Some functions are already good: enumerate for instance does link to the definition of iterator and hints about the __next__ method, format points to __format__, etc.  They can serve as example for how to add links (in plain text and in the global index).

----------
assignee: docs at python
components: Documentation
messages: 120189
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Document magic methods called by built-in functions
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Nov  2 01:01:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Nov 2010 00:01:59 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288656119.19.0.693347733571.issue10284@psf.upfronthosting.co.za>


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

That's not what you opened the bug about, though, according to the title.

I discussed the headers-in-things-other-than HEAD/ARTICLE, and Antoine was of the opinion that they were "supposed" to be utf-8 and that in any case using surrogate escape was good enough in context.  (Headers could also, of course, be MIME transfer encoded, but in that case the header decode will turn them into the correct unicode, assuming they were encoded correctly).

Perhaps this design decision needs to be revisited, but if so you'll need a different example of a problem, and so I think this ticket should remain closed and you should open a new one.

Two new ones, actually, since AUTHINFO is yet a different problem.  And given that the standard you quote specifies bytes without an encoding, there may be *no* solution that works (that is, the standard appears to be broken, since most people expect to be able to use text strings for passwords).

----------

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

From report at bugs.python.org  Tue Nov  2 01:03:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 02 Nov 2010 00:03:10 +0000
Subject: [issue10289] Document magic methods called by built-in functions
In-Reply-To: <1288655696.94.0.809001507215.issue10289@psf.upfronthosting.co.za>
Message-ID: <1288656190.53.0.0933186272062.issue10289@psf.upfronthosting.co.za>


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

?ric,

I just wanted to link to a related discussion we had under issue 8983.  See msg107689.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Tue Nov  2 01:05:33 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 02 Nov 2010 00:05:33 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1288656333.86.0.348093042163.issue10278@psf.upfronthosting.co.za>


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

Certainly.
I was going to put this simple code in time.py when I realized that time was a C module.

The main point, as Antoine points out, is that time.clock() means two seriously different things on the two main platforms, and time.clock() is potentially inadequate on one of them.

I put in the patch since it was quick to do, but I'll provoke a discussion on python-ideas for now.

----------

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

From report at bugs.python.org  Tue Nov  2 01:18:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 02 Nov 2010 00:18:58 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288656333.86.0.348093042163.issue10278@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=5G=Wtfvwad4jHRRDocNWU10_gK84s-_=nqOsk@mail.gmail.com>


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

2010/11/1 Kristj?n Valur J?nsson <report at bugs.python.org>:
..
> I put in the patch since it was quick to do, but I'll provoke a discussion
> on python-ideas for now.

I am looking forward to it.  You may find reviewing the following
issues helpful for your case: #9079, #2736, and #9528.

----------

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

From report at bugs.python.org  Tue Nov  2 01:22:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Nov 2010 00:22:24 +0000
Subject: [issue10282] IMPLEMENTATION token differently delt with in NNTP
	capability
In-Reply-To: <1288642567.32.0.7785411032.issue10282@psf.upfronthosting.co.za>
Message-ID: <1288657344.12.0.82582749656.issue10282@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov  2 01:24:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Nov 2010 00:24:16 +0000
Subject: [issue10283] New parameter for an NNTP newsgroup pattern in LIST
	ACTIVE
In-Reply-To: <1288642864.21.0.311033761057.issue10283@psf.upfronthosting.co.za>
Message-ID: <1288657456.58.0.00793927515472.issue10283@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov  2 01:25:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 02 Nov 2010 00:25:02 +0000
Subject: [issue10285] Other status field flags in documentation for NNTP LIST
	command
In-Reply-To: <1288643123.11.0.762395184057.issue10285@psf.upfronthosting.co.za>
Message-ID: <1288657502.13.0.0423600215779.issue10285@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov  2 01:28:59 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Nov 2010 00:28:59 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288657739.43.0.106896228103.issue10273@psf.upfronthosting.co.za>


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

[Antoine]
> I would prefer assertRegex to assertRegexp

That makes sense.  It is the name used in other unittest implementations, it matches what the re module used to be called in Python, and it avoids issues with camel casing (i.e. Regexp vs RegExp).

----------

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

From report at bugs.python.org  Tue Nov  2 01:29:13 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 02 Nov 2010 00:29:13 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>
Message-ID: <1288657753.33.0.884410299435.issue10260@psf.upfronthosting.co.za>


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

Good points, Jeffrey.  Documentation can be improved and cond.wait_for(pred) is indeed not guaranteed to wake up when predicate is true unless someone calls notifyAll.

I spent some time thinking of a name.  I tried wait_predicate and predicate_wait, but wait_for seemed natural.  Any other ideas?
How about wait_until_true?

My original method had this as a free function, but I moved it into the Condition because I could see no other kind of primitive that would use it.  I agree that it is unfortunate to pull what is essentially a utility function into the Condition variable, so I am leaning towards keeping it a module function.

----------

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

From report at bugs.python.org  Tue Nov  2 01:29:17 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Nov 2010 00:29:17 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288657757.43.0.589890082692.issue10273@psf.upfronthosting.co.za>


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


----------
assignee: michael.foord -> rhettinger

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

From report at bugs.python.org  Tue Nov  2 01:51:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Nov 2010 00:51:39 +0000
Subject: [issue10290] Fix resource warnings in distutils
In-Reply-To: <1288659099.71.0.79415360493.issue10290@psf.upfronthosting.co.za>
Message-ID: <1288659099.71.0.79415360493.issue10290@psf.upfronthosting.co.za>


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

The attached patch cleans up the numerous ResourceWarning messages that distutils test runs generate. The changes basically just close all open files - some in the test suite, some in the library code.
No context managers were used since distutils appears in PEP 291 as requiring 2.3 support.

----------
assignee: tarek
components: Distutils, Library (Lib), Tests
messages: 120196
nosy: brian.curtin, eric.araujo, tarek
priority: normal
severity: normal
stage: patch review
status: open
title: Fix resource warnings in distutils
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov  2 01:52:43 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Nov 2010 00:52:43 +0000
Subject: [issue10290] Fix resource warnings in distutils
In-Reply-To: <1288659099.71.0.79415360493.issue10290@psf.upfronthosting.co.za>
Message-ID: <1288659163.22.0.628782122702.issue10290@psf.upfronthosting.co.za>


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

Wow, I should open my eyes. Dupe of #10252

----------
assignee: tarek -> 
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Nov  2 02:01:13 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 02 Nov 2010 01:01:13 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1288659673.4.0.374910174587.issue10252@psf.upfronthosting.co.za>


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

The patch shouldn't use context managers, as distutils claims to support 2.3. #10290 contains a similar patch which doesn't use 'with'. (Sorry to duplicate efforts here, forgot to search...)

----------
nosy: +brian.curtin
status: pending -> open

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

From report at bugs.python.org  Tue Nov  2 02:40:18 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Nov 2010 01:40:18 +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: <1288662018.68.0.386196482119.issue10242@psf.upfronthosting.co.za>


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

On Python-dev Nick Coghlan suggests a fix for the fast-path that would allow us to keep it whilst fixing this bug (not tested yet but adding this note not to lose it). The issue of the name of this method is in 10273.


Looking at assertItemsEqual, I'd be inclined to insert a check that falls back to the "unorderable_list_difference" approach in the case where "expected != sorted(reversed(expected))".

As far as I can tell, that check is a valid partial ordering detector
for any sequence that contains one or more pairs of items for which
LT, EQ and GE are all False:

>>> seq = [{1}, {2}]
>>> seq[0] < seq[1]
False
>>> seq[0] == seq[1]
False
>>> seq[0] > seq[1]
False
>>> sorted(seq)
[{1}, {2}]
>>> sorted(reversed(sorted(seq)))
[{2}, {1}]

Obviously, if the sequence doesn't contain any such items (e.g. all
subsets of each other), then it will look like a total ordering and
use the fast path. I see that as an upside :)

----------

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

From report at bugs.python.org  Tue Nov  2 03:03:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 02 Nov 2010 02:03:32 +0000
Subject: [issue10291] Clean-up turtledemo in-package documentation
In-Reply-To: <1288663412.18.0.821423720263.issue10291@psf.upfronthosting.co.za>
Message-ID: <1288663412.18.0.821423720263.issue10291@psf.upfronthosting.co.za>


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

Since after closing of issue #10199, docstrings in demo scripts are accessible to pydoc, it is important to bring them up to date.  For example, turtledemo.wikipedia docstring contains a reference to nonexistent wikipedia1 and calls itself tdemo_wikipedia3.py.

In addition, the turtledemo package contains three text files: Lib/turtledemo/about_turtle.txt, Lib/turtledemo/about_turtledemo.txt, and Lib/turtledemo/demohelp.txt.  The contents of these files should be moved to appropriate (doc)strings inside appropriate .py files.

----------
assignee: belopolsky
components: Demos and Tools, Documentation
keywords: easy
messages: 120200
nosy: belopolsky, eric.araujo, georg.brandl, glingl, gregorlingl, gvanrossum, ned.deily, r.david.murray, rhettinger, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Clean-up turtledemo in-package documentation
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov  2 03:39:42 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Nov 2010 02:39:42 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288665582.06.0.352086480713.issue10273@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just sent an email to python-dev, but since this issue sparked it, I might as well comment here: unittest shouldn't be made back into a single module.

Ignoring the fact that the file structure has nothing to do with the public API and so is orthogonal to the main thrust of this issue, changing it back will break imports in code from Python 2.7 that uses the more modular structure that now underlies unittest. Considering how much whining we get about code breakage any time Michael tries to fix anything in the module I think this is the last thing anyone wants to have happen.

----------
nosy: +brett.cannon

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

From report at bugs.python.org  Tue Nov  2 03:49:47 2010
From: report at bugs.python.org (Jacques Grove)
Date: Tue, 02 Nov 2010 02:49: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: <1288666187.24.0.0719987410046.issue2636@psf.upfronthosting.co.za>


Jacques Grove <jacques at tripitinc.com> added the comment:

OK, I think this might be the last one I will find for the moment:

$ cat test.py
import re, regex

text = "test?"
regexp = "test\?"
sub_value = "result\?"
print repr(re.sub(regexp, sub_value, text))
print repr(regex.sub(regexp, sub_value, text))


$ python test.py
'result\\?'
'result?'

----------

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

From report at bugs.python.org  Tue Nov  2 04:51:36 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 02 Nov 2010 03:51:36 +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: <1288669896.09.0.540564558078.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101102.zip is a new version of the regex module.

----------
Added file: http://bugs.python.org/file19460/issue2636-20101102.zip

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

From report at bugs.python.org  Tue Nov  2 05:08:02 2010
From: report at bugs.python.org (Jacques Grove)
Date: Tue, 02 Nov 2010 04:08:02 +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: <1288670882.84.0.0142930399135.issue2636@psf.upfronthosting.co.za>


Jacques Grove <jacques at tripitinc.com> added the comment:

Spoke too soon, although this might be a valid divergence in behavior:

$ cat test.py 
import re, regex

text = "test: 2"

print regex.sub('(test)\W+(\d+)(?:\W+(TEST)\W+(\d))?', '\\2 \\1, \\4 \\3', text)
print re.sub('(test)\W+(\d+)(?:\W+(TEST)\W+(\d))?', '\\2 \\1, \\4 \\3', text)


$ python test.py 
2 test,  
Traceback (most recent call last):
  File "test.py", line 6, in <module>
    print re.sub('(test)\W+(\d+)(?:\W+(TEST)\W+(\d))?', '\\2 \\1, \\4 \\3', text)
  File "/usr/lib64/python2.7/re.py", line 151, in sub
    return _compile(pattern, flags).sub(repl, string, count)
  File "/usr/lib64/python2.7/re.py", line 278, in filter
    return sre_parse.expand_template(template, match)
  File "/usr/lib64/python2.7/sre_parse.py", line 787, in expand_template
    raise error, "unmatched group"
sre_constants.error: unmatched group

----------

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

From report at bugs.python.org  Tue Nov  2 05:38:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Nov 2010 04:38:02 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1288672682.28.0.289967377517.issue10278@psf.upfronthosting.co.za>


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

I would also be nice to have a "monotonic" clock in Python. See monotonic.py for an example. But I don't know if it solves the same problem than time.wallclock() or not. I need a monotonic clock for a server on which NTP is sometimes called to resynchronize the system clock (and the NTP server may be change by the user).

----------
nosy: +haypo
Added file: http://bugs.python.org/file19461/monotonic.py

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

From report at bugs.python.org  Tue Nov  2 05:52:20 2010
From: report at bugs.python.org (Jacques Grove)
Date: Tue, 02 Nov 2010 04:52:20 +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: <1288673540.59.0.224029022463.issue2636@psf.upfronthosting.co.za>


Jacques Grove <jacques at tripitinc.com> added the comment:

Another, with backreferences:

import re, regex

text = "TEST, BEST; LEST ; Lest 123 Test, Best"
regexp = "(?i)(.{1,40}?),(.{1,40}?)(?:;)+(.{1,80}).{1,40}?\\3(\ |;)+(.{1,80}?)\\1"
print re.findall(regexp, text)
print regex.findall(regexp, text)

$ python test.py 
[('TEST', ' BEST', ' LEST', ' ', '123 ')]
[('T', ' BEST', ' ', ' ', 'Lest 123 ')]

----------

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

From report at bugs.python.org  Tue Nov  2 05:54:46 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 02 Nov 2010 04:54:46 +0000
Subject: [issue10278] add time.wallclock() method
In-Reply-To: <1288624210.23.0.0497533122542.issue10278@psf.upfronthosting.co.za>
Message-ID: <1288673686.1.0.319456699072.issue10278@psf.upfronthosting.co.za>


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

Well, that is sort of what I'm trying to achieve.  Note that you probably want to use QueryPerformaceCounter on windows (or simply time.clock()) or at least GetTickCount64 which doesn't wrap around after 50 days :).  Also, I'm trying to get the highest resolution possible...

----------

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

From report at bugs.python.org  Tue Nov  2 06:58:12 2010
From: report at bugs.python.org (JP St. Pierre)
Date: Tue, 02 Nov 2010 05:58:12 +0000
Subject: [issue10292] tarinfo should use relative symlinks
In-Reply-To: <1288677491.56.0.490634807811.issue10292@psf.upfronthosting.co.za>
Message-ID: <1288677491.56.0.490634807811.issue10292@psf.upfronthosting.co.za>


New submission from JP St. Pierre <jstpierre at mecheye.net>:

With all the tools I've used, the target of a symlink appears to be relative to the actual symlink entry. Fix this.

----------
components: Library (Lib)
messages: 120208
nosy: magcius
priority: normal
severity: normal
status: open
title: tarinfo should use relative symlinks
versions: Python 2.7

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

From report at bugs.python.org  Tue Nov  2 06:59:07 2010
From: report at bugs.python.org (JP St. Pierre)
Date: Tue, 02 Nov 2010 05:59:07 +0000
Subject: [issue10292] tarinfo should use relative symlinks
In-Reply-To: <1288677491.56.0.490634807811.issue10292@psf.upfronthosting.co.za>
Message-ID: <1288677547.99.0.890838003162.issue10292@psf.upfronthosting.co.za>


Changes by JP St. Pierre <jstpierre at mecheye.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19462/tarinfo-10292.diff

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

From report at bugs.python.org  Tue Nov  2 07:44:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 02 Nov 2010 06:44:05 +0000
Subject: [issue10292] tarinfo should use relative symlinks
In-Reply-To: <1288677491.56.0.490634807811.issue10292@psf.upfronthosting.co.za>
Message-ID: <1288680245.27.0.21933204998.issue10292@psf.upfronthosting.co.za>


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


----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

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

From report at bugs.python.org  Tue Nov  2 09:38:34 2010
From: report at bugs.python.org (Andrew Vant)
Date: Tue, 02 Nov 2010 08:38:34 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288687114.88.0.948001871059.issue1926@psf.upfronthosting.co.za>


Andrew Vant <ajvant at gmail.com> added the comment:

At Antoine's suggestion I've written a new patch for this for 3.2, adding support for both SSL on 563 and STARTTLS on a normal connection. A NNTP_SSL class supports the former and a NNTP.starttls() method supports the latter. As a side effect of getting starttls working I had to add a NNTP.login() method as well. (see below)

The patch updates nntplib.py, test_nntplib.py, nntplib.rst, and Misc/NEWS. 

Some implementation notes: 

By default, NNTP objects attempt to log in during initialization,and there didn't seem to be any support for logging in later. This was a problem as STARTTLS has to be issued before logging in. In order to get around this and handle a STARTTLS nuance involving CAPABILITIES, I moved the authentication part of _NNTPBase.__init__ into a method of its own, NNTP.login(), and another piece of it into NNTP.getcapabilities(). This doesn't affect the observable behavior of NNTP() or the existing methods.

As a side note, IMHO NNTP shouldn't attempt to log in at initialization at all. The user, password, and usenetrc args should not be part of the constructors and the program using the library should be able to choose when or if to log in after connecting. I couldn't think of any way to do this without breaking existing programs, though. At the very least I think usenetrc should default to False, but that would break programs that rely on the default behavior too, I think. 

I updated the test cases, with a caveat. They use gmane to perform the tests. Gmane doesn't support starttls. Therefor the tests currently only check for correct failure rather than correct success. There's test code for the starttls() method but it never runs. I checked the functionality against eternal-september to be sure it does, in fact, correctly succeed as well, but I'm not about to put my login details in the automatic test script. ;-) 

The NNTPS-on-563 test, OTOH, works exactly like the existing NNTP test and seems to work fine. It was a hell of a lot easier to implement that part too.

Hope I didn't miss anything. First time doing this for a public project. Apparently the personal-itch theory is correct.

<click>

----------
nosy: +ajvant
Added file: http://bugs.python.org/file19463/python_nntp_ssl_patch1.diff

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

From report at bugs.python.org  Tue Nov  2 09:43:47 2010
From: report at bugs.python.org (Andrew Vant)
Date: Tue, 02 Nov 2010 08:43:47 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288687427.67.0.76985031712.issue1926@psf.upfronthosting.co.za>


Andrew Vant <ajvant at gmail.com> added the comment:

Also, Julien: Thanks for mentioning the 563-discouraged thing. I added a note about it to the new documentation before submitting.

----------

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

From report at bugs.python.org  Tue Nov  2 10:26:36 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 02 Nov 2010 09:26:36 +0000
Subject: [issue10293] PyMemoryView object has obsolete members
In-Reply-To: <1288689996.27.0.790374524403.issue10293@psf.upfronthosting.co.za>
Message-ID: <1288689996.27.0.790374524403.issue10293@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The PyMemoryObject has a "base" member which appears to be obsolete.  Furthermore, the function do_release() attempt to perform some obsolete-looking woodo with base if it happens to be a tuple.  Looks dangerous.

----------
components: Interpreter Core
messages: 120211
nosy: krisvale
priority: normal
severity: normal
status: open
title: PyMemoryView object has obsolete members
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov  2 10:50:24 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Nov 2010 09:50:24 +0000
Subject: [issue10288] Remove
In-Reply-To: <1288651306.95.0.100885156034.issue10288@psf.upfronthosting.co.za>
Message-ID: <4CCFDEDB.2020804@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Dave Malcolm wrote:
> 
> New submission from Dave Malcolm <dmalcolm at redhat.com>:
> 
> Issue 5793 rationalized all usage of C "character" handling to use "Py_"-prefixed locale-unaware macros, at the "char" level.
> 
> In particular, this comment was added in two places to Include/bytes_methods.h in r72044:
> http://svn.python.org/view/python/branches/py3k/Include/bytes_methods.h?view=diff&r1=72043&r2=72044
> 
>   /* These are left in for backward compatibility and will be removed
>   in 2.8/3.2 */
> 
> Given that 3.2 is coming soon, is it time to remove these?  (also, the reference to "2.8" caught my eye)

+1

> Attached is a patch to py3k which removes them, and fixes up various users that were still in the source tree.
> 
> Am I right in thinking that the undef and redefinition of the various lower-case macros from <ctype.h> was already intended to be removed? (given that this messes about with a standard C library)

Please remove those as well. I suppose those were mainly used to find
instances of islower() et al. in the source code.

----------
nosy: +lemburg
title: Remove deprecated C "character" handling macros ISUPPER() etc -> Remove

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

From report at bugs.python.org  Tue Nov  2 11:28:34 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 02 Nov 2010 10:28:34 +0000
Subject: [issue10086] test_sysconfig failure with site-packages
In-Reply-To: <1287422116.51.0.705691169894.issue10086@psf.upfronthosting.co.za>
Message-ID: <hbf.20101102lh05@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

,AC?ric Araujo writes:
> Attaching a patch with your two suggestions.
> Added file: http://bugs.python.org/file19264/fix10086.diff

Not quite, since I suggested
   global_path.startswith(os.path.join(base, ""))
instead of
   global_path.startswith(base)

I should have mentioned, the join appends a directory terminator
to base.  Not sure if that's the correct way to do it.  Anyway,
your patch does not catch a similar failure (if this can happen):

   base        = "/site"
   global_path = "/site-nonsense/..."

----------

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

From report at bugs.python.org  Tue Nov  2 11:32:45 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 02 Nov 2010 10:32:45 +0000
Subject: [issue10288] Remove deprecated C "character" handling macros
	ISUPPER() etc
In-Reply-To: <1288651306.95.0.100885156034.issue10288@psf.upfronthosting.co.za>
Message-ID: <1288693965.56.0.600754215918.issue10288@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
title: Remove -> Remove deprecated C "character" handling macros ISUPPER() etc

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

From report at bugs.python.org  Tue Nov  2 12:29:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 11:29:04 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1288657753.33.0.884410299435.issue10260@psf.upfronthosting.co.za>
Message-ID: <1288697339.3549.1.camel@localhost.localdomain>


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

> I spent some time thinking of a name.  I tried wait_predicate and
> predicate_wait, but wait_for seemed natural.  Any other ideas?
> How about wait_until_true?

wait_for is ok IMO.

> My original method had this as a free function, but I moved it into
> the Condition because I could see no other kind of primitive that
> would use it.  I agree that it is unfortunate to pull what is
> essentially a utility function into the Condition variable, so I am
> leaning towards keeping it a module function.

I'm not sure I see the point. It's an operation on a Condition variable,
so it's natural to have it as a Condition method. A module function
would feel rather weird.

----------

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

From report at bugs.python.org  Tue Nov  2 12:56:07 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Tue, 02 Nov 2010 11:56:07 +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: <1288698967.27.0.673022040104.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

There seems to be a bug in the handling of numbered backreferences in sub() in
issue2636-20101102.zip
I believe, it would be a fairly new regression, as it would be noticed rather soon.
(tested on Python 2.7; winXP)

>>> re.sub("([xy])", "-\\1-", "abxc")
'ab-x-c'
>>> regex.sub("([xy])", "-\\1-", "abxc")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\regex.py", line 176, in sub
    return _compile(pattern, flags).sub(repl, string, count, pos, endpos)
  File "C:\Python27\lib\regex.py", line 375, in _compile_replacement
    compiled.extend(items)
TypeError: 'int' object is not iterable
>>>

vbr

----------

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

From report at bugs.python.org  Tue Nov  2 13:08:15 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Tue, 02 Nov 2010 12:08:15 +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: <1288699695.04.0.504912510142.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Sorry for the noise, please, forgot my previous msg120215;
I somehow managed to keep an older version of _regex_core.py along with the new regex.py in the Lib directory, which are obviously incompatible.
After updating the files correctly, the mentioned examples work correctly.

vbr

----------

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

From report at bugs.python.org  Tue Nov  2 13:42:43 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Nov 2010 12:42:43 +0000
Subject: [issue4510] ValueError for list.remove() not very helpful
In-Reply-To: <1228347518.63.0.0108612017272.issue4510@psf.upfronthosting.co.za>
Message-ID: <1288701763.57.0.107334568799.issue4510@psf.upfronthosting.co.za>


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

This has already been implemented.

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

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

From report at bugs.python.org  Tue Nov  2 13:43:30 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Nov 2010 12:43:30 +0000
Subject: [issue7266] test_lib2to3 failure under Windows
In-Reply-To: <1257433591.14.0.555852020916.issue7266@psf.upfronthosting.co.za>
Message-ID: <1288701810.38.0.543663115815.issue7266@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov  2 13:45:47 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Nov 2010 12:45:47 +0000
Subject: [issue9796] Add summary tables for unittest API
In-Reply-To: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>
Message-ID: <1288701947.21.0.399941688156.issue9796@psf.upfronthosting.co.za>


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

issue9796-3.diff improves the rendering of the HTML tables. (Note: the patch just adds the tables, short paragraphs before them and moves a few methods around to match the division and the order of the tables, without changing their content.)

----------
components: +Tests
Added file: http://bugs.python.org/file19464/issue9796-3.diff

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

From report at bugs.python.org  Tue Nov  2 13:51:09 2010
From: report at bugs.python.org (Steven Bethard)
Date: Tue, 02 Nov 2010 12:51:09 +0000
Subject: [issue9340] argparse parse_known_args does not work with subparsers
In-Reply-To: <1279886405.92.0.918578525345.issue9340@psf.upfronthosting.co.za>
Message-ID: <1288702269.43.0.0953130765205.issue9340@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Fixed with a variant of Catherine's patch (following R. David Murray's suggestion of inlining the two methods) in r86111 (3.X) and r86112 (2.7). Also added one more test to make sure that the order of the extra arguments is consistent (extra arguments from main parser before extra arguments from subparser).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.1

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

From report at bugs.python.org  Tue Nov  2 14:11:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Nov 2010 13:11:39 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288703499.42.0.049258156035.issue10273@psf.upfronthosting.co.za>


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

FWIW in addition to assertRegexpMatches and assertNotRegexpMatches there are 2 more methods that use "Regexp": assertRaisesRegexp and the newly introduced assertWarnsRegexp.

----------
components: +Tests

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

From report at bugs.python.org  Tue Nov  2 14:14:54 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 02 Nov 2010 13:14:54 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288703694.89.0.823920882445.issue10273@psf.upfronthosting.co.za>


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

@Ezio

Good catch. Even though several of us (including myself) prefer assertRegex over assertRegexp it is probably better to have consistent APIs otherwise people will never remember which methods have the 'p' and which don't.

----------

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

From report at bugs.python.org  Tue Nov  2 14:17:35 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Nov 2010 13:17:35 +0000
Subject: [issue7826] support caching for 2to3
In-Reply-To: <1264985952.93.0.779639488883.issue7826@psf.upfronthosting.co.za>
Message-ID: <1288703855.81.0.660244632762.issue7826@psf.upfronthosting.co.za>


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

I'm going to reject this for now.

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

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

From report at bugs.python.org  Tue Nov  2 14:51:11 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 02 Nov 2010 13:51:11 +0000
Subject: [issue10288] Remove deprecated C "character" handling macros
	ISUPPER() etc
In-Reply-To: <1288651306.95.0.100885156034.issue10288@psf.upfronthosting.co.za>
Message-ID: <1288705871.11.0.269106444809.issue10288@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

+1

I agree on removing the lowercase versions. It's sort of handy having them around to prevent accidental uses. But the same could be said for other similar macros/functions. Plus they wouldn't work if the isXXX symbols were really functions, not macros (not that I know if that's even allowed by the standard).

The patch looks okay to me, although I didn't actually compile and run the tests. You'll find out soon enough! The issue number in the NEWS entry needs to be fixed, of course.

Thanks for doing this, Dave.

----------

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

From report at bugs.python.org  Tue Nov  2 15:18:26 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 02 Nov 2010 14:18:26 +0000
Subject: [issue10292] tarinfo should use relative symlinks
In-Reply-To: <1288677491.56.0.490634807811.issue10292@psf.upfronthosting.co.za>
Message-ID: <1288707506.17.0.186573919193.issue10292@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Apparently you were in quite a hurry when you filed this bug report.

- What is the exact problem and how does it manifest itself?
- Any helpful details (tracebacks, output)?
- Is there a testcase or example code you can provide?
- Which other tools are you talking about?
- Your patch is faulty (upperdir is undefined).
- The patch does not apply to neither r27 tag nor release27-maint branch although you claim that 2.7 is affected.
- Which exact Python version are you using on what platform?
- Oh, and a little more politeness wouldn't hurt.

Okay, so please ask again. I am curious to see what you've found.

----------

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

From report at bugs.python.org  Tue Nov  2 15:36:14 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 02 Nov 2010 14:36:14 +0000
Subject: [issue7292] Multiprocessing Joinable race condition?
In-Reply-To: <1257748286.94.0.346139031927.issue7292@psf.upfronthosting.co.za>
Message-ID: <1288708574.55.0.000473496104026.issue7292@psf.upfronthosting.co.za>


Changes by Ask Solem <askh at opera.com>:


----------
nosy: +asksol

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

From report at bugs.python.org  Tue Nov  2 15:37:27 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 02 Nov 2010 14:37:27 +0000
Subject: [issue5930] Transient error in multiprocessing
	(test_number_of_objects)
In-Reply-To: <1241472804.71.0.981647805709.issue5930@psf.upfronthosting.co.za>
Message-ID: <1288708647.28.0.677337556277.issue5930@psf.upfronthosting.co.za>


Changes by Ask Solem <askh at opera.com>:


----------
nosy: +asksol

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

From report at bugs.python.org  Tue Nov  2 15:37:51 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 02 Nov 2010 14:37:51 +0000
Subject: [issue10267] test_ttk_guionly leaks many references
In-Reply-To: <1288542306.75.0.249495592657.issue10267@psf.upfronthosting.co.za>
Message-ID: <1288708671.01.0.606327103531.issue10267@psf.upfronthosting.co.za>


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

It seems this issue can be fixed by attached patch.

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file19465/py3k_fix_test_ttk_guionly_refleak.patch

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

From report at bugs.python.org  Tue Nov  2 15:41:52 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 02 Nov 2010 14:41:52 +0000
Subject: [issue9733] Can't iterate over multiprocessing.managers.DictProxy
In-Reply-To: <1283349080.83.0.871806054056.issue9733@psf.upfronthosting.co.za>
Message-ID: <1288708912.24.0.680893033077.issue9733@psf.upfronthosting.co.za>


Changes by Ask Solem <askh at opera.com>:


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

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

From report at bugs.python.org  Tue Nov  2 15:44:06 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 02 Nov 2010 14:44:06 +0000
Subject: [issue3876] multiprocessing does not compile on systems which do not
	define sem_timedwait
In-Reply-To: <1221541852.59.0.453473189868.issue3876@psf.upfronthosting.co.za>
Message-ID: <1288709046.36.0.024550286526.issue3876@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

What is the status of this issue?  There are several platform listed here, which I unfortunately don't have access to.

----------
nosy: +asksol

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

From report at bugs.python.org  Tue Nov  2 15:51:19 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 02 Nov 2010 14:51:19 +0000
Subject: [issue9955] multiprocessing.Pipe segmentation fault when recv of
	unpicklable object
In-Reply-To: <1285527695.71.0.573625122377.issue9955@psf.upfronthosting.co.za>
Message-ID: <1288709479.59.0.758166881831.issue9955@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Can't reproduce on Python 2.7, but can indeed reproduce on 2.6.  Issue fixed?

----------

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

From report at bugs.python.org  Tue Nov  2 15:57:35 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 02 Nov 2010 14:57:35 +0000
Subject: [issue10133] multiprocessing: conn_recv_string() broken error handling
In-Reply-To: <1287346495.15.0.809946654619.issue10133@psf.upfronthosting.co.za>
Message-ID: <1288709855.2.0.17132932594.issue10133@psf.upfronthosting.co.za>


Changes by Ask Solem <askh at opera.com>:


----------
nosy: +asksol

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

From report at bugs.python.org  Tue Nov  2 15:59:30 2010
From: report at bugs.python.org (Jasper St. Pierre)
Date: Tue, 02 Nov 2010 14:59:30 +0000
Subject: [issue10292] tarinfo should use relative symlinks
In-Reply-To: <1288677491.56.0.490634807811.issue10292@psf.upfronthosting.co.za>
Message-ID: <1288709970.4.0.0407902568175.issue10292@psf.upfronthosting.co.za>


Jasper St. Pierre <jstpierre at mecheye.net> added the comment:

Oh man, attaching the wrong diff and getting the diff wrong.

The issue I found with Python 2.7:

when creating a simple link in tar:

$ mkdir tar_test
$ cd tar_test
$ touch one
$ ln -s one two
$ cd ..
$ tar czf tar_test.tgz tar_test

It seems obvious that there would be a relative link in the tar file:

-rwxrwxrwx jstpierre/me 2010-11-02 10:57:15 tar_test/two -> one

Unfortunately, as far as I can tell, tarfile treats this as an absolute path, and fails when extracting:

>>> tf.extractfile("tar_test/two")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/tarfile.py", line 2122, in extractfile
    tarinfo))
  File "/usr/lib/python2.6/tarfile.py", line 2105, in extractfile
    if tarinfo.isreg():
AttributeError: 'NoneType' object has no attribute 'isreg'

I was trying to fix that.

----------

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

From report at bugs.python.org  Tue Nov  2 16:16:14 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 02 Nov 2010 15:16:14 +0000
Subject: [issue8028] self.terminate() from a multiprocessing.Process raises
	AttributeError exception
In-Reply-To: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za>
Message-ID: <1288710974.23.0.602971353125.issue8028@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

It seems that Process.terminate is not meant to be used by the child, but only the parent.

>From the documentation:

  "Note that the start(), join(), is_alive() and exit_code methods
  should only be called by the process that created the process object."

Either terminate() should be added to this list,
or terminate should be patch to call sys.exit in a child process.

I vote for the former, so I attached a doc patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file19466/i8028.patch

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

From report at bugs.python.org  Tue Nov  2 16:28:10 2010
From: report at bugs.python.org (Jasper St. Pierre)
Date: Tue, 02 Nov 2010 15:28:10 +0000
Subject: [issue10292] tarinfo should use relative symlinks
In-Reply-To: <1288677491.56.0.490634807811.issue10292@psf.upfronthosting.co.za>
Message-ID: <1288711690.86.0.0124783063088.issue10292@psf.upfronthosting.co.za>


Jasper St. Pierre <jstpierre at mecheye.net> added the comment:

Uh, I just noticed the "python2.6" in the traceback.

Looks like I *was* using 2.6 because Cygwin decided
to downgrade for some reason.

Uh, sorry about that.

----------

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

From report at bugs.python.org  Tue Nov  2 16:33:07 2010
From: report at bugs.python.org (Nik Tautenhahn)
Date: Tue, 02 Nov 2010 15:33:07 +0000
Subject: [issue10038] json.loads() on str should return unicode, not str
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1288711987.81.0.567678697514.issue10038@psf.upfronthosting.co.za>


Nik Tautenhahn <nik at livinglogic.de> added the comment:

There is even more inconsistency here.

As already mentioned, we have this:


>>> import json
>>> json.loads(json.dumps("abc"))

'abc'

If, however, I am evil and hide _json.so (which is the C-part of the json module for speedup), the JSON code falls back to its python implementation and voila:

>>> import json
>>> json.loads(json.dumps("abc"))

u'abc'

Not so neat, if your fallback is not a fallback but shows such different behaviour.

----------

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

From report at bugs.python.org  Tue Nov  2 16:33:31 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 02 Nov 2010 15:33:31 +0000
Subject: [issue5573] multiprocessing Pipe poll() and recv() semantics.
In-Reply-To: <1238096312.97.0.564685442594.issue5573@psf.upfronthosting.co.za>
Message-ID: <1288712011.77.0.385540622735.issue5573@psf.upfronthosting.co.za>


Changes by Ask Solem <askh at opera.com>:


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

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

From report at bugs.python.org  Tue Nov  2 16:40:19 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 02 Nov 2010 15:40:19 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1288712419.08.0.832685055582.issue8037@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Pickling on put makes sense to me.  I can't think of cases where this could break existing code either.  I think this may also resolve issue 8323

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

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

From report at bugs.python.org  Tue Nov  2 16:41:45 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 02 Nov 2010 15:41:45 +0000
Subject: [issue10038] json.loads() on str should return unicode, not str
In-Reply-To: <1288711987.81.0.567678697514.issue10038@psf.upfronthosting.co.za>
Message-ID: <AANLkTimGMujJjZd2WcpaFKhwJV6JW56gqUv_Ue7NY3uz@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Alternately, the Python implementation may be thought of as definitive
and the optimizations are broken.

----------

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

From report at bugs.python.org  Tue Nov  2 16:42:58 2010
From: report at bugs.python.org (qpatata)
Date: Tue, 02 Nov 2010 15:42:58 +0000
Subject: [issue9919] gdbinit lineno result is one line in excess
In-Reply-To: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>
Message-ID: <1288712578.13.0.256686759013.issue9919@psf.upfronthosting.co.za>


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

I'm sorry, I've not explained correctly.

I'm wondering if the addition of the \n is ok or not, taken into account that it breaks the format of the "pyframe" macro output. It could be better to keep the older version (without the \n").

Kind regards.

----------

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

From report at bugs.python.org  Tue Nov  2 17:05:16 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 02 Nov 2010 16:05:16 +0000
Subject: [issue9796] Add summary tables for unittest API
In-Reply-To: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>
Message-ID: <1288713916.92.0.647060271403.issue9796@psf.upfronthosting.co.za>


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

Updated patch after the changes made in r86118.

----------
Added file: http://bugs.python.org/file19467/issue9796-4.diff

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

From report at bugs.python.org  Tue Nov  2 17:09:49 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Tue, 02 Nov 2010 16:09:49 +0000
Subject: [issue10294] Lib/test/test_unicode_file.py contains dead code
In-Reply-To: <1288714188.98.0.557257896773.issue10294@psf.upfronthosting.co.za>
Message-ID: <1288714188.98.0.557257896773.issue10294@psf.upfronthosting.co.za>


New submission from Stefan Behnel <scoder at users.sourceforge.net>:

Lib/test/test_unicode_file.py contains dead code:

    def _test_equivalent(self, filename1, filename2):
        remove_if_exists(filename1)
        self.assertTrue(not os.path.exists(filename2))
        f = file(filename1, "w")
        f.close()
        try:
            self._do_equivalent(filename1, filename2)
        finally:
            os.unlink(filename1)

Note how this refers to the now-gone "file()". The method is never used in the test code. Similarly, the "_do_equivalent()" method that it calls appears otherwise unused.

----------
components: Tests
messages: 120236
nosy: scoder
priority: normal
severity: normal
status: open
title: Lib/test/test_unicode_file.py contains dead code
versions: Python 3.2

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

From report at bugs.python.org  Tue Nov  2 17:15:10 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 02 Nov 2010 16:15:10 +0000
Subject: [issue10038] json.loads() on str should return unicode, not str
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1288714510.61.0.056228589077.issue10038@psf.upfronthosting.co.za>


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

The following patch (against the release27-maint branch) seems to fix the problem.

----------
keywords: +patch
nosy: +doerwalter
Added file: http://bugs.python.org/file19468/json.diff

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

From report at bugs.python.org  Tue Nov  2 17:17:57 2010
From: report at bugs.python.org (Ron Adam)
Date: Tue, 02 Nov 2010 16:17:57 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1288714677.92.0.380160207566.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Nick, I can update the patch and move the server back into pydoc.py if that will help you get this into 3.2 beta.

I can also changed the docstrings of the new parts to # comments.

----------

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

From report at bugs.python.org  Tue Nov  2 18:05:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 17:05:39 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288717539.98.0.790128608117.issue1926@psf.upfronthosting.co.za>


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

Andrew, thank you for posting a patch.
I have a couple of comments:

* the command-line option for the SSLContext won't work, since a context is a custom object, not a string; I would rework this part anyway, since I don't think separate options for the "SSL host" are useful (I'd rather add a SSL-enabling flag; also, STARTTLS can be queried from the capabilities)

* on a stylistic note, there are a couple of places where you use tabs for indentation; also, comments should have a space after the '#' ('# xxx' and not '#xxx')

* not moving methods around (such as getwelcome) would make it easier to review the real changes

* in test_starttls, I would clearly report that the server doesn't support STARTTLS, e.g.:

            except nntplib.NNTPPermanentError:
                self.skip("STARTTLS not supported by server")

* starttls() should probably test the `tls_on` attribute first and raise a ValueError if True (as you point out, a client mustn't attempt to start a new TLS session if one is already active).


All in all, it looks good though.

----------

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

From report at bugs.python.org  Tue Nov  2 18:20:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 17:20:36 +0000
Subject: [issue10267] test_ttk_guionly leaks many references
In-Reply-To: <1288542306.75.0.249495592657.issue10267@psf.upfronthosting.co.za>
Message-ID: <1288718436.65.0.615595417982.issue10267@psf.upfronthosting.co.za>


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

Hirokazu's patch works for me.

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

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

From report at bugs.python.org  Tue Nov  2 18:21:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 17:21:28 +0000
Subject: [issue10294] Lib/test/test_unicode_file.py contains dead code
In-Reply-To: <1288714188.98.0.557257896773.issue10294@psf.upfronthosting.co.za>
Message-ID: <1288718488.36.0.0823926959862.issue10294@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov  2 18:25:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 17:25:39 +0000
Subject: [issue9635] Add Py_BREAKPOINT and sys._breakpoint hooks
In-Reply-To: <1282175005.37.0.905894818052.issue9635@psf.upfronthosting.co.za>
Message-ID: <1288718739.38.0.817340636805.issue9635@psf.upfronthosting.co.za>


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

I would rename Py_BREAKPOINT to _Py_BREAKPOINT since we don't really want to support this. Also, why do you allow any arguments to sys._breakpoint()?

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

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

From report at bugs.python.org  Tue Nov  2 19:26:29 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Tue, 02 Nov 2010 18:26:29 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288722389.16.0.719629877823.issue1926@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

Thanks a lot for having implemented STARTTLS, Andrew!
That's great news!



+        Since the order in which certain operations need to be done varies
+        between normal, SSL, and STARTTLS connections varies, some
+        initialization must be done in the subclasses. 

One "varies" is enough.

----------

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

From report at bugs.python.org  Tue Nov  2 20:02:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 19:02:18 +0000
Subject: [issue10240] dict.update.__doc__ is misleading
In-Reply-To: <1288406048.13.0.615215732385.issue10240@psf.upfronthosting.co.za>
Message-ID: <1288724538.7.0.107431131451.issue10240@psf.upfronthosting.co.za>


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


----------
nosy: +eric.araujo
versions:  -Python 2.5, Python 2.6, Python 3.3

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

From report at bugs.python.org  Tue Nov  2 20:12:14 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 02 Nov 2010 19:12: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: <1288725134.59.0.887517688955.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101102a.zip is a new version of the regex module.

msg120204 relates to issue #1519638 "Unmatched group in replacement". In 'regex' an unmatched group is treated as an empty string in a replacement template. This behaviour is more in keeping with regex implementations in other languages.

msg120206 was caused by not all group references being made case-insensitive when they should be.

----------
Added file: http://bugs.python.org/file19469/issue2636-20101102a.zip

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

From report at bugs.python.org  Tue Nov  2 20:19:54 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 02 Nov 2010 19:19:54 +0000
Subject: [issue10038] json.loads() on str should return unicode, not str
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1288725594.76.0.792081299268.issue10038@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

The fact that the C and Python versions are not fully tested (afaict) is not good.  I'm not sure that's worth fixing for 2.7 and it's probably worth a separate bug report for Python 3.2 on that.

In the meantime, I'll test Walter's patch and add a unit test for this case.

----------

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

From report at bugs.python.org  Tue Nov  2 20:20:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 19:20:20 +0000
Subject: [issue1500504] Alternate RFC 3986 compliant URI parsing module
Message-ID: <1288725620.43.0.993447868312.issue1500504@psf.upfronthosting.co.za>


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

Is this still relevant?  Can?t the improvements make it into urllib.parse?

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

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

From report at bugs.python.org  Tue Nov  2 20:21:40 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Tue, 02 Nov 2010 19:21:40 +0000
Subject: [issue10171] Ugly buttons in some Tkinter objects in Windows
In-Reply-To: <1287714866.92.0.753573590678.issue10171@psf.upfronthosting.co.za>
Message-ID: <1288725700.39.0.943075824683.issue10171@psf.upfronthosting.co.za>


Rafe Kettler <rafe.kettler at gmail.com> added the comment:

I've tested how these dialogs display in regular Tcl/Tk, and it appears the problem resides in the Tcl implementation, not the Python binding. You can see for yourself by running this Tcl script:

package require Tk
tk_messageBox
tk_chooseColor

Since this is not a Tkinter or Python issue, I think the issue should be closed and a bug (if it doesn't exist already) should be filed with the Tcl/Tk developers.

----------

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

From report at bugs.python.org  Tue Nov  2 20:27:16 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 02 Nov 2010 19:27:16 +0000
Subject: [issue10038] json.loads() on str should return unicode, not str
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1288726036.02.0.223144996929.issue10038@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

The incomplete testing and C/Python implementation mismatch are covered by issue 5723 and issue 9233.

----------

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

From report at bugs.python.org  Tue Nov  2 20:28:56 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 02 Nov 2010 19:28:56 +0000
Subject: [issue10294] Lib/test/test_unicode_file.py contains dead code
In-Reply-To: <1288714188.98.0.557257896773.issue10294@psf.upfronthosting.co.za>
Message-ID: <1288726136.61.0.535632330355.issue10294@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Committed in r86125

----------
assignee:  -> brett.cannon
nosy: +brett.cannon
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Nov  2 20:29:40 2010
From: report at bugs.python.org (Brian Brazil)
Date: Tue, 02 Nov 2010 19:29:40 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1288726180.36.0.283833635967.issue10252@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

I don't see your patch on the other bug, so I've updated mine not to use with.

----------
Added file: http://bugs.python.org/file19470/distutils_fd_leak_v2.patch

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

From report at bugs.python.org  Tue Nov  2 20:36:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 19:36:38 +0000
Subject: [issue5843] Normalization error in urlunparse
In-Reply-To: <1240686759.57.0.0410680082249.issue5843@psf.upfronthosting.co.za>
Message-ID: <1288726598.46.0.211498077315.issue5843@psf.upfronthosting.co.za>


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


----------
components: +Library (Lib)
title: Possible normalization error in urlparse.urlunparse -> Normalization error in urlunparse
versions: +Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Tue Nov  2 20:44:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 19:44:38 +0000
Subject: [issue10215] Mac Python 3.1 installer does less than earlier
	installers
In-Reply-To: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>
Message-ID: <1288727078.93.0.331704216984.issue10215@psf.upfronthosting.co.za>


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

Does 3.2 install into a Python3.framework?  In other words, is the conception that 2.x and 3.x are two different languages ported over to Mac?

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

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

From report at bugs.python.org  Tue Nov  2 20:45:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 19:45:28 +0000
Subject: [issue10215] Mac Python 3.1 installer does less than earlier
	installers
In-Reply-To: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>
Message-ID: <1288727128.02.0.510262615685.issue10215@psf.upfronthosting.co.za>


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

Without typos: Does 3.1 install into a Python3.framework directory?

----------

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

From report at bugs.python.org  Tue Nov  2 20:47:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 19:47:23 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1288727243.71.0.383163580727.issue10206@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov  2 20:58:12 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Tue, 02 Nov 2010 19:58:12 +0000
Subject: [issue8994] pydoc does not support non-ascii docstrings
In-Reply-To: <1276506836.98.0.338188119331.issue8994@psf.upfronthosting.co.za>
Message-ID: <1288727892.31.0.341030913521.issue8994@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

You are right, this is a duplicate of #6625. And in fact I should have known since I commented on that bug...

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

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

From report at bugs.python.org  Tue Nov  2 20:59:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 19:59:19 +0000
Subject: [issue10198] wave module writes corrupt wav file for zero-length
	writeframes
In-Reply-To: <1288107337.09.0.986719080657.issue10198@psf.upfronthosting.co.za>
Message-ID: <1288727959.17.0.261420613739.issue10198@psf.upfronthosting.co.za>


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

That revision is actually an edit to re.rst.

Is the patch irrelevant for other branches?

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

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

From report at bugs.python.org  Tue Nov  2 21:02:51 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Tue, 02 Nov 2010 20:02:51 +0000
Subject: [issue8488] Docstrings of non-data descriptors "ignored"
In-Reply-To: <1271874309.07.0.567011993617.issue8488@psf.upfronthosting.co.za>
Message-ID: <1288728171.54.0.988914027711.issue8488@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

FYI, this still applies to r86094 of py3k.

----------

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

From report at bugs.python.org  Tue Nov  2 21:35:47 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Nov 2010 20:35:47 +0000
Subject: [issue10038] json.loads() on str should return unicode, not str
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1288730147.66.0.0404222266806.issue10038@psf.upfronthosting.co.za>


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

To mitigate possible negative impacts from changing the return type, consider adding a parse_string hook that lets users control the return type:

   json.loads(f, parse_int=decimal.Decimal, parse_string=repr)

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

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

From report at bugs.python.org  Tue Nov  2 21:36:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 02 Nov 2010 20:36:51 +0000
Subject: [issue6625] UnicodeEncodeError on pydoc's CLI
In-Reply-To: <1249218048.23.0.0483172452601.issue6625@psf.upfronthosting.co.za>
Message-ID: <1288730211.88.0.271071618616.issue6625@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/issue6625>
_______________________________________

From report at bugs.python.org  Tue Nov  2 21:40:22 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 02 Nov 2010 20:40:22 +0000
Subject: [issue10038] json.loads() on str should return unicode, not str
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1288730422.01.0.480379872702.issue10038@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Adding that argument to Python 2.7 seems like new feature territory.

----------

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

From report at bugs.python.org  Tue Nov  2 21:55:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 02 Nov 2010 20:55:45 +0000
Subject: [issue8488] Docstrings of non-data descriptors "ignored"
In-Reply-To: <1271874309.07.0.567011993617.issue8488@psf.upfronthosting.co.za>
Message-ID: <1288731345.91.0.799892849483.issue8488@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov  2 21:57:39 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 02 Nov 2010 20:57:39 +0000
Subject: [issue10038] json.loads() on str should return unicode, not str
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1288731459.08.0.115697320596.issue10038@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

@doerwalter: patch looks good.  I've added a test and will commit momentarily.

----------

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

From report at bugs.python.org  Tue Nov  2 22:04:29 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 02 Nov 2010 21:04:29 +0000
Subject: [issue10038] json.loads() on str should return unicode, not str
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1288731869.49.0.802177206349.issue10038@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r86126

----------
assignee: bob.ippolito -> barry
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Tue Nov  2 22:08:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 21:08:07 +0000
Subject: [issue9999] test_shutil cross-file-system tests are fragile (may not
	test what they purport to test)
In-Reply-To: <1285860550.74.0.246130427134.issue9999@psf.upfronthosting.co.za>
Message-ID: <1288732087.42.0.707931335821.issue9999@psf.upfronthosting.co.za>


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


----------
nosy: +eric.araujo
title: test_shutil cross-file-system tests are fragile (may not test what they pruport to test) -> test_shutil cross-file-system tests are fragile (may not test what they purport to test)

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

From report at bugs.python.org  Tue Nov  2 22:26:41 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 02 Nov 2010 21:26:41 +0000
Subject: [issue8488] Docstrings of non-data descriptors "ignored"
In-Reply-To: <1271874309.07.0.567011993617.issue8488@psf.upfronthosting.co.za>
Message-ID: <1288733201.37.0.495386942292.issue8488@psf.upfronthosting.co.za>


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

pydoc should probably be adapted to look at a type for descrs.

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

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

From report at bugs.python.org  Tue Nov  2 22:30:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 21:30:35 +0000
Subject: [issue10181] get_shape0 in memoryobject.c not checked for error return
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288733435.37.0.795220024524.issue10181@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Nov  2 22:41:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 21:41:32 +0000
Subject: [issue9849] Argparse needs better error handling for nargs
In-Reply-To: <1284420312.86.0.187137843637.issue9849@psf.upfronthosting.co.za>
Message-ID: <1288734092.3.0.764816829559.issue9849@psf.upfronthosting.co.za>


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


----------
nosy: +eric.araujo
stage:  -> needs patch

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

From report at bugs.python.org  Tue Nov  2 22:47:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 21:47:15 +0000
Subject: [issue9846] ZipExtFile provides no mechanism for closing the
	underlying file object
In-Reply-To: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>
Message-ID: <1288734435.47.0.151019237353.issue9846@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/issue9846>
_______________________________________

From report at bugs.python.org  Tue Nov  2 22:55:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 21:55:07 +0000
Subject: [issue9736] doctest.DocTestSuite doesn't handle test globs correctly
In-Reply-To: <1283367674.32.0.228375766546.issue9736@psf.upfronthosting.co.za>
Message-ID: <1288734907.64.0.754040790751.issue9736@psf.upfronthosting.co.za>


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

Would you like to work on a patch?

(Setting the versions field to versions that are open for bug fixes.)

----------
nosy: +eric.araujo
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2 -Python 2.5, Python 2.6

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

From report at bugs.python.org  Tue Nov  2 22:56:49 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Nov 2010 21:56:49 +0000
Subject: [issue10263] "python -m site" does not print path details
In-Reply-To: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>
Message-ID: <1288735009.59.0.799405234619.issue10263@psf.upfronthosting.co.za>


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

Yeah, because the internal import system isn't fully exposed, runpy and a couple of other tools in the standard library rely on the emulation in pkgutil instead. I know there are some differences between the emulation and the builtin mechanism on Windows in terms of search order, but I thought they were the same on OS X.

Manipulating sys.path and the various caches in sys should affect both import mechanisms though - just what are setuptools/distribute doing?

I'm also curious as to which version of the module importlib finds ("import importlib; print(importlib.import_module("site").__file__)" will tell you that for both 2.7 and 3.x)

----------

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

From report at bugs.python.org  Tue Nov  2 23:01:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 22:01:00 +0000
Subject: [issue9625] argparse: Problem with defaults for variable nargs
In-Reply-To: <1282036744.37.0.964764969496.issue9625@psf.upfronthosting.co.za>
Message-ID: <1288735261.0.0.639065708123.issue9625@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/issue9625>
_______________________________________

From report at bugs.python.org  Tue Nov  2 23:02:51 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Nov 2010 22:02:51 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1288714677.92.0.380160207566.issue2001@psf.upfronthosting.co.za>
Message-ID: <AANLkTim-mGaTQgxF374fJ52-a=8GLSBfuDev2BLq9xJw@mail.gmail.com>


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

On Wed, Nov 3, 2010 at 2:17 AM, Ron Adam <report at bugs.python.org> wrote:
>
> Ron Adam <ron_adam at users.sourceforge.net> added the comment:
>
> Nick, I can update the patch and move the server back into pydoc.py if that will help you get this into 3.2 beta.

Yep, probably the best option 3.2 - then make a new issue about making
those public in the standard library (since they aren't really
pydoc-specific).

> I can also changed the docstrings of the new parts to # comments.

Just mark the various names with an underscore so people know the
current names aren't final. There's no harm in leaving the docstrings
in place if you do that.

----------

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

From report at bugs.python.org  Tue Nov  2 23:06:10 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Tue, 02 Nov 2010 22:06:10 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288735570.3.0.458362390151.issue10284@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

David, the headers are not at all supposed to be "utf-8" encoded.
For instance, have a look at the cn.bbs.comp.lang.python newsgroup:

http://groups.google.fr/group/cn.bbs.comp.lang.python

If you look at the source of the articles, you will for instance see that the Subject: header field is not MIME-encoded.  It is directly written in gb2312.

That's how news works in the wild.  Please do not break nntplib in Python 3.2!


Regarding AUTHINFO, the specification is not broken at all.  Bytes are expected, not strings in a particular encoding.  Well, most people are in fact confused when they speak about encodings -- me included :-)
The specification is pretty clear:  NNTP expects bytes.  And my text string is "\xC9ric", that's all.  Please also do not break nntplib when providing such strings on class instantiation.

----------

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

From report at bugs.python.org  Tue Nov  2 23:06:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 22:06:13 +0000
Subject: [issue9587] unittest.assertRaises() return the raised exception
In-Reply-To: <1281711464.19.0.685530938413.issue9587@psf.upfronthosting.co.za>
Message-ID: <1288735573.64.0.141156378964.issue9587@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/issue9587>
_______________________________________

From report at bugs.python.org  Tue Nov  2 23:09:22 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Nov 2010 22:09:22 +0000
Subject: [issue1500504] Alternate RFC 3986 compliant URI parsing module
Message-ID: <1288735762.81.0.935892929979.issue1500504@psf.upfronthosting.co.za>


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

I still like the higher level API concept, although I might not do it exactly as presented here any more.

Independently of introducing a new parsing API, it would be worthwhile extracting the parsing tests from the attached module to make sure the *existing* parser can handle them all correctly.

----------

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

From report at bugs.python.org  Tue Nov  2 23:10:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 22:10:20 +0000
Subject: [issue670664] HTMLParser.py - more robust SCRIPT tag parsing
Message-ID: <1288735820.19.0.496205319093.issue670664@psf.upfronthosting.co.za>


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

Would it be reasonable to add knowledge to html.parser to make it recognize script elements as CDATA and handle it correctly (that is let ?<? pass)?

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

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

From report at bugs.python.org  Tue Nov  2 23:14:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 22:14:27 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288736067.75.0.46823280161.issue10284@psf.upfronthosting.co.za>


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

> And my text string is "\xC9ric", that's all.

You mean b"\xC9ric", right?

> If you look at the source of the articles, you will for instance see
> that the Subject: header field is not MIME-encoded.  It is directly
> written in gb2312.

How is an NNTP client supposed to guess the encoding? Either a header is MIME-encoded, or it follows the RFC 3977 recommendation of UTF-8 (?The content of a header SHOULD be in UTF-8?), or it's unreadable.

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

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

From report at bugs.python.org  Tue Nov  2 23:16:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 22:16:20 +0000
Subject: [issue10181] get_shape0 in memoryobject.c not checked for error return
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288736180.43.0.062939536799.issue10181@psf.upfronthosting.co.za>


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

Yes, there are probably many holes like this. I've done what I could to make the simple cases (builtin types) to work, but the spec is rotten from the start. Blame the numpy people, sorry.

----------
nosy: +ncoghlan

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

From report at bugs.python.org  Tue Nov  2 23:30:04 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Nov 2010 22:30:04 +0000
Subject: [issue10181] get_shape0 in memoryobject.c not checked for error return
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288737004.38.0.369323365897.issue10181@psf.upfronthosting.co.za>


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

As far as I know, PEP 3118 serves its purpose of allowing extension modules like numpy and PIL to share data without needing to copy it around all the time. It's just that memoryview wasn't really part of that purpose (since all the affected third party libraries have their own objects for looking at memory), and it shows :P

Our near term goal should be to get memoryview in a good place for handling 1D contiguous data and throw exceptions (rather than crashing) for everything else. I think Antoine has achieved the former, but it sounds like there is still some work to do on the latter.

----------

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

From report at bugs.python.org  Tue Nov  2 23:32:56 2010
From: report at bugs.python.org (Tom Pinckney)
Date: Tue, 02 Nov 2010 22:32:56 +0000
Subject: [issue2927] expose html.parser.unescape
In-Reply-To: <1211262235.18.0.705526453605.issue2927@psf.upfronthosting.co.za>
Message-ID: <1288737176.85.0.300662371126.issue2927@psf.upfronthosting.co.za>


Tom Pinckney <thomaspinckney3 at gmail.com> added the comment:

I don't think Django includes an HTML unescape. I'm not familiar with other frameworks. So I'd still find this useful to include in the stdlib.

----------

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

From report at bugs.python.org  Tue Nov  2 23:34:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 22:34:59 +0000
Subject: [issue10181] get_shape0 in memoryobject.c not checked for error return
In-Reply-To: <1288737004.38.0.369323365897.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288737292.3541.5.camel@localhost.localdomain>


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

> As far as I know, PEP 3118 serves its purpose of allowing extension
> modules like numpy and PIL to share data without needing to copy it
> around all the time. It's just that memoryview wasn't really part of
> that purpose (since all the affected third party libraries have their
> own objects for looking at memory), and it shows :P

The deeper issue is that there are no ownership or lifetime rules for
dynamically allocated fields in Py_buffer (such as strides and shape),
which itself isn't a PyObject. For very simple objects (such as bytes or
bytearray) it isn't really a problem, but it is in more complicated
situations; and there's no possible solution without a clear spec..

(and I'm not even talking of the issue of making slices of memoryviews,
since the buffer API itself doesn't handle slicing, which means the
memoryview object has to modify its inner Py_buffer...)

----------

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

From report at bugs.python.org  Tue Nov  2 23:35:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 22:35:40 +0000
Subject: [issue10280] nntp_version set to the most recent advertised version
In-Reply-To: <1288641195.29.0.702249344241.issue10280@psf.upfronthosting.co.za>
Message-ID: <1288737340.73.0.379330524335.issue10280@psf.upfronthosting.co.za>


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

I've fixed it according to your suggestion (take the max of the advertised version) in r86129. Thank you!

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

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

From report at bugs.python.org  Tue Nov  2 23:41:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 22:41:27 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288737687.07.0.321115032489.issue10281@psf.upfronthosting.co.za>


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

I am wondering how to return the corresponding information. Should the field be totally absent from the returned dictionary, should it map to the empty string, or should it map to None?
I'm leaning towards the latter (map to None), but perhaps the empty string is better?

----------

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

From report at bugs.python.org  Tue Nov  2 23:43:16 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Tue, 02 Nov 2010 22:43:16 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288737796.7.0.968299484534.issue10284@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

Antoine, a news client could guess it because of the Content-Type: header field (in this example, it mentions charset="gb2312").
Yet, articles without a Content-Type: header field exist in the wild...
There is no way to always make the right guess, unfortunately.
News clients try to do their best :-)


Yes, I mean b"\xC9ric".  4 bytes.

----------

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

From report at bugs.python.org  Tue Nov  2 23:44:45 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Tue, 02 Nov 2010 22:44:45 +0000
Subject: [issue10215] Mac Python 3.1 installer does less than earlier
	installers
In-Reply-To: <1288727128.02.0.510262615685.issue10215@psf.upfronthosting.co.za>
Message-ID: <AANLkTikvA23Us7C1sZDc30=f0vLv1qm2kSk1Y_YwhimC@mail.gmail.com>


Bruce Sherwood <bruce.sherwood at gmail.com> added the comment:

Yes. After installation, you'll see that Python 3.1 is in
/Library/Frameworks/Python.framework/Versions/3.1

Bruce Sherwood

On Tue, Nov 2, 2010 at 1:45 PM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Without typos: Does 3.1 install into a Python3.framework directory?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10215>
> _______________________________________
>

----------

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

From report at bugs.python.org  Tue Nov  2 23:45:11 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Tue, 02 Nov 2010 22:45:11 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288737911.86.0.563854897207.issue10281@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

The empty string would mean the header exists, and is empty (though not RFC-compliant).
For instance:

"User-Agent: \r\n"

I believe None is better.

----------

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

From report at bugs.python.org  Tue Nov  2 23:48:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 22:48:21 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288737796.7.0.968299484534.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288738096.3541.7.camel@localhost.localdomain>


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

> Antoine, a news client could guess it because of the Content-Type:
> header field (in this example, it mentions charset="gb2312").
> Yet, articles without a Content-Type: header field exist in the
> wild...

Unless I'm mistaken, Content-Type should only apply to the body, not the
headers. Either the headers use UTF-8 (RFC 3977), or they should be
MIME-encoded. Everything else is undecodable.

> There is no way to always make the right guess, unfortunately.
> News clients try to do their best :-)

Well, a news client built on nntplib could also try to do its best :)

> Yes, I mean b"\xC9ric".  4 bytes.

Ok, perhaps we should allow bytes username and password.

----------

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

From report at bugs.python.org  Tue Nov  2 23:52:32 2010
From: report at bugs.python.org (Jim Fulton)
Date: Tue, 02 Nov 2010 22:52:32 +0000
Subject: [issue9736] doctest.DocTestSuite doesn't handle test globs correctly
In-Reply-To: <1288734907.64.0.754040790751.issue9736@psf.upfronthosting.co.za>
Message-ID: <AANLkTimy78G-sriKU_Bhxkc1AkGqu8M+SwMATfBLv21X@mail.gmail.com>


Jim Fulton <jim at zope.com> added the comment:

On Tue, Nov 2, 2010 at 5:55 PM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Would you like to work on a patch?

Sure.

Jim

----------

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

From report at bugs.python.org  Tue Nov  2 23:52:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 22:52:34 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288738354.87.0.709300793102.issue10281@psf.upfronthosting.co.za>


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

Here is a patch for returning None on absent fields.
(works with trigofacile.com)

----------
keywords: +patch
Added file: http://bugs.python.org/file19471/nntpover.patch

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

From report at bugs.python.org  Tue Nov  2 23:56:23 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Tue, 02 Nov 2010 22:56:23 +0000
Subject: [issue10284] Exception raised when decoding NNTP newsgroup
	descriptions
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288738583.25.0.147008491692.issue10284@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

> Unless I'm mistaken, Content-Type should only apply to the body, not the
> headers.  Either the headers use UTF-8 (RFC 3977), or they should be
> MIME-encoded.  Everything else is undecodable.

Yes, of course.  Such articles are not RFC-compliant.  You're not mistaken when you mention that the Content-Type: header field applies to the body.
I was just answering about how the encoding could be guessed.

----------

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

From report at bugs.python.org  Tue Nov  2 23:57:09 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 02 Nov 2010 22:57:09 +0000
Subject: [issue10181] get_shape0 in memoryobject.c not checked for error return
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288738629.35.0.53407341178.issue10181@psf.upfronthosting.co.za>


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

Read the "Releasing the buffer" section in PEP 3118 again. Unless I'm misunderstanding you completely, the rules you're asking for are already in place: those fields are entirely the responsibility of the exporting object, and it needs to ensure they remain valid until the buffer is released.

Now, it may be that we haven't *implemented* this correctly or consistently in the builtin objects, in which case we should do something about it. But the rules are there.

----------

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

From report at bugs.python.org  Wed Nov  3 00:01:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 23:01:14 +0000
Subject: [issue10181] get_shape0 in memoryobject.c not checked for error return
In-Reply-To: <1288738629.35.0.53407341178.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288738868.3541.14.camel@localhost.localdomain>


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

> Read the "Releasing the buffer" section in PEP 3118 again. Unless I'm
> misunderstanding you completely, the rules you're asking for are
> already in place: those fields are entirely the responsibility of the
> exporting object, and it needs to ensure they remain valid until the
> buffer is released.

In practice, though, we copy Py_buffer structs around and there's no way
for the original object to know about that. That's the fundamental
difference with a PyObject where you would only increase a refcount
instead of copying the structure's contents.

----------

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

From report at bugs.python.org  Wed Nov  3 00:05:10 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Tue, 02 Nov 2010 23:05:10 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288739110.07.0.890731125422.issue10281@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

OK, thanks.
By the way, why is the token stripped?
  token = token[len(h):].lstrip(" ")

"X-Header:   test  \r\n" in an header is kept in the overview as-is.
I do not see why "  test  " should not be the value returned.

Also, with:
  token = token or None

"X-Header: \r\n" becomes None if I understand how the source code works...  Yet, it is a real '', not None.

----------

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

From report at bugs.python.org  Wed Nov  3 00:08:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 23:08:41 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288739110.07.0.890731125422.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288739314.3541.17.camel@localhost.localdomain>


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

> OK, thanks.
> By the way, why is the token stripped?
>   token = token[len(h):].lstrip(" ")
> 
> "X-Header:   test  \r\n" in an header is kept in the overview as-is.
> I do not see why "  test  " should not be the value returned.

It's a simple way of handling "Xref: foo" and returning "foo" rather
than " foo". If spaces are supposed to be significant I can just strip
the first one, though.

> Also, with:
>   token = token or None
> 
> "X-Header: \r\n" becomes None if I understand how the source code
> works...  Yet, it is a real '', not None.

Er, so you're disagreeing with your previous message? Or am I missing
something? :)

----------

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

From report at bugs.python.org  Wed Nov  3 00:08:48 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Tue, 02 Nov 2010 23:08:48 +0000
Subject: [issue8037] multiprocessing.Queue's put() not atomic thread wise
In-Reply-To: <1267482006.55.0.281200221208.issue8037@psf.upfronthosting.co.za>
Message-ID: <1288739328.05.0.906819634571.issue8037@psf.upfronthosting.co.za>


Vilnis Termanis <vilnis.termanis at googlemail.com> added the comment:

Please find attached an updated patch (including unit test) for the release27-maint branch. I've run the test_multiprocessing suite against svn revision 86129 of said branch.

----------
Added file: http://bugs.python.org/file19472/patch_27maint.diff

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

From report at bugs.python.org  Wed Nov  3 00:18:41 2010
From: report at bugs.python.org (Andrew Vant)
Date: Tue, 02 Nov 2010 23:18:41 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1288717539.98.0.790128608117.issue1926@psf.upfronthosting.co.za>
Message-ID: <4CD09C4E.3058.AC5AA3B@ajvant.gmail.com>


Andrew Vant <ajvant at gmail.com> added the comment:

On 2 Nov 2010 at 17:05, Antoine Pitrou wrote:

> * the command-line option for the SSLContext won't work, since a
> context is a custom object, not a string; I would rework this part
> anyway, since I don't think separate options for the "SSL host" are
> useful (I'd rather add a SSL-enabling flag; also, STARTTLS can be
> queried from the capabilities)

I'm not sure I understand which part you're talking about here....the 
tests don't take a context for anything that I can see, and the 
mechanism I use in nntplib (a context as a named argument) is the 
same one used in smtplib and poplib for <prot>_SSL. 

(if you can suggest a method-of-use that breaks it, that may enlighten
me better) 

> * on a stylistic note, there are a couple of places where you use tabs
> for indentation; also, comments should have a space after the '#' ('#
> xxx' and not '#xxx')

Meh. My editor wasn't set up properly when I started. I thought I'd 
eliminated all the tabs. Guess not. There's probably a way to grep 
for lines that have tabs in them, I'll fix it.

> * not moving methods around (such as getwelcome) would make it easier
> to review the real changes

I'll see what I can do. Some amount of that was necessary to fit 
STARTTLS in. (because init assumed you wanted to log in right away 
and never again) 

> * in test_starttls, I would clearly report that the server doesn't
> support STARTTLS, e.g.:

Can do. I didn't know about self.skip; I don't really understand the 
testing framework, I was just working by comparison to the other 
tests.

> * starttls() should probably test the `tls_on` attribute first and
> raise a ValueError if True (as you point out, a client mustn't attempt
> to start a new TLS session if one is already active).

...I actually meant to do exactly that, but forgot to put the check 
in. Thank you. 

--

Andrew.

----------

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

From report at bugs.python.org  Wed Nov  3 00:18:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 23:18:47 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288739927.82.0.173654774084.issue10281@psf.upfronthosting.co.za>


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

Here is a patch trying to better handle whitespace. Would it be ok for you?

----------
Added file: http://bugs.python.org/file19473/nntpover2.patch

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

From report at bugs.python.org  Wed Nov  3 00:19:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 23:19:20 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288739960.88.0.957970648922.issue10281@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file19473/nntpover2.patch

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

From report at bugs.python.org  Wed Nov  3 00:19:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 23:19:34 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288739974.31.0.197276933738.issue10281@psf.upfronthosting.co.za>


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

Oops, sorry.

----------
Added file: http://bugs.python.org/file19474/nntpover2.patch

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

From report at bugs.python.org  Wed Nov  3 00:20:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 23:20:53 +0000
Subject: [issue10215] Mac Python 3.1 installer does less than earlier
	installers
In-Reply-To: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>
Message-ID: <1288740053.45.0.904084260083.issue10215@psf.upfronthosting.co.za>


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

So your answer is actually *no*, it does not install into Python3.framework :)

If there had been separate Python.framework and Python3.framework, the answer to this bug would be obvious.  But since 2.x and 3.x Pythons are installed as versions of the same framework, it sort of makes sense that Versions/Current can point to a 3.x version.

Do I make sense?

----------

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

From report at bugs.python.org  Wed Nov  3 00:22:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 23:22:47 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <4CD09C4E.3058.AC5AA3B@ajvant.gmail.com>
Message-ID: <1288740162.3541.20.camel@localhost.localdomain>


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

> > * the command-line option for the SSLContext won't work, since a
> > context is a custom object, not a string; I would rework this part
> > anyway, since I don't think separate options for the "SSL host" are
> > useful (I'd rather add a SSL-enabling flag; also, STARTTLS can be
> > queried from the capabilities)
> 
> I'm not sure I understand which part you're talking about here....the 
> tests don't take a context for anything that I can see, and the 
> mechanism I use in nntplib (a context as a named argument) is the 
> same one used in smtplib and poplib for <prot>_SSL. 

I'm talking about the code under "if __name__ == '__main__'".
Specifically the "-c" option for specifying an SSL context.

> > * in test_starttls, I would clearly report that the server doesn't
> > support STARTTLS, e.g.:
> 
> Can do. I didn't know about self.skip; I don't really understand the 
> testing framework, I was just working by comparison to the other 
> tests.

Well, actually it's "self.skipTest(...)". My bad.

----------

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

From report at bugs.python.org  Wed Nov  3 00:37:52 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 02 Nov 2010 23:37:52 +0000
Subject: [issue10263] "python -m site" does not print path details
In-Reply-To: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>
Message-ID: <1288741072.94.0.247653460111.issue10263@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The issue here is not unique to OS X. I see the same behavior on Linux with a built-from-source Python 3.2a3 and Distribute 0.6.14. (As I noted earlier, Debian and presumably various other distributors package a patched version of setuptools / Distribute which does not do the "bootstrap" manipulations so you likely wouldn't see the problem.)

importlib.import_module('site') finds the standard library version whether s/D is installed or not.  But that is to be expected.  This problem is unique to the site module because the path manipulation stuff happens first and in the normal environment (not -m), sys.modules['site'] will always be pointing to the standard lib version; the s/D bootstrap erases its tracks so to speak.

Just to be clear, I don't think there is any Python problem here.  It's all due to how s/D tries to manage import order.  The only way around it is for s/D to recognize and support the -m site case.

Here's what is in easy_install.pth, with my {} annotations:

import sys; sys.__plen = len(sys.path)
{... an entry for the first easy_installed distribution ... }
./appscript-0.21.1-py2.7-macosx-10.3-fat.egg
{... and entries here for any other easy_installed distributions ...}
{... ending with this last one for distribute or setuptools itself ...}
./distribute-0.6.8-py2.7.egg
[ ... which creates the _egginsert attribute used here }
import sys; new=sys.path[_sys.__plen:]; del sys.path[sys.__plen:]; p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; s
ys.__egginsert = p+len(new)

The distribute egg contains a site.py at the top level.  If you are interested in looking at it, it's probably best to just install distribute and look at what happens in site-packages.

----------

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

From report at bugs.python.org  Wed Nov  3 00:49:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 02 Nov 2010 23:49:31 +0000
Subject: [issue10171] Ugly buttons in some Tkinter objects in Windows
In-Reply-To: <1287714866.92.0.753573590678.issue10171@psf.upfronthosting.co.za>
Message-ID: <1288741771.32.0.863597459631.issue10171@psf.upfronthosting.co.za>


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

Thanks for hunting that down.  Agreed about closing.

I have no inkling about the Tcl development process.  Can you report the bug to them?

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

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

From report at bugs.python.org  Wed Nov  3 00:52:52 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Tue, 02 Nov 2010 23:52:52 +0000
Subject: [issue10171] Ugly buttons in some Tkinter objects in Windows
In-Reply-To: <1287714866.92.0.753573590678.issue10171@psf.upfronthosting.co.za>
Message-ID: <1288741972.76.0.557782628099.issue10171@psf.upfronthosting.co.za>


Rafe Kettler <rafe.kettler at gmail.com> added the comment:

I don't know anything about the Tcl development process either. Luckily, Tk is hosted on SourceForge so it was just a matter of adding a ticket to their issue tracker.

Hopefully it'll get fixed quickly and the fix will percolate down into Tkinter.

----------

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

From report at bugs.python.org  Wed Nov  3 00:53:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 02 Nov 2010 23:53:08 +0000
Subject: [issue10173] Don't pickle TestCase instances in test_multiprocessing
In-Reply-To: <1287786993.14.0.756780399794.issue10173@psf.upfronthosting.co.za>
Message-ID: <1288741988.35.0.12483862258.issue10173@psf.upfronthosting.co.za>


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

Committed in r86130 (3.2), r86131 (2.7) and r86132 (3.1).

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

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

From report at bugs.python.org  Wed Nov  3 01:33:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Nov 2010 00:33:53 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288744433.94.0.519642939011.issue10273@psf.upfronthosting.co.za>


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

After discussion on python-dev, it seems that API lock-in precludes any change to the package structure.  So, the main proposals left are the addition of new better aliases for some of the functions and changing to the docs so that the new name is clear:

   assertLE(self, other)
      old name:  AssertLessEqual
      . . .

Also, I we should still dedocument assert<sometype>Equal and its brethren and leave assertEqual as the primary interface.  

At some point, we could add an option to assertEqual to allow user control of how failing results are displayed.  This would let us separate content from presentation (i.e. a==b vs how a diff would get presented).

----------

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

From report at bugs.python.org  Wed Nov  3 01:54:11 2010
From: report at bugs.python.org (Andrew Vant)
Date: Wed, 03 Nov 2010 00:54:11 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1288740162.3541.20.camel@localhost.localdomain>
Message-ID: <4CD0B2B4.29230.B1D265E@ajvant.gmail.com>


Andrew Vant <ajvant at gmail.com> added the comment:

On 2 Nov 2010 at 23:22, Antoine Pitrou wrote:

> I'm talking about the code under "if __name__ == '__main__'".
> Specifically the "-c" option for specifying an SSL context.

Now I feel silly. Partly because of the mistake, partly because I did 
test_nntplib.py last and by the time I was done I'd forgotten there 
was another section of test code involved. 

Thanks for the advice; I'll fix it as best I can in the next day or 
two and submit a new version. 

--

Andrew

----------

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

From report at bugs.python.org  Wed Nov  3 01:57:02 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Wed, 03 Nov 2010 00:57:02 +0000
Subject: [issue10215] Mac Python 3.1 installer does less than earlier
	installers
In-Reply-To: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>
Message-ID: <1288745822.79.0.19422579491.issue10215@psf.upfronthosting.co.za>


Bruce Sherwood <bruce.sherwood at gmail.com> added the comment:

Now I understand what you're getting at; I didn't realize that you were aiming at the possible distinction between 3 and 3.1. Yes, this is what bothered me and prompted my original posting. Python 3.1 goes into the same framework as the 2.x versions.

Incidentally, I did find that in /usr/local/bin (where I had not thought to look) there are the following:

python3.1, a link to the framework python3.1
pythonw3.1, a link to the framework pythonw3.1

python3, a link to a framework python3, which is an extra copy (not a link) to the framework python3.1
pythonw3, a link to a framework pythonw3, which is a link to the framework python3.1

This looks to me pretty contorted, although I suppose the goal was to let people either run "python" (their most recent Python 2.x) or run "python3" (their most recent Python 3.x).

A somewhat related example of confusion is that on Ubuntu 10.10 there is a shadowy existence for some python3 that has its own lib folder, in parallel to python3.1; the python3 doesn't seem to be simply an alias for python3.1.

----------

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

From report at bugs.python.org  Wed Nov  3 02:17:32 2010
From: report at bugs.python.org (Roger Upole)
Date: Wed, 03 Nov 2010 01:17:32 +0000
Subject: [issue10181] get_shape0 in memoryobject.c not checked for error return
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288747052.45.0.352431471183.issue10181@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

The culprit wrt copying Py_buffer structs seems mainly to be dup_buffer, which is called in memory_getbuf.  This seems unnecessary in the case where there's an underlying object and it has returned the view thru its own tp_as_buffer.  The underlying object at that point is solely responsible for releasing the buffer, so memory_getbuf shouldn't mess with it at all.  In the case where there is no underlying object (mainly thru PyMemoryView_FromBuffer), it probably should allocate any memory in the view in such a way that it can be freed in memory_releasebuf when the view->obj is NULL.

----------

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

From report at bugs.python.org  Wed Nov  3 02:31:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Nov 2010 01:31:43 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288747903.77.0.669350407405.issue10273@psf.upfronthosting.co.za>


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

I don't think assertLE is enough of an improvement over assertLessEqual to be worth adding yet more deprecated names to unittest. So I'm -0 on this change in general.  (I'd be -1 except that it would be kind of nice to have the names be shorter :)

If the change is made, then assertEqual should become assertEQ, and assertNotEqual should become assertNE.

Another option is to go the other way, and change assertLess to assertLessThan.  That is, make the spelling consistently be the spelled out version of the abbreviation used in the special methods and elsewhere in the docs.  This would involve far fewer name changes.

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

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

From report at bugs.python.org  Wed Nov  3 03:00:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Nov 2010 02:00:52 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288749652.15.0.548573293094.issue10281@psf.upfronthosting.co.za>


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

My conclusion in working on the email package is that only the first space after the ':', if it exists, should be stripped.  That is, even though the RFC (for email) reads as if the space after the colon is part of the value, in practice it is part of the delimiter, but is optional (and almost always present, in email).  Whether additional leading spaces are significant depends on why they are there.  Since they are an unusual case, I would choose to preserve them on the theory that someone might care, and that someone who doesn't care can strip them.

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

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

From report at bugs.python.org  Wed Nov  3 03:13:21 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Nov 2010 02:13:21 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288750401.58.0.504832024196.issue10281@psf.upfronthosting.co.za>


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

Besides being shorter, the advantages of assertLE are consistent with the rich comparison method names, no worries about Than, no camel casing ambiguities, no pluralization or other nmemonic issues (LessThanEqual or LessThanEquals or LessThanOrEqual or LessThanOrEqualTo).  The goal is to make sure you don't have to look up the spelling every time you use them.  

That being said, assertEqual can't change.  It has been around forever and is clear about what it does.

What I am sure about is that assertLess and assertLessEqual are very non-standard spellings and that infrequent users of comparison assertions won't remember them.

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

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

From report at bugs.python.org  Wed Nov  3 03:29:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Nov 2010 02:29:53 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288751393.48.0.255134010366.issue10273@psf.upfronthosting.co.za>


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

Besides being shorter, the advantages of assertLE are consistent with the rich comparison method names, no worries about Than, no camel casing ambiguities, no pluralization or other nmemonic issues (LessThanEqual or LessThanEquals or LessThanOrEqual or LessThanOrEqualTo).  The goal is to make sure you don't have to look up the spelling every time you use them.  

That being said, assertEqual can't change.  It has been around forever and is clear about what it does.

What I am sure about is that assertLess and assertLessEqual are very non-standard spellings and that infrequent users of comparison assertions won't remember them.

----------

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

From report at bugs.python.org  Wed Nov  3 03:30:10 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Nov 2010 02:30:10 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288751410.48.0.102433134329.issue10281@psf.upfronthosting.co.za>


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


----------
Removed message: http://bugs.python.org/msg120300

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

From report at bugs.python.org  Wed Nov  3 03:32:48 2010
From: report at bugs.python.org (Roger Upole)
Date: Wed, 03 Nov 2010 02:32:48 +0000
Subject: [issue3605] Py_FatalError causes infinite loop
In-Reply-To: <1219178538.87.0.507520309186.issue3605@psf.upfronthosting.co.za>
Message-ID: <1288751568.61.0.284664596361.issue3605@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

I know this has been closed, but I disagree with the fix. Py_FatalError is designed to give a clean exit with a readable error message when the state of the interpreter is known to be compromised.  Calling *any* python functions or accessing *any* python internals is only likely to lead to more issues that obscure the original problems.  IMO the PyErr_Occurred needs to be removed entirely.

----------

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

From report at bugs.python.org  Wed Nov  3 03:37:29 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Nov 2010 02:37:29 +0000
Subject: [issue10215] Mac Python 3.1 installer does less than earlier
	installers
In-Reply-To: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>
Message-ID: <1288751849.09.0.218332330923.issue10215@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It was a deliberate decision on Ronald's part to not modify the Versions/Current link in the Python framework when installing a Python 3.x version.  As far as I know, the Current link is not used anywhere other than perhaps by Xcode when trying to link a Python frameworks into another language project.  Current has no affect on any of the /usr/local symlinks optionally created by the python OS X installer.

Use of the those symlinks is somewhat problematic anyway once you install any third-party packages the include scripts.  By default, Distutils installs scripts into the framework bin directory of the appropriate version.  That's why the recommended approach to managing paths is to simply put the framework bin directory towards the head of your shell PATH.  For each version, the OS X installer provides "Update Shell Profile.command" to alter the most common shell profiles accordingly; it can be found in the "/Applications/Python x.m" folder.  As documented in the installer README, for 3.x installs, the installer does not automatically run "Update Shell Profile" as it does for 2.x installs; you need to run it explicitly or otherwise cause PATH to be changed.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Wed Nov  3 03:41:23 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Nov 2010 02:41:23 +0000
Subject: [issue10215] Mac Python 3.1 installer does less than earlier
	installers
In-Reply-To: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>
Message-ID: <1288752083.48.0.569393698897.issue10215@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It was a deliberate decision on Ronald's part to not modify the Versions/Current link in the Python framework when installing a Python 3.x version.  As far as I know, the Current link is not used anywhere other than perhaps by Xcode when trying to link a Python frameworks into another language project.  Current has no affect on any of the /usr/local symlinks optionally created by the python OS X installer.

Use of the those symlinks is somewhat problematic anyway once you install any third-party packages that include scripts.  By default, Distutils installs scripts into the framework bin directory of the appropriate version.  That's why the recommended approach to managing paths is to simply put the framework bin directory towards the head of your shell PATH, so something like:

export PATH="/Library/Frameworks/Python.framework/Versions/3.1/bin:${PATH}"

For each version, the OS X installer provides "Update Shell Profile.command" to alter the most common shell profiles accordingly; it can be found in the "/Applications/Python x.m" folder.  As documented in the installer README, for 3.x installs, the installer does not automatically run "Update Shell Profile" as it does for 2.x installs; you need to run it explicitly or otherwise cause PATH to be changed.

----------

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

From report at bugs.python.org  Wed Nov  3 03:41:32 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 03 Nov 2010 02:41:32 +0000
Subject: [issue10215] Mac Python 3.1 installer does less than earlier
	installers
In-Reply-To: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>
Message-ID: <1288752092.99.0.447980842229.issue10215@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg120303

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

From report at bugs.python.org  Wed Nov  3 04:28:08 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Wed, 03 Nov 2010 03:28:08 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1288754888.21.0.493810987272.issue7652@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

Has the cdecimal branch kept up with the hash value changes in 3.2?

Is there a still a chance that cdecimal could be merged into 3.2?

----------
nosy: +casevh

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

From report at bugs.python.org  Wed Nov  3 05:06:58 2010
From: report at bugs.python.org (Devin Cook)
Date: Wed, 03 Nov 2010 04:06:58 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1288757218.67.0.283021583175.issue8998@psf.upfronthosting.co.za>


Devin Cook <devin.c.cook at gmail.com> added the comment:

It sounds like you may already have an idea of how you want the API structured, but just in case you're still thinking about it here's another API to look at that I think focuses on exactly what you were highlighting as priorities (sane defaults, easy to use): keyczar.

I use keyczar quite a bit and really like it, although I tend to only use the key classes directly instead of using the generic "Crypter" etc. classes.

http://code.google.com/p/keyczar/

----------
nosy: +devin

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

From report at bugs.python.org  Wed Nov  3 05:24:02 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Wed, 03 Nov 2010 04:24:02 +0000
Subject: [issue10215] Mac Python 3.1 installer does less than earlier
	installers
In-Reply-To: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>
Message-ID: <1288758242.33.0.149121045304.issue10215@psf.upfronthosting.co.za>


Bruce Sherwood <bruce.sherwood at gmail.com> added the comment:

Thanks for the detailed explanation. What had not occurred to me was to read the README file that came with the installer. I made the mistake (that may be made by others) of assuming continuity with installer policy, especially since the installation location was the same as before.

----------

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

From report at bugs.python.org  Wed Nov  3 07:01:56 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 03 Nov 2010 06:01:56 +0000
Subject: [issue10295] _socket.pyd uses winsock2, select.pyd uses winsock 1
In-Reply-To: <1288764115.88.0.357779080417.issue10295@psf.upfronthosting.co.za>
Message-ID: <1288764115.88.0.357779080417.issue10295@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

These two socket modules link to a different winsock api, thus pulling two potentially incompatible dlls in to the process.  There is no guarantee that they interact.

I'll see if there is a simple patch for select module

----------
components: IO
messages: 120308
nosy: krisvale
priority: normal
severity: normal
status: open
title: _socket.pyd uses winsock2, select.pyd uses winsock 1
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  3 07:14:41 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 03 Nov 2010 06:14:41 +0000
Subject: [issue10295] _socket.pyd uses winsock2, select.pyd uses winsock 1
In-Reply-To: <1288764115.88.0.357779080417.issue10295@psf.upfronthosting.co.za>
Message-ID: <1288764881.85.0.601551926981.issue10295@psf.upfronthosting.co.za>


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

Here is a patch

----------
keywords: +patch
Added file: http://bugs.python.org/file19475/select.patch

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

From report at bugs.python.org  Wed Nov  3 07:20:10 2010
From: report at bugs.python.org (Ron Adam)
Date: Wed, 03 Nov 2010 06:20:10 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1288765210.24.0.0747928079146.issue2001@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file16517/pydoc_gui.diff

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

From report at bugs.python.org  Wed Nov  3 07:20:15 2010
From: report at bugs.python.org (Ron Adam)
Date: Wed, 03 Nov 2010 06:20:15 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1288765215.63.0.276847974686.issue2001@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file18165/pydoc_server3.diff

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

From report at bugs.python.org  Wed Nov  3 07:20:20 2010
From: report at bugs.python.org (Ron Adam)
Date: Wed, 03 Nov 2010 06:20:20 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1288765220.42.0.256812059608.issue2001@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file18271/pydoc_server4.diff

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

From report at bugs.python.org  Wed Nov  3 07:26:49 2010
From: report at bugs.python.org (Ron Adam)
Date: Wed, 03 Nov 2010 06:26:49 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1288765609.82.0.345216138273.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Here you go Nick.  One file with Underscores for the new class's and functions.  Where there was some overlap in names, like where some of the older server class's were reused, but don't have exactly the same behavior, I started those with underscores also.

This should make it easier for you to review and/or make adjustments where it's needed.

----------
Added file: http://bugs.python.org/file19476/pydoc_r86133.diff

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

From report at bugs.python.org  Wed Nov  3 08:41:14 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 03 Nov 2010 07:41:14 +0000
Subject: [issue9919] gdbinit lineno result is one line in excess
In-Reply-To: <1285151676.58.0.234965887204.issue9919@psf.upfronthosting.co.za>
Message-ID: <1288770074.17.0.927817417842.issue9919@psf.upfronthosting.co.za>


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

Right. Fixed in r86134. Thanks :)

----------

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

From report at bugs.python.org  Wed Nov  3 09:20:33 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 03 Nov 2010 08:20:33 +0000
Subject: [issue10296] ctypes catches BreakPoint error on windows 32
In-Reply-To: <1288772433.69.0.284335189868.issue10296@psf.upfronthosting.co.za>
Message-ID: <1288772433.69.0.284335189868.issue10296@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

import ctypes
ctypes.windll.kernel32.DebugBreak()
This used to be a handy way to attach a debugger to a running program, by way of JIT debugging.  Now ctypes catches and handles this exception so a debugger is never invoked.  Bummer.

----------
messages: 120312
nosy: krisvale
priority: normal
severity: normal
status: open
title: ctypes catches BreakPoint error on windows 32
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  3 09:35:05 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Wed, 03 Nov 2010 08:35:05 +0000
Subject: [issue9015] array.array.tofile cannot write arrays of sizes > 4GB,
	even compiled for amd64
In-Reply-To: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>
Message-ID: <1288773305.52.0.886409179002.issue9015@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

This seems to be related: http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/7c913001-227e-439b-bf07-54369ba07994

----------
nosy: +cgohlke

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

From report at bugs.python.org  Wed Nov  3 09:47:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Nov 2010 08:47:02 +0000
Subject: [issue10295] _socket.pyd uses winsock2, select.pyd uses winsock 1
In-Reply-To: <1288764115.88.0.357779080417.issue10295@psf.upfronthosting.co.za>
Message-ID: <1288774022.3.0.778786039641.issue10295@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Nov  3 10:01:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 03 Nov 2010 09:01:24 +0000
Subject: [issue10295] _socket.pyd uses winsock2, select.pyd uses winsock 1
In-Reply-To: <1288764115.88.0.357779080417.issue10295@psf.upfronthosting.co.za>
Message-ID: <1288774884.3.0.588651014978.issue10295@psf.upfronthosting.co.za>


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

LGTM.

----------

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

From report at bugs.python.org  Wed Nov  3 11:30:21 2010
From: report at bugs.python.org (hafiza jameel)
Date: Wed, 03 Nov 2010 10:30:21 +0000
Subject: [issue10297] decimal module documentation is misguiding
In-Reply-To: <1288780221.67.0.597486897879.issue10297@psf.upfronthosting.co.za>
Message-ID: <1288780221.67.0.597486897879.issue10297@psf.upfronthosting.co.za>


New submission from hafiza jameel <fizabreeze at gmail.com>:

the documentation does not show the import statement of decimal module in the introduction:
http://docs.python.org/library/decimal.html

import should have been done like this:
from decimal import *

----------
assignee: docs at python
components: Documentation
messages: 120315
nosy: docs at python, hafiza.jameel
priority: normal
severity: normal
status: open
title: decimal module documentation is misguiding
versions: Python 2.7

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

From report at bugs.python.org  Wed Nov  3 12:44:18 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 03 Nov 2010 11:44:18 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1288784658.32.0.0881079239562.issue9995@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

> python setup.py build sdist register upload
...
Save your login (y/N)?n
running upload
Submitting dist\review-r585.zip to http://pypi.python.org/pypi
Upload failed (401): You must be identified to edit package information

----------

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

From report at bugs.python.org  Wed Nov  3 12:58:16 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 03 Nov 2010 11:58:16 +0000
Subject: [issue10263] "python -m site" does not print path details
In-Reply-To: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>
Message-ID: <1288785496.28.0.000850188381675.issue10263@psf.upfronthosting.co.za>


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

Ah, yes, I see what you mean - because runpy ignores the sys.modules cache (by design), it won't see the precached module instance placed there by the bootstrap code.

We actually *could* make this work on our end: if we find an existing module in sys.modules, derive the file to be executed from the __file__ attribute of that module rather than searching the whole path again.

----------

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

From report at bugs.python.org  Wed Nov  3 12:59:54 2010
From: report at bugs.python.org (Roger Upole)
Date: Wed, 03 Nov 2010 11:59:54 +0000
Subject: [issue10181] get_shape0 in memoryobject.c not checked for error return
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288785594.53.0.159772587323.issue10181@psf.upfronthosting.co.za>


Roger Upole <rupole at hotmail.com> added the comment:

While on the subject, the docs for PyMemoryView_FromBuffer state that the resulting memoryview takes ownership of the Py_buffer struct and is responsible for freeing any associated memory.  It does not do so, which is not surprising.  The absence of a standard for allocation makes it absolutely impossible for it to do so safely.

----------

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

From report at bugs.python.org  Wed Nov  3 13:19:56 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 03 Nov 2010 12:19:56 +0000
Subject: [issue10181] get_shape0 in memoryobject.c not checked for error return
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288786796.97.0.586977101382.issue10181@psf.upfronthosting.co.za>


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

Hmm, if we're ever creating a new copy of a Py_buffer without calling GetBuffer again on the original object, then *that* is a bug (exactly comparable to copying a PyObject pointer without incrementing the reference count - it's OK if you can guarantee the lifecycle of your borrowed pointer is shorter than the lifecycle of the original, but disallowed otherwise).

This still doesn't sound like a problem with the spec to me, it sounds like a problem with the implementation strategy that was originally used when integrating the spec into the interpeter core (which I readily agree received far less attention than the spec itself did).

It really sounds like we should be creating a _Py_ManagedBuffer internal object, with each instance containing a PyObject* and a Py_buffer instance. We don't need to alter PEP 3118 to do that - such a change is entirely consumer side, so the objects providing the buffers don't need to care how the lifecycle of the Py_buffer struct is managed.

When we need another reference to the buffer, we can then just increment the refcount of the _Py_ManagedBuffer instance rather than having to call GetBuffer again on the original object.

The contents of Py_buffer objects that have been passed to GetBuffer really shouldn't be getting modified at all - for those cases, we should maintain *two* Py_buffer structs, one (unmodified) with the original results of the GetBuffer call, and a second owned by the caller (for manipulation).

----------

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

From report at bugs.python.org  Wed Nov  3 13:21:52 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 03 Nov 2010 12:21:52 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288786912.75.0.0782611526963.issue10181@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
title: get_shape0 in memoryobject.c not checked for error return -> Problems with Py_buffer management in memoryobject.c (and elsewhere?)

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

From report at bugs.python.org  Wed Nov  3 13:42:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 03 Nov 2010 12:42:08 +0000
Subject: [issue10263] "python -m site" does not print path details
In-Reply-To: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>
Message-ID: <1288788128.25.0.913704223304.issue10263@psf.upfronthosting.co.za>


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

Sounds good to me.

----------

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

From report at bugs.python.org  Wed Nov  3 13:51:52 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 03 Nov 2010 12:51:52 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288788712.4.0.755696279881.issue10181@psf.upfronthosting.co.za>


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

It doesn't help that neither PEP 3118 nor the Py_buffer docs mention the "obj" member of the Py_buffer struct that refers back to the original object providing the buffer - that's fairly fundamental to understanding how PyBuffer_Release and PyMemoryView_FromBuffer can work even in theory.

(Given that, an additional _PyManagedBuffer object shouldn't be necessary - MemoryView just needs to call ReleaseBuffer and GetBuffer at the appropriate times)

----------

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

From report at bugs.python.org  Wed Nov  3 14:00:36 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 03 Nov 2010 13:00:36 +0000
Subject: [issue10181] Problems with Py_buffer management in memoryobject.c
	(and elsewhere?)
In-Reply-To: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>
Message-ID: <1288789236.21.0.230161432379.issue10181@psf.upfronthosting.co.za>


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

So the overall to-do list here is sounding like:

1. Document "Py_buffer->obj" appropriately in both the C API documentation and in PEP 3118

2. Ensure GetBuffer/ReleaseBuffer are used as the moral equivalent of INCREF/DECREF for Py_buffer objects.

3. Check builtin types correctly manage the lifecycle of all elements of their exported Py_buffer structs

4. Check return values and throw exceptions as noted in the original post

----------

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

From report at bugs.python.org  Wed Nov  3 14:01:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Nov 2010 13:01:25 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288789285.15.0.420993930529.issue10273@psf.upfronthosting.co.za>


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

assertEquals existed forever, too, but we deprecated that :) (with no intent to remove it, as I understand it).

There is no more ambiguity in "assertLessThan" than there is in assertLT, one just has more letters.  True, you have to look it up the first time, but you have to do that anyway, so I don't see that as a big deal.  Once you've looked it up the first time you know the naming rule and you can figure out all the other names.  (Which is not true now, since instead of 'LessThan' we have "Less", which does *not* correspond to to the special method name by a simple rule).

----------

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

From report at bugs.python.org  Wed Nov  3 14:26:02 2010
From: report at bugs.python.org (Tod Olson)
Date: Wed, 03 Nov 2010 13:26:02 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1288790762.17.0.999666874301.issue4147@psf.upfronthosting.co.za>


Changes by Tod Olson <tod at uchicago.edu>:


----------
nosy: +tod

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

From report at bugs.python.org  Wed Nov  3 14:28:25 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 03 Nov 2010 13:28:25 +0000
Subject: [issue10295] _socket.pyd uses winsock2, select.pyd uses winsock 1
In-Reply-To: <1288764115.88.0.357779080417.issue10295@psf.upfronthosting.co.za>
Message-ID: <1288790905.42.0.810850903646.issue10295@psf.upfronthosting.co.za>


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

committed as revision 86136

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

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

From report at bugs.python.org  Wed Nov  3 14:57:45 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 03 Nov 2010 13:57:45 +0000
Subject: [issue9981] let make_buildinfo use a temporary directory on windows
In-Reply-To: <1285741718.07.0.0571419018875.issue9981@psf.upfronthosting.co.za>
Message-ID: <1288792665.2.0.263009094498.issue9981@psf.upfronthosting.co.za>


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

Committed to 3.2 in revision 86137

----------
resolution:  -> accepted
status: open -> closed
versions: +Python 3.2 -Python 2.7

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

From report at bugs.python.org  Wed Nov  3 15:00:39 2010
From: report at bugs.python.org (rep)
Date: Wed, 03 Nov 2010 14:00:39 +0000
Subject: [issue10298] zipfile: incorrect comment size will prevent extracting
In-Reply-To: <1288792839.67.0.901999285278.issue10298@psf.upfronthosting.co.za>
Message-ID: <1288792839.67.0.901999285278.issue10298@psf.upfronthosting.co.za>


New submission from rep <ms at mwcollect.org>:

Opening (and thus extracting) zip files with appended junk data is not possible with the way the current zipfile implementation checks validity. Basically the problem comes down to the comment size in the end-of-central-directory record being different from the size of the data following that record.

Unix unzip and similar utilities handle that case by looking at the eocd-record and taking that as the correct value. Zip files with data appended to them will be extracted just fine with these tools.

In python's zipfile the _EndRecData function will return None if the comment size does not match the record's value.

The patch modifies this behaviour and takes only the portion of trailing data that the record specifies and due to that it does not raise BadZipfile exceptions if there's any junk data appended to a zip file.

----------
components: Library (Lib)
files: zipfile_recover_commentsize.patch
keywords: patch
messages: 120326
nosy: rep
priority: normal
severity: normal
status: open
title: zipfile: incorrect comment size will prevent extracting
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19477/zipfile_recover_commentsize.patch

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

From report at bugs.python.org  Wed Nov  3 15:24:59 2010
From: report at bugs.python.org (nestor)
Date: Wed, 03 Nov 2010 14:24:59 +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: <1288794298.88.0.884491179751.issue10299@psf.upfronthosting.co.za>


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

The built-in function page (http://docs.python.org/dev/py3k/library/functions.html) is pretty long. Each function has an anchor but unlike the built-in types section there is no quick way to get an overview or jump to a specific function (like open or print) short of scrolling through 22 pages. It would be nice to have an index of all built-in functions linked to the specific entry on the built-in functions page. This could be either somehow added to the index page (http://docs.python.org/dev/py3k/library/index.html) or to the top of the built-in functions page itself. For efficient use of real-estate multiple function names could be on one single line alphabetically sorted and separated by spaces.

----------
assignee: docs at python
components: Documentation
messages: 120327
nosy: docs at python, georg.brandl, nestor
priority: normal
severity: normal
status: open
title: Add index with links section for built-in functions
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Wed Nov  3 15:26:57 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Nov 2010 14:26:57 +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: <1288794417.9.0.823571123109.issue10299@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> needs patch

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

From report at bugs.python.org  Wed Nov  3 16:54:22 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Wed, 03 Nov 2010 15:54:22 +0000
Subject: [issue10300] Documentation of three PyDict_* functions
In-Reply-To: <1288799659.81.0.759259964025.issue10300@psf.upfronthosting.co.za>
Message-ID: <1288799659.81.0.759259964025.issue10300@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hagen at zhuliguan.net>:

The documentation of the functions PyDict_Items, PyDict_Keys and PyDict_Values is incorrect: They do return PyListObject, but in Python 3.x this is not the same as dict.items() etc.

----------
assignee: docs at python
components: Documentation
messages: 120328
nosy: docs at python, hagen
priority: normal
severity: normal
status: open
title: Documentation of three PyDict_* functions
versions: Python 3.1, Python 3.2

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

From report at bugs.python.org  Wed Nov  3 17:33:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Nov 2010 16:33:05 +0000
Subject: [issue10284] NNTP should accept bytestrings for username and password
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288801985.52.0.77647778345.issue10284@psf.upfronthosting.co.za>


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


----------
resolution: invalid -> 
stage: committed/rejected -> needs patch
status: closed -> open
title: Exception raised when decoding NNTP newsgroup descriptions -> NNTP should accept bytestrings for username and password

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

From report at bugs.python.org  Wed Nov  3 17:34:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Nov 2010 16:34:25 +0000
Subject: [issue2281] Enhanced cPython profiler with high-resolution timer
In-Reply-To: <1205359008.42.0.436050296007.issue2281@psf.upfronthosting.co.za>
Message-ID: <1288802065.57.0.821459953797.issue2281@psf.upfronthosting.co.za>


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


----------
nosy: +krisvale

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

From report at bugs.python.org  Wed Nov  3 17:59:36 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 03 Nov 2010 16:59:36 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1288803576.6.0.444163153053.issue9995@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Do you have a list of more important tasks than this one. I'd like to elaborate, because for me alone it could take a lot of time. What I need now is SVN URL to checkout distutils code and some advice where to start. No guarantees though - if the code is too complicated, I won't be able to dedicate much time for exploration.

----------

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

From report at bugs.python.org  Wed Nov  3 18:03:24 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Nov 2010 17:03: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: <1288803804.38.0.784294249007.issue10299@psf.upfronthosting.co.za>


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

The attached patch adds a 4-columns table that lists the functions without args.

----------
assignee: docs at python -> ezio.melotti
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19478/issue10299.diff

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

From report at bugs.python.org  Wed Nov  3 18:10:51 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 03 Nov 2010 17:10:51 +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: <1288804251.15.0.912068521781.issue10299@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy: +fdrake

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

From report at bugs.python.org  Wed Nov  3 18:27:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Nov 2010 17:27:52 +0000
Subject: [issue10297] decimal module documentation is misguiding
In-Reply-To: <1288780221.67.0.597486897879.issue10297@psf.upfronthosting.co.za>
Message-ID: <1288805272.5.0.316540422766.issue10297@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/issue10297>
_______________________________________

From report at bugs.python.org  Wed Nov  3 18:37:52 2010
From: report at bugs.python.org (5houston)
Date: Wed, 03 Nov 2010 17:37:52 +0000
Subject: [issue8028] self.terminate() from a multiprocessing.Process raises
	AttributeError exception
In-Reply-To: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za>
Message-ID: <1288805872.14.0.435949160449.issue8028@psf.upfronthosting.co.za>


5houston <cadabras at gmail.com> added the comment:

I vote for the latter.

----------

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

From report at bugs.python.org  Wed Nov  3 18:55:55 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Wed, 03 Nov 2010 17:55:55 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288806955.85.0.708016176321.issue10281@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

> Er, so you're disagreeing with your previous message?
> Or am I missing something? :)

I was saying that if an empty string is returned, then it means that the header exists and is empty.  An example was "User-Agent: \r\n".
And my remark "I believe None is better." concerned your initial question "Should the field be totally absent [...]" regarding how to deal with a header that does not exist.

Therefore, "User-Agent: \r\n" becomes a real '', not None.  None is only when the User-Agent: header field is absent from the headers.



> Here is a patch trying to better handle whitespace.
> Would it be ok for you?

Yes Antoine, thanks!

----------

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

From report at bugs.python.org  Wed Nov  3 19:01:09 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Wed, 03 Nov 2010 18:01:09 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288807269.96.0.136484698532.issue10281@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

> My conclusion in working on the email package is that only
> the first space after the ':', if it exists, should be stripped.
> That is, even though the RFC (for email) reads as if the space
> after the colon is part of the value, in practice it is part
> of the delimiter, but is optional (and almost always present,
> in email).

That is why the RFC (for netnews) explicitly mentions that the space after the colon is not part of the value.  See the grammar for OVER in RFC 3977:

  hdr-n-content = [(header-name ":" / metadata-name) SP hdr-content]

So yes, only the first space should be stripped.

----------

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

From report at bugs.python.org  Wed Nov  3 19:10:20 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Wed, 03 Nov 2010 18:10:20 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288807820.12.0.432104131685.issue1926@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

>> * starttls() should probably test the `tls_on` attribute first and
>> raise a ValueError if True (as you point out, a client mustn't attempt
>> to start a new TLS session if one is already active).
>
> ...I actually meant to do exactly that, but forgot to put the check
> in. Thank you. 

And it should also make sure the user is not already authenticated.
And that STARTTLS is advertised (if nntp_version >=2).

----------

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

From report at bugs.python.org  Wed Nov  3 19:19:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Nov 2010 18:19:29 +0000
Subject: [issue10281] Exception raised when an NNTP overview field is absent
In-Reply-To: <1288641504.02.0.740146955118.issue10281@psf.upfronthosting.co.za>
Message-ID: <1288808369.53.0.239275219428.issue10281@psf.upfronthosting.co.za>


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

Ok, committed in r86139.

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

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

From report at bugs.python.org  Wed Nov  3 19:26:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Nov 2010 18:26:20 +0000
Subject: [issue10282] IMPLEMENTATION token differently delt with in NNTP
	capability
In-Reply-To: <1288642567.32.0.7785411032.issue10282@psf.upfronthosting.co.za>
Message-ID: <1288808780.32.0.237935041277.issue10282@psf.upfronthosting.co.za>


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

Rather than special casing the dict item, I would rather add an "nntp_implementation" attribute containing the desired value.

> Besides, shouldn't it be checked that the line is not empty, before
> splitting it?

If the line is empty, the server is non-conformant. Then it's a matter of taste whether all errors should be wrapped in higher-level exceptions; I tend to think it's useless clutter.

----------

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

From report at bugs.python.org  Wed Nov  3 19:27:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 03 Nov 2010 18:27:41 +0000
Subject: [issue10171] Ugly buttons in some Tkinter objects in Windows
In-Reply-To: <1287714866.92.0.753573590678.issue10171@psf.upfronthosting.co.za>
Message-ID: <1288808861.3.0.976140789298.issue10171@psf.upfronthosting.co.za>


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

Thanks!

----------

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

From report at bugs.python.org  Wed Nov  3 19:33:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 03 Nov 2010 18:33:15 +0000
Subject: [issue10285] Other status field flags in documentation for NNTP LIST
	command
In-Reply-To: <1288643123.11.0.762395184057.issue10285@psf.upfronthosting.co.za>
Message-ID: <1288809195.7.0.118303957124.issue10285@psf.upfronthosting.co.za>


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

Improvement committed in r86140, thank you!

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

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

From report at bugs.python.org  Wed Nov  3 19:38:51 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Wed, 03 Nov 2010 18:38:51 +0000
Subject: [issue10282] IMPLEMENTATION token differently delt with in NNTP
	capability
In-Reply-To: <1288642567.32.0.7785411032.issue10282@psf.upfronthosting.co.za>
Message-ID: <1288809531.82.0.36776591303.issue10282@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

The "nntp_implementation" attribute would be great.
OK for the exception.

----------

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

From report at bugs.python.org  Wed Nov  3 20:05:12 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 03 Nov 2010 19:05:12 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1288811112.7.0.988937385991.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

@rpetrov: reusing $LDVERSION does make sense, but then I think the variable is misnamed.  I don't like $ABIVERSION either but maybe $BUILDVERSION?

Also I think we need to let the substitution for $LDVERSION happen in the Makefile rather than in the configure script.  I tried it the way you suggested and IIRC, it had some problems, but I don't remember the details.

@doko: Agreed.  I'll have an updated patch that fixes python.pc.  I'll look at INSTALL_SCHEME/headers too.

----------

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

From report at bugs.python.org  Wed Nov  3 20:32:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 03 Nov 2010 19:32:24 +0000
Subject: [issue10284] NNTP should accept bytestrings for username and password
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288812744.25.0.755654545118.issue10284@psf.upfronthosting.co.za>


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

What I meant by saying that the spec was broken is that the user is going to be typing the password at a keyboard.  The keyboard will generate scan codes.  Those scan codes will get interpreted through a system-specific chain of processes until some bytes or some unicode characters are generated.  What's to say that the password typed on the keyboard where the password is set up is going to be a binary match for the password entered on the keyboard used for authentication?

Which doesn't change the fact that if the spec calls for binary, nttplib should support binary.

----------

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

From report at bugs.python.org  Wed Nov  3 20:38:30 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 03 Nov 2010 19:38:30 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1288813110.04.0.0139128048826.issue9995@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Fix attached. Also on Rietveld - http://codereview.appspot.com/2874041

Could you also backport it to other Python distributions to avoid questions like these:

http://stackoverflow.com/questions/3773613/pypi-issues-upload-failed-401-you-must-be-identified-to-edit-package-informa
http://stackoverflow.com/questions/1750186/weird-pypi-authentication-behavior

----------
keywords: +patch
Added file: http://bugs.python.org/file19479/issue9995.distutils-forces-developers-to-store-password-in-cleartext.diff

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

From report at bugs.python.org  Wed Nov  3 21:24:08 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Wed, 03 Nov 2010 20:24:08 +0000
Subject: [issue10284] NNTP should accept bytestrings for username and password
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288815848.56.0.241662958533.issue10284@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

OK, I understand.  I believe it works fine in practice, because people often use ASCII-only characters...  I assume it is going to be a problem when the passwords contain 8-bit characters.
I doubt it will work fine if I use different news readers on different localized systems...

Interesting question.  I will ask how it should be handled.

----------

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

From report at bugs.python.org  Wed Nov  3 21:24:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 03 Nov 2010 20:24:24 +0000
Subject: [issue1500504] Alternate RFC 3986 compliant URI parsing module
Message-ID: <1288815864.26.0.3281844062.issue1500504@psf.upfronthosting.co.za>


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

Sure, adding tests is a no-brainer.

Regarding the module, I?m a bit reluctant.  I see value in providing low-level building blocks (think OS calls) and high-level utilities for regular use, but here it seems that urllib.parse and urischemes are at the same level.  I?m not opposed to the functionality itself?I would like to use a class simply named ?URI? (and generally get better names, that is RFC names instead of specific inventions), have components normalization and such goodies?but I think the existing module can get fixes and improvements.  I fear the confusion that could be caused by having two modules for the same task, unless you want to propose that the new module deprecate urllib.parse.

Senthil, what is your opinion?

----------

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

From report at bugs.python.org  Wed Nov  3 21:38:39 2010
From: report at bugs.python.org (Ask Solem)
Date: Wed, 03 Nov 2010 20:38:39 +0000
Subject: [issue8028] self.terminate() from a multiprocessing.Process raises
	AttributeError exception
In-Reply-To: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za>
Message-ID: <1288816719.84.0.372685056004.issue8028@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Since you can't specify the return code, `self.terminate` is less flexible than `sys.exit`.

I think the original intent is clear here, the method is there for the parent to control the child.  You are of course welcome to argue otherwise.

By the way, I just read the code and noticed that it handles SystemExit well, and supports using it to set the return code:

    class X(Process):
        def run(self):
            if not frobulating:
                raise SystemExit(255)

----------

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

From report at bugs.python.org  Wed Nov  3 22:28:58 2010
From: report at bugs.python.org (t.steinruecken)
Date: Wed, 03 Nov 2010 21:28:58 +0000
Subject: [issue10301] Zipfile cannot be used in "with" Statement
In-Reply-To: <1288819738.25.0.351027689616.issue10301@psf.upfronthosting.co.za>
Message-ID: <1288819738.25.0.351027689616.issue10301@psf.upfronthosting.co.za>


New submission from t.steinruecken <t.steinruecken at service4every1.de>:

Using a ZipFile as a "with"-context dosnt work
(Im using the standard Ubuntu version of Python3.1)

Python 3.1.2 (r312:79147, Apr 15 2010, 15:35:48) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from zipfile import ZipFile
>>> with ZipFile("test.zip","w") as z:
...     z.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'ZipFile' object has no attribute '__exit__'
>>>

----------
components: Extension Modules
messages: 120346
nosy: t.steinruecken
priority: normal
severity: normal
status: open
title: Zipfile cannot be used in "with" Statement
type: behavior
versions: Python 3.1

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

From report at bugs.python.org  Wed Nov  3 22:35:55 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Nov 2010 21:35:55 +0000
Subject: [issue10300] Documentation of three PyDict_* functions
In-Reply-To: <1288799659.81.0.759259964025.issue10300@psf.upfronthosting.co.za>
Message-ID: <1288820155.26.0.821267091486.issue10300@psf.upfronthosting.co.za>


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

r86144

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

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

From report at bugs.python.org  Wed Nov  3 22:40:22 2010
From: report at bugs.python.org (Alex)
Date: Wed, 03 Nov 2010 21:40:22 +0000
Subject: [issue10301] Zipfile cannot be used in "with" Statement
In-Reply-To: <1288819738.25.0.351027689616.issue10301@psf.upfronthosting.co.za>
Message-ID: <1288820422.21.0.913264369036.issue10301@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Context manager support was added in 3.2

----------
nosy: +alex

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

From report at bugs.python.org  Wed Nov  3 22:42:28 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 03 Nov 2010 21:42:28 +0000
Subject: [issue10301] Zipfile cannot be used in "with" Statement
In-Reply-To: <1288819738.25.0.351027689616.issue10301@psf.upfronthosting.co.za>
Message-ID: <1288820548.8.0.0633700283256.issue10301@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Wed Nov  3 22:47:36 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 03 Nov 2010 21:47:36 +0000
Subject: [issue1500504] Alternate RFC 3986 compliant URI parsing module
Message-ID: <1288820856.81.0.90415017671.issue1500504@psf.upfronthosting.co.za>


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

Just to be clear, even *I* don't think adding urischemes as it stands is a particularly great idea, and I wrote it. The only reason I haven't closed the issue is because I'd like to see it mined for additional tests in test_urlparse and perhaps even implementation or API enhancements in url.parse first.

(The latter becomes a lot more likely if the urischemes implementation passes tests that url.parse fails)

I also think, since I wrote this, the various urllib parsing methods were updated to return named tuple instances with properties, so a lot of the awkwardness of extracting partial values went away. (i.e. returning structured objects already raised the level of the urllib APIs from the "tuple-of-strings" level they used to be sitting at)

I do still assert that urischemes is slightly "higher level" than the current incarnation of similar functionality in urllib.parse. Universal Resource Identifiers are more encompassing than Universal Resource Locators and Universal Resource Names, and the new APIs explicitly deal with both kinds of URI. There are subtle differences in the assumptions you're allowed to make when you may have a URN rather than a URL, so I believe the current module sometimes does the wrong thing when given one of the former.

That said, it's been a long time since I've needed to remember the details, so I don't recall exactly where the current module gets URI handling wrong (or at least, did back in 2006). The intro to RFC 3986 is a good place to start in learning the differences though - Sir Tim writes good docs :)

----------

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

From report at bugs.python.org  Wed Nov  3 23:27:58 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Wed, 03 Nov 2010 22:27:58 +0000
Subject: [issue10284] NNTP should accept bytestrings for username and password
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1288823278.85.0.70584667725.issue10284@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

I quote what Russ Allbery has just answered on news.software.nntp:


It's completely unspecified what encoding to use for AUTHINFO USER/PASS,
which is one of the problems fixed by SASL.  Clients should always use
SASL where possible because of things like this.  None of the legacy
authentication mechanisms (for protocols besides NNTP, as well) support
character sets.

If they have to fall back to AUTHINFO USER/PASS, they're unfortunately
just going to have to guess.  Most clients previously probably just sent
whatever bytes across the wire that corresponded to the local character
set encoding of the username and password.

In practice, using anything other than ASCII in passwords with AUTHINFO
USER/PASS is not going to be portable and won't work reliably.

> ** How do current news readers send them to news servers?
> ** And how news servers should decode them?

News servers probably can't do anything better than just accepting them as
a byte stream and doing a byte-by-byte comparison against local
configuration.

----------

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

From report at bugs.python.org  Wed Nov  3 23:40:26 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Nov 2010 22:40:26 +0000
Subject: [issue10301] Zipfile cannot be used in "with" Statement
In-Reply-To: <1288819738.25.0.351027689616.issue10301@psf.upfronthosting.co.za>
Message-ID: <1288824026.59.0.653398480296.issue10301@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> committed/rejected

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

From report at bugs.python.org  Wed Nov  3 23:42:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Nov 2010 22:42:01 +0000
Subject: [issue8886] zipfile.ZipExtFile is a context manager,
	but that is not documented
In-Reply-To: <1275565167.77.0.94387257463.issue8886@psf.upfronthosting.co.za>
Message-ID: <1288824121.26.0.231262927645.issue8886@psf.upfronthosting.co.za>


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


----------
nosy: +ezio.melotti
stage:  -> patch review

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

From report at bugs.python.org  Wed Nov  3 23:44:17 2010
From: report at bugs.python.org (Lukas Lueg)
Date: Wed, 03 Nov 2010 22:44:17 +0000
Subject: [issue10302] Add class-functions to hash many small objects with
	hashlib
In-Reply-To: <1288824257.88.0.548360154902.issue10302@psf.upfronthosting.co.za>
Message-ID: <1288824257.88.0.548360154902.issue10302@psf.upfronthosting.co.za>


New submission from Lukas Lueg <lukas.lueg at gmail.com>:

The objects provided by hashlib mainly serve the purpose of computing hashes over strings of arbitrary size. The user gets a new object (e.g. hashlib.sha1()), calls .update() with chunks of data and then finally uses .digest() or .hexdigest() to get the hash. For convenience reasons these steps can also be done in almost one step (e.g. hashlib.sha1('foobar').hexdigest()).
While the above approach basically covers all use-cases for hash-functions, when computing hashes of many small strings it is yet inefficient (e.g. due to interpreter-overhead) and leaves out the possibility for performance improvements.

There are many cases where we need the hashes of numerous (small) objects, most or all of which being available in memory at the same time.

I therefor propose to extend the classes provided by hashlib with an additional function that takes an iterable object, computes the hash over the string representation of each member and returns the result. Due to the aim of this interface, the function is a member of the class (not the instance) and has therefor no state bound to an instance. Memory requirements are to be anticipated and met by the programmer.

For example:

foo = ['my_database_key1', 'my_database_key2']
hashlib.sha1.compute(foo) 
>> ('\x00\x00', '\xff\xff')


I consider this interface to hashlib particular useful, as we can take advantage of vector-based implementations that compute multiple hashes in one pass (e.g. through SSE2). GCC has a vector-extension that provides a *somewhat* standard way to write code that can get compiled to SSE2 or similar machine code. Examples of vector-based implementations of SHA1 and MD5 can be found at https://code.google.com/p/pyrit/issues/detail?id=207


Contigency plan: We compile to code iterating over OpenSSL's EVP-functions if compiler is other than GCC or SSE2 is not available. The same approach can be used to cover hashlib-objects for which we don't have an optimized implementation.

----------
components: Library (Lib)
messages: 120351
nosy: ebfe
priority: normal
severity: normal
status: open
title: Add class-functions to hash many small objects with hashlib
type: feature request
versions: Python 3.2, Python 3.3

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

From report at bugs.python.org  Thu Nov  4 00:06:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Nov 2010 23:06:48 +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: <1288825608.51.0.870131650343.issue10242@psf.upfronthosting.co.za>


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

Suggestions:

* new name:  assertCountEqual(a, b)
  or:        assertElementCountEqual(a, b)

  this name captures the essential service:

  - unordered comparison where duplicates matter
  - inputs are "elements", 
    not "items" which means key/value pairs


* O(n) implementation with O(n**2) fallback:

   try:
     a_cnt = collections.Counter(a)
     b_cnt = collections.Counter(b)
   except TypeError:
     # do current O(n**2) fallback
   else:
       if a_cnt == b_cnt:
          # test passed
       else:
          in_a_but_not_in_b = a - b
          in_b_but_not_in_a = b - a
          # display nice diff

* documentation should emphasize the new name:

  assertElementCountEqual(a, b)
  obsolete alias:  assertItemsEqual(a, b)

----------
assignee: rhettinger -> michael.foord

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

From report at bugs.python.org  Thu Nov  4 00:14:37 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 03 Nov 2010 23:14:37 +0000
Subject: [issue9796] Add summary tables for unittest API
In-Reply-To: <1283906621.68.0.367606257735.issue9796@psf.upfronthosting.co.za>
Message-ID: <1288826077.26.0.472664292567.issue9796@psf.upfronthosting.co.za>


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

I committed the patch in r86141 and a few other fixes in r86142 and r86143. There are still more things I want to fix before I backport all the patches to 3.1 and 2.7 and close the issue.

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

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

From report at bugs.python.org  Thu Nov  4 00:21:39 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Wed, 03 Nov 2010 23:21:39 +0000
Subject: [issue10155] Add fixups for encoding problems to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1288826499.13.0.1742116057.issue10155@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Committed to Py3K in r86146, with added docs and a larger list of transcodable CGI variables.

----------

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

From report at bugs.python.org  Thu Nov  4 00:33:20 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 03 Nov 2010 23:33:20 +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: <1288827200.55.0.716619606448.issue10242@psf.upfronthosting.co.za>


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

> I'd be inclined to insert a check that falls back 
> to the "unorderable_list_difference" approach in 
> the case where "expected != sorted(reversed(expected))".

Too fragile and subtle.  The method need to be absolutely straight-forward.

----------

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

From report at bugs.python.org  Thu Nov  4 00:36:08 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 03 Nov 2010 23:36:08 +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: <1288827368.06.0.393935295082.issue10242@psf.upfronthosting.co.za>


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

assertElementCountEqual is good name and I like your implementation suggestion. I'll put this in. I think the implementation fix can go into 2.7 as well but not the rename/aliasing.

----------

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

From report at bugs.python.org  Thu Nov  4 00:52:35 2010
From: report at bugs.python.org (Michael Foord)
Date: Wed, 03 Nov 2010 23:52:35 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288828355.24.0.851805937208.issue10273@psf.upfronthosting.co.za>


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

Renaming and aliasing methods has a cost. It confuses users of the old names (including future users - the current API is now baked into django 1.3 unless I can get an update done in time for them to change the version they're using). People who use autocomplete or introspection (dir) to explore the APIs will also still come across the old names. Given that unittest has just changed a lot a further radical change is 'unfortunate'.

However, for both the regexp methods and the Items method the names are actually misleading.

For assertItemsEqual Raymond suggests assertElementCountsEqual. See issue 10242.

For the regexp methods we should use assertRegexp - this is shorter, not misleading and consistent with assertRaisesRegexp.

We should leave the gt / le / lt methods as they are. There is less consensus that these methods should be changed anyway.

The documentation can be improved by moving *all* the deprecated methods (new and old) out of the main documentation and into a separate section at the end of the documentation.

The type specific asserts we should also move into their own section and out of the main documentation. This means users who discover don't have to go to the source (there are online references) but they are out of the main documentation.

Hopefully everyone is only equally unhappy with this resolution.

----------

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

From report at bugs.python.org  Thu Nov  4 00:52:48 2010
From: report at bugs.python.org (Max Skaller)
Date: Wed, 03 Nov 2010 23:52:48 +0000
Subject: [issue10243] Packaged Pythons
In-Reply-To: <4CCBCC03.8020200@v.loewis.de>
Message-ID: <AANLkTi=7ete0-Jb+an-+xEZhd-q4iQvy9mR46VmxsOdy@mail.gmail.com>


Max Skaller <max.skaller at gmail.com> added the comment:

On Sat, Oct 30, 2010 at 6:40 PM, Martin v. L??wis <report at bugs.python.org>wrote:

It may be there is none. You need to read the bit where I explain that I am
not building Python, I'm grabbing pre-made packages, for OSX and for Ubuntu.

The problem is that these packages don't seem to supply a dynamic link
version.

My problem cannot be solved by telling me I can build Python myself with
the --enable-shared switch, because I am not the client. I am a vendor
supplying a tool that can generate Python shared libraries which cannot run
unless the CLIENT has a shared library version of libpython. So you're
telling me to tell THEM to build Python with --enable-shared switch which is
out of the question for many of them, who may, for example, be programmers
working in a shop where they do not have the ability to change the system
installed by their system admin.

So the problem is that the *packagers* are not supplying the dynamic lib.

Surely that is not the Python dev's issue directly, but it IS an issue the
Python dev's can do something about, by talking to the packagers.

Anyhow, I will give up. I can't test the feature of the compiler I have
implemented
because I don't have a libpython.so and I have no intention of building one,
because I can't expect all those Python users out there to do it either.

It seems you really don't understand the requirements for dynamic linking:
my application code is exclusively in a dlopen()d shared library, so if it
is
used AS a python module or it wants itself to USE a Python extension
module OR Python interpreter itself, it cannot do so.

The top level application is a fixed mainline which does not include
libpython.a or any such symbols.

It's a basic design principle, Meyer called it "the principle of explicit
interfaces"
which means: if you depend on something make the dependency explicit.

Extension modules which do not *explicitly* link against libpython break
this rule.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10243>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Sat, Oct 30, 2010 at 6:40 PM, Martin v. L??wis <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Martin v. L??wis &lt;<a href="mailto:martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br>
<div class="im"><br>
&gt; Python 2.6, for example, does ship a shared library.<br><br></div>
<br>
I fail to see the bug in this report.<br><br></blockquote><div><br>It may be there is none. You need to read the bit where I explain that I am not building Python, I&#39;m grabbing pre-made packages, for OSX and for Ubuntu.<br>
<br>The problem is that these packages don&#39;t seem to supply a dynamic link version.<br><br>My problem cannot be solved by telling me I can build Python myself with<br>the --enable-shared switch, because I am not the client. I am a vendor supplying a tool that can generate Python shared libraries which cannot run unless the CLIENT has a shared library version of libpython. So you&#39;re telling me to tell THEM to build Python with --enable-shared switch which is out of the question for many of them, who may, for example, be programmers working in a shop where they do not have the ability to change the system installed by their system admin.<br>
??<br>So the problem is that the *packagers* are not supplying the dynamic lib.<br><br>Surely that is not the Python dev&#39;s issue directly, but it IS an issue the Python dev&#39;s can do something about, by talking to the packagers.<br>
<br>Anyhow, I will give up. I can&#39;t test the feature of the compiler I have implemented<br>because I don&#39;t have a libpython.so and I have no intention of building one,<br>because I can&#39;t expect all those Python users out there to do it either.<br>
<br>It seems you really don&#39;t understand the requirements for dynamic linking:<br>my application code is exclusively in a dlopen()d shared library, so if it is<br>used AS a python module or it wants itself to USE a Python extension<br>
module OR Python interpreter itself, it cannot do so.<br><br>The top level application is a fixed mainline which does not include<br>libpython.a or any such symbols.<br><br>It&#39;s a basic design principle, Meyer called it &quot;the principle of explicit interfaces&quot;<br>
which means: if you depend on something make the dependency explicit.<br><br>Extension modules which do not *explicitly* link against libpython break<br>this rule.<br><br><br></div></div>

From report at bugs.python.org  Thu Nov  4 00:55:02 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 03 Nov 2010 23:55:02 +0000
Subject: [issue3699] test_bigaddrspace broken
In-Reply-To: <1219841607.12.0.523528748152.issue3699@psf.upfronthosting.co.za>
Message-ID: <1288828502.55.0.0223510704614.issue3699@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

After quite a bit of discussion with Antoine on IRC, here it is a preliminary patch: it uses byte instead of string, but at least it works :) I'll work on a string (additional) test class hopefully tomorrow

----------
keywords: +patch
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19481/issue3699-py3k.patch

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

From report at bugs.python.org  Thu Nov  4 01:04:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 00:04:33 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288828355.24.0.851805937208.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288829068.5969.24.camel@localhost.localdomain>


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

> For assertItemsEqual Raymond suggests assertElementCountsEqual. See
> issue 10242.

Why replace a long awkward name with an even longer and more awkward
name?

----------

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

From report at bugs.python.org  Thu Nov  4 01:13:04 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 04 Nov 2010 00:13:04 +0000
Subject: [issue6081] str.format_from_mapping()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1288829584.77.0.00156814108537.issue6081@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Updated patch which adds tests and minimal docs. Named changed to format_map. I'll commit this before 3.2b1 unless I hear a complaint.

----------
keywords: +easy, needs review
resolution:  -> accepted
Added file: http://bugs.python.org/file19482/issue6081-1.diff

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

From report at bugs.python.org  Thu Nov  4 01:21:21 2010
From: report at bugs.python.org (Malte Helmert)
Date: Thu, 04 Nov 2010 00:21:21 +0000
Subject: [issue10303] small inconsistency in tutorial
In-Reply-To: <1288830081.73.0.485204964128.issue10303@psf.upfronthosting.co.za>
Message-ID: <1288830081.73.0.485204964128.issue10303@psf.upfronthosting.co.za>


New submission from Malte Helmert <helmert at informatik.uni-freiburg.de>:

Section "3.1.2. Strings" says "*Once again*, the print() function produces the more readable output.", but as far as I can see (or grep), this is the first time that this aspect of print() is mentioned.

----------
assignee: docs at python
components: Documentation
messages: 120362
nosy: docs at python, maltehelmert
priority: normal
severity: normal
status: open
title: small inconsistency in tutorial
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov  4 01:27:04 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Nov 2010 00:27:04 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288830424.01.0.720043508788.issue10273@psf.upfronthosting.co.za>


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

An alternative would be adding check_order and check_duplicates to assertSameElements and de-deprecate it.

Python 2.7 could be left unchanged because it's too late to add/rename/deprecate methods (it has assertItemsEqual but not assertSameElements). Py3.2 would also be unchanged (assertItemsEqual and the deprecation of assertSameElements are both new in 3.2, assertSameElements has been introduced in 3.1).
They would end up with two different methods though.

The assertSameElements name seems quite good, and providing extra args will make it more flexible (it will cover all the 4 cases listed in msg100685) and the behavior would be clear without clumsy method names.

----------

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

From report at bugs.python.org  Thu Nov  4 01:27:53 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Nov 2010 00:27:53 +0000
Subject: [issue10303] small inconsistency in tutorial
In-Reply-To: <1288830081.73.0.485204964128.issue10303@psf.upfronthosting.co.za>
Message-ID: <1288830473.81.0.624255817104.issue10303@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/issue10303>
_______________________________________

From report at bugs.python.org  Thu Nov  4 01:28:23 2010
From: report at bugs.python.org (Malte Helmert)
Date: Thu, 04 Nov 2010 00:28:23 +0000
Subject: [issue10304] error in tutorial triple-string example
In-Reply-To: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>
Message-ID: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>


New submission from Malte Helmert <helmert at informatik.uni-freiburg.de>:

>From Section 3.1.2 of the tutorial:

  print("""
  Usage: thingy [OPTIONS]
       -h                        Display this usage message
       -H hostname               Hostname to connect to
  """)

  produces the following output:

  _____________________________________________________________
  Usage: thingy [OPTIONS]
       -h                        Display this usage message
       -H hostname               Hostname to connect to
  _____________________________________________________________


That doesn't quite match the behaviour: there should be an extra blank line prepended to the output.

----------
assignee: docs at python
components: Documentation
messages: 120364
nosy: docs at python, maltehelmert
priority: normal
severity: normal
status: open
title: error in tutorial triple-string example
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov  4 01:30:19 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Nov 2010 00:30:19 +0000
Subject: [issue10304] error in tutorial triple-string example
In-Reply-To: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>
Message-ID: <1288830619.83.0.547137437766.issue10304@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/issue10304>
_______________________________________

From report at bugs.python.org  Thu Nov  4 01:44:11 2010
From: report at bugs.python.org (Malte Helmert)
Date: Thu, 04 Nov 2010 00:44:11 +0000
Subject: [issue10304] error in tutorial triple-string example
In-Reply-To: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>
Message-ID: <1288831451.29.0.13903656512.issue10304@psf.upfronthosting.co.za>


Malte Helmert <helmert at informatik.uni-freiburg.de> added the comment:

Here's a related one if you want to get the sample output really 100% correct. In the last example of Section 3, the output in

{>>> a, b = 0, 1
>>> while b < 1000:
...     print(b, end=' ')
...     a, b = b, a+b
...
1 1 2 3 5 8 13 21 34 55 89 144 233 377 610 987}

should have an extra space at the end. (Granted, this is very very minor, but this may make a Python 2.x oldtimer like me wonder if print's end=" " does the same as old Python 2.x's "print b," including suppression of the "softspace".)

----------

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

From report at bugs.python.org  Thu Nov  4 01:54:43 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Nov 2010 00:54:43 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1288832083.9.0.821058443521.issue9732@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18699/static.py

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

From report at bugs.python.org  Thu Nov  4 01:55:01 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Nov 2010 00:55:01 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1288832101.83.0.445642253654.issue9732@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file18701/test_static.py

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

From report at bugs.python.org  Thu Nov  4 01:57:18 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Nov 2010 00:57:18 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1288832238.63.0.0116449159435.issue9732@psf.upfronthosting.co.za>


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

Updated implementation that handles instances with inherited __slots__ members and attributes from C descriptors correctly.

I think is both "good enough" and useful enough to add to inspect. (The remaining constraints are rare or pathological.)

----------
Added file: http://bugs.python.org/file19483/static.py

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

From report at bugs.python.org  Thu Nov  4 01:57:43 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Nov 2010 00:57:43 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1288832263.32.0.990836972417.issue9732@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file19484/test_static.py

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

From report at bugs.python.org  Thu Nov  4 02:03:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 04 Nov 2010 01:03:36 +0000
Subject: [issue10305] Cleanup up ResourceWarnings in multiprocessing
In-Reply-To: <1288832616.21.0.291852483251.issue10305@psf.upfronthosting.co.za>
Message-ID: <1288832616.21.0.291852483251.issue10305@psf.upfronthosting.co.za>


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

As shown in a debug run of test_multiprocessing, at least two places in managers.py apparently leave open sockets. Lines 786 and 805 are the culprits, both util log lines.

----------
components: Library (Lib)
messages: 120367
nosy: asksol, brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: Cleanup up ResourceWarnings in multiprocessing
type: resource usage
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov  4 02:22:46 2010
From: report at bugs.python.org (StevenJ)
Date: Thu, 04 Nov 2010 01:22:46 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288833766.11.0.90440770238.issue1926@psf.upfronthosting.co.za>


StevenJ <sjohnson at sakuraindustries.com> added the comment:

I too was just looking at NNTPS support because I have a need for it. The latest patch looks like great work and I think the things it implements are needed for this library.  But it seems to me that the latest patch combines 3 things which might otherwise be able to be separately considered. NNTPS, START_TLS (RFC 4642) extension and AUTHINFO extension (RFC 4643).  It may be that START_TLS and AUTHINFO are indivisible, I need to read those more, but shouldn't that be a new topic of discussion as this feature request is for NNTPS support?

I also don't understand the difficulty with plain NNTPS as it doesn't need a new interface a very simple patch (attached) achieves NNTPS?? (Most of the patch is test case and variant defaults.  The actual NNTPS code is just:
+        # Make sure we can actually use ssl if its attempted.
+        if ssl_context:
+          self.sslcontext = ssl_context
+          self.sock = self.sslcontext.wrap_socket(self.sock)


I also don't understand why START_TLS and AUTHINFO need to change how the module is interfaced to (separating log in/authentication, etc), my reading of START_TLS and AUTHINFO seem to me that it should all be under the covers.  It even explains this in Section 7 of "Using TLS
with IMAP, POP3 and ACAP" [TLS-IMAPPOP].  That the idea is "It just works".  So surely if someone uses this module and they do not specify NNTPS and it supports START_TLS and AUTHINFO and so does the server then it just works.  Otherwise it seems a bunch of NNTP Extension requirements and processing spills over to the users of this module when they can probably be contained locally??

Perhaps there needs to be a separate feature request "START_TLS and AUTHINFO extension support for nntplib" so the issues and any necessary interface changes can be considered in isolation from simple NNTP over SSL?

I think it would be nice to have NNTPS in for 3.2.

----------
nosy: +StevenJ
Added file: http://bugs.python.org/file19485/nntps_only_patch.diff

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

From report at bugs.python.org  Thu Nov  4 02:25:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Nov 2010 01:25:45 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288833945.26.0.391847299844.issue10273@psf.upfronthosting.co.za>


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

> For the regexp methods we should use assertRegexp 

assertRegex is better.  it matches the name used in other unittest implementations, there is not confusion with camel casing RegExp vs Regexp, and it matches the former name of Python's own regex module.

> We should leave the gt / le / lt methods as they are. 

The assertLessEqual name is non-standard, it will never be spelled right by someone who hasn't used it recently.


> The documentation can be improved by moving *all* the deprecated 
> methods (new and old) out of the main documentation and
> into a separate section at the end of the documentation

See issue 10242 for a suggestion on how to handle renaming (document the new and old name in the same entry, noting that one name is old).


>> For assertItemsEqual Raymond suggests assertElementCountsEqual. 
> Why replace a long awkward name with an even longer 
> and more awkward name?

If length is an issue, assertCountsEqual will also do fine.  The important virtue is clarity.  The problem with ItemsEqual is that it doesn't tell you anything about what it does (unordered comparison where duplicates matter).  Also, the term "items" in Python usually means key/value pairs.  That is why we use the term "elements" in sets, itertools, etc.  In contrast, assertCountsEqual tells you what it does, compares the element counts.  It is the same as Counter(a)==Counter(b) for hashable elements and an equivalent for unhashable elements.

----------

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

From report at bugs.python.org  Thu Nov  4 02:54:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Nov 2010 01:54:32 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288835672.78.0.243686420434.issue10273@psf.upfronthosting.co.za>


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

assertCountsEqual is IMO much clearer than assertItemsCountsEqual (or however you spell it).  I was unclear on what the latter did, but the former is fairly clear.  Ezio's suggestion is also clearer.

Raymond, since you said 'never' your statement about assertLessEqual is clearly false :).  I don't have any problem remembering it (it's just __le__ spelled out using the standard unittest camelcase).  assertLess, on the other hand, I often get wrong, since it is *not* __lt__ spelled out.

----------

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

From report at bugs.python.org  Thu Nov  4 03:04:59 2010
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 04 Nov 2010 02:04:59 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1288697339.3549.1.camel@localhost.localdomain>
Message-ID: <AANLkTik=zGVD3sZJ2VEbWc608LmwXsiR4wGCb0d4JsPS@mail.gmail.com>


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

On Tue, Nov 2, 2010 at 4:29 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>> I spent some time thinking of a name. ?I tried wait_predicate and
>> predicate_wait, but wait_for seemed natural. ?Any other ideas?
>> How about wait_until_true?
>
> wait_for is ok IMO.

Agreed.

>> My original method had this as a free function, but I moved it into
>> the Condition because I could see no other kind of primitive that
>> would use it. ?I agree that it is unfortunate to pull what is
>> essentially a utility function into the Condition variable, so I am
>> leaning towards keeping it a module function.
>
> I'm not sure I see the point. It's an operation on a Condition variable,
> so it's natural to have it as a Condition method. A module function
> would feel rather weird.

Yeah, it should primarily be used as a Condition method. I was
suggesting implementing that Condition method in terms of a threading
function, which would also help other people trying to, say, mock
Condition objects. But that's not a big deal, and I could be wrong
about whether it's useful at all. As I said earlier, I'm happy with
this patch either way. (Note that Condition.wait_for is helpful to
people mocking Condition anyway, since the number of calls is much
more fixed than the calls to Condition.wait.)

----------

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

From report at bugs.python.org  Thu Nov  4 03:24:03 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Nov 2010 02:24:03 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288837443.84.0.483600638143.issue10273@psf.upfronthosting.co.za>


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

> assertLess, on the other hand, I often get wrong, 
> since it is *not* __lt__ spelled out.

Right.  Even Michael gets that one wrong.

Meditate on why Guido created the special method __lt__ instead of __less_than__.

Regardless of why Guido made that choice, we do already have a standard way to spell less-than in Python, and it would be good to stick with it.

----------

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

From report at bugs.python.org  Thu Nov  4 03:41:57 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Nov 2010 02:41:57 +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: <1288838517.53.0.545343816427.issue10242@psf.upfronthosting.co.za>


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

One nuance, it may be better to implement as:

     a_cnt = collections.Counter(iter(a))
     b_cnt = collections.Counter(iter(b))

That will bypass the special handling the Counter constructor has if the  argument is a Mapping.

----------

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

From report at bugs.python.org  Thu Nov  4 04:07:38 2010
From: report at bugs.python.org (David Sankel)
Date: Thu, 04 Nov 2010 03:07:38 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1288840058.53.0.754973636629.issue1602@psf.upfronthosting.co.za>


Changes by David Sankel <camior at gmail.com>:


----------
nosy: +David.Sankel

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

From report at bugs.python.org  Thu Nov  4 04:08:10 2010
From: report at bugs.python.org (David Sankel)
Date: Thu, 04 Nov 2010 03:08:10 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1288840090.2.0.456248507953.issue6058@psf.upfronthosting.co.za>


Changes by David Sankel <camior at gmail.com>:


----------
nosy: +David.Sankel

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

From report at bugs.python.org  Thu Nov  4 04:14:06 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Nov 2010 03:14:06 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1288840446.04.0.613488337219.issue6058@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/issue6058>
_______________________________________

From report at bugs.python.org  Thu Nov  4 04:41:07 2010
From: report at bugs.python.org (Julian)
Date: Thu, 04 Nov 2010 03:41:07 +0000
Subject: [issue7317] Display full tracebacks when an error occurs
	asynchronously
In-Reply-To: <1258140215.22.0.835793798885.issue7317@psf.upfronthosting.co.za>
Message-ID: <1288842067.31.0.976059962904.issue7317@psf.upfronthosting.co.za>


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

Amaury asks: "Is there an already existing flag that could control this behaviour?"

I wonder if the warnings module could be used.

----------
nosy: +oddthinking

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

From report at bugs.python.org  Thu Nov  4 04:49:56 2010
From: report at bugs.python.org (Julian)
Date: Thu, 04 Nov 2010 03:49:56 +0000
Subject: [issue10306] Weakref callback exceptions should be turned into
	warnings.
In-Reply-To: <1288842596.1.0.996476383192.issue10306@psf.upfronthosting.co.za>
Message-ID: <1288842596.1.0.996476383192.issue10306@psf.upfronthosting.co.za>


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

If a weakref callback raises an exception, weakref writes out some text (to stderr, I think) and ignores it.

I think it would be more appropriate if weakref emitted that text using the Python warning module, to allow it to be better controlled.

Consider this code with two foolish mistakes in it:
---------
import warnings
import weakref

warnings.simplefilter('ignore') # Whoops, ignoring warnings is foolish.

def callback(condemned_object):
    raise Exception("Failure") # Whoops, raising an exception in a callback is foolish.

class RandomObject(object):
    pass

strong_ref = RandomObject()
wr = weakref.proxy(strong_ref, callback)
print "Removing the only strong reference"
strong_ref = None
# No guarantee that the garbage collector will trigger
# in practice, in CPython, it does.
print "Shutting down now."

---------
When I run this I get:
Removing the only strong reference
Exception Exception: Exception('Failure',) in <function callback at 0x0280A1B0> ignored
Shutting down now.

The exception text is output even though I don't want it to be. To help me debug, I want for the exception text to be manageable (not by ignoring it, like in the example above, but using the other warnings module features.)

----------
components: Library (Lib)
messages: 120375
nosy: oddthinking
priority: normal
severity: normal
status: open
title: Weakref callback exceptions should be turned into warnings.
type: behavior
versions: Python 2.7

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

From report at bugs.python.org  Thu Nov  4 04:50:22 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 04 Nov 2010 03:50:22 +0000
Subject: [issue10307] compile error in readline.c
In-Reply-To: <1288842622.31.0.254816051601.issue10307@psf.upfronthosting.co.za>
Message-ID: <1288842622.31.0.254816051601.issue10307@psf.upfronthosting.co.za>


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

/py3k/Modules/readline.c: In function flex_complete:
/py3k/Modules/readline.c:877: error: on_completion  undeclared (first use in this function)

----------
assignee: orsenthil
messages: 120376
nosy: orsenthil
priority: normal
severity: normal
status: open
title: compile error in readline.c
type: compile error

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

From report at bugs.python.org  Thu Nov  4 04:55:09 2010
From: report at bugs.python.org (And Clover)
Date: Thu, 04 Nov 2010 03:55:09 +0000
Subject: [issue10155] Add fixups for encoding problems to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1288842909.89.0.640922860652.issue10155@psf.upfronthosting.co.za>


And Clover <and at doxdesk.com> added the comment:

Thanks.

Some of those additions in _needs_transcode are potentially controversial, though. I'm not wholly sure it's the right thing to transcode these.

Some of them may not actually come from the request, eg `REMOTE_USER` may be filled in by IIS's Windows authentication using a native-Unicode string from the Windows user database. Is it the right thing to turn it into UTF-8-bytes-in-Unicode for consistency with Apache? Maybe. (At least for most of the other new envvars there will never see a non-ASCII character. Or in `REMOTE_IDENT`'s case never be used for anything.)

The case with the REDIRECT_HTTP_ and SSL_ envvars is an interesting one. Whilst transcoding them at some point will very probably be what applications need to do if they want to actually use them, is it within CGIHandler's remit to change Apache mod-specific variables that are not specified by CGI or WSGI?

(There might, after all, be lots of these to catch for other mods and servers, and it's *conceivable* that somebody might be re-using one of these names to set in the environment for some other purpose, in which case transcoding would be adding an unexpected mangling. We can't in the general case expect users to know to avoid envvar names are used as non-standard extensions in all servers.)

REDIRECT_HTTP_ at least comes from the HTTP request, so I guess the consistency is good there. (But then I think the only header that actually may contain non-ASCII is REDIRECT_URL, which replaces the unescaped SCRIPT_NAME and PATH_INFO; that one isn't caught at the moment.)

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

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

From report at bugs.python.org  Thu Nov  4 05:12:11 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 04 Nov 2010 04:12:11 +0000
Subject: [issue10307] compile error in readline.c
In-Reply-To: <1288842622.31.0.254816051601.issue10307@psf.upfronthosting.co.za>
Message-ID: <1288843931.46.0.338247407374.issue10307@psf.upfronthosting.co.za>


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

The problem was in py3k, due to a minor overlook in r85680.

Fixed in r86153.

----------
components: +Build
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

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

From report at bugs.python.org  Thu Nov  4 05:44:19 2010
From: report at bugs.python.org (Martin Spacek)
Date: Thu, 04 Nov 2010 04:44:19 +0000
Subject: [issue9015] array.array.tofile cannot write arrays of sizes > 4GB,
	even compiled for amd64
In-Reply-To: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>
Message-ID: <1288845859.64.0.247815291434.issue9015@psf.upfronthosting.co.za>


Martin Spacek <python at mspacek.mm.st> added the comment:

NumPy is addressing this with a workaround in its ndarray, calling fwrite multiple times in reasonably sized chunks. See http://projects.scipy.org/numpy/ticket/1660

----------
nosy: +mspacek
type:  -> crash

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

From report at bugs.python.org  Thu Nov  4 07:19:52 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 04 Nov 2010 06:19:52 +0000
Subject: [issue10243] Packaged Pythons
In-Reply-To: <1288421190.78.0.406160800778.issue10243@psf.upfronthosting.co.za>
Message-ID: <1288851592.49.0.19819499978.issue10243@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

For what it's worth, the python.org installers for Mac OS X do include a libpython shared library.  As of Python 2.7 (and 3.2), the installer includes a symlink to make it easier to find:

$ cd /Library/Frameworks/Python.framework/Versions/2.7/lib
$ ls -l libpython2.7.dylib
$ lrwxr-xr-x  1 root  admin  9 Oct 27 20:46 libpython2.7.dylib@ -> ../Python
$ file ../Python
../Python: Mach-O universal binary with 2 architectures
../Python (for architecture ppc):	Mach-O dynamically linked shared library ppc
../Python (for architecture i386):	Mach-O dynamically linked shared library i386
$ cd /Library/Frameworks/Python.framework/Versions/2.6
$ file Python
Python: Mach-O universal binary with 2 architectures
Python (for architecture ppc):	Mach-O dynamically linked shared library ppc
Python (for architecture i386):	Mach-O dynamically linked shared library i386

In Debian and Ubuntu releases, the shared library is put into its own optionally installed package, libpythonx.x.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Thu Nov  4 07:20:04 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 04 Nov 2010 06:20:04 +0000
Subject: [issue10243] Packaged Pythons
In-Reply-To: <1288421190.78.0.406160800778.issue10243@psf.upfronthosting.co.za>
Message-ID: <1288851604.13.0.932028391314.issue10243@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


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

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

From report at bugs.python.org  Thu Nov  4 07:48:03 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Thu, 04 Nov 2010 06:48:03 +0000
Subject: [issue10300] Documentation of three PyDict_* functions
In-Reply-To: <1288799659.81.0.759259964025.issue10300@psf.upfronthosting.co.za>
Message-ID: <1288853283.95.0.565693563934.issue10300@psf.upfronthosting.co.za>


Hagen F?rstenau <hagen at zhuliguan.net> added the comment:

The ReST links in http://docs.python.org/py3k/c-api/dict.html#PyDict_Items seem to be broken.

----------

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

From report at bugs.python.org  Thu Nov  4 09:29:19 2010
From: report at bugs.python.org (Ask Solem)
Date: Thu, 04 Nov 2010 08:29:19 +0000
Subject: [issue10305] Cleanup up ResourceWarnings in multiprocessing
In-Reply-To: <1288832616.21.0.291852483251.issue10305@psf.upfronthosting.co.za>
Message-ID: <1288859359.67.0.805249303964.issue10305@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

ah, this is something I've seen as well, its part of a bug that I haven't created an issue for yet.

----------

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

From report at bugs.python.org  Thu Nov  4 09:35:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Nov 2010 08:35:51 +0000
Subject: [issue10286] URLOpener => URLopener x2 in fix_urllib.py
In-Reply-To: <1288643335.41.0.951306369167.issue10286@psf.upfronthosting.co.za>
Message-ID: <1288859751.99.0.454024694177.issue10286@psf.upfronthosting.co.za>


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

Fixed in r86157.

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

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

From report at bugs.python.org  Thu Nov  4 09:36:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Nov 2010 08:36:34 +0000
Subject: [issue10293] PyMemoryView object has obsolete members
In-Reply-To: <1288689996.27.0.790374524403.issue10293@psf.upfronthosting.co.za>
Message-ID: <1288859794.1.0.397002229372.issue10293@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/issue10293>
_______________________________________

From report at bugs.python.org  Thu Nov  4 09:40:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Nov 2010 08:40:53 +0000
Subject: [issue10198] wave module writes corrupt wav file for zero-length
	writeframes
In-Reply-To: <1288107337.09.0.986719080657.issue10198@psf.upfronthosting.co.za>
Message-ID: <1288860053.72.0.39764964327.issue10198@psf.upfronthosting.co.za>


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

I'm sorry, the actual revision is r85970.  Why should it be irrelevant for other branches?

----------

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

From report at bugs.python.org  Thu Nov  4 09:49:52 2010
From: report at bugs.python.org (Martin Spacek)
Date: Thu, 04 Nov 2010 08:49:52 +0000
Subject: [issue9015] f.write(s) for s > 2GB hangs in win64 (and win32?)
In-Reply-To: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>
Message-ID: <1288860592.3.0.670484449031.issue9015@psf.upfronthosting.co.za>


Martin Spacek <python at mspacek.mm.st> added the comment:

It turns out this isn't just a problem with array.array. It's a problem with Python's file.write() as well. Here's my test code:

# file.write() test:
FOURGBMINUS = 2**32 - 16
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in xrange(FOURGBMINUS//len(s))])
assert len(longs) == FOURGBMINUS
f = open('test.txt', 'w')
f.write(longs) # completes successfully
f.close()

FOURGB = 2**32
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in xrange(FOURGB//len(s))])
assert len(longs) == FOURGB
f = open('test.txt', 'w')
f.write(longs) # hangs with 100% CPU, file is 0 bytes
f.close()

SIXGB = 2**32 + 2**31
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in xrange(SIXGB//len(s))])
assert len(longs) == SIXGB
f = open('test.txt', 'w')
f.write(longs) # hangs with 100% CPU, file is 2**31 bytes
f.close()

# file.read test:
TWOGB = 2**31
TWOGBPLUS = TWOGB + 16
s = '0123456789012345' # 16 bytes
longs = ''.join([s for i in xrange(TWOGBPLUS//len(s))])
assert len(longs) == TWOGBPLUS
f = open('test.txt', 'w')
f.write(longs) # completes successfully
f.close()
f = open('test.txt', 'r')
longs = f.read() # works, but takes >30 min, memory usage keeps jumping around
f.close()
del longs
# maybe f.read() reads 1 char at a time til it hits EOL. try this instead:
f = open('test.txt', 'r')
longs = f.read(TWOGBPLUS) # OverflowError: long int too large to convert to int
longs = f.read(TWOGB) # OverflowError: long int too large to convert to int
longs = f.read(TWOGB - 1) # works, takes only seconds
f.close()


So, I guess in windows (I've only tested in 64-bit Windows 7, Python 2.6.6 amd64), file.write() should call fwrite multiple times in chunks no greater than 2**31 bytes or so. Also, calling f.read(nbytes) where nbytes >= 2**31 raises "OverflowError: long int too large to convert to int". I don't have either of these problems in 64-bit Linux (Ubuntu 10.10) on the same machine (i7, 12GB).

----------
components: +IO -Extension Modules
title: array.array.tofile cannot write arrays of sizes > 4GB, even compiled for amd64 -> f.write(s) for s > 2GB hangs in win64 (and win32?)

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

From report at bugs.python.org  Thu Nov  4 09:53:34 2010
From: report at bugs.python.org (Martin Spacek)
Date: Thu, 04 Nov 2010 08:53:34 +0000
Subject: [issue9015] f.write(s) for s > 2GB hangs in win64 (and win32?)
In-Reply-To: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>
Message-ID: <1288860814.87.0.685642131072.issue9015@psf.upfronthosting.co.za>


Martin Spacek <python at mspacek.mm.st> added the comment:

I suppose someone should confirm this problem on Py > 2.6?

----------
components: +Extension Modules, Windows

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

From report at bugs.python.org  Thu Nov  4 10:37:34 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Nov 2010 09:37:34 +0000
Subject: [issue9015] f.write(s) for s > 2GB hangs in win64 (and win32?)
In-Reply-To: <1276730446.48.0.255465495583.issue9015@psf.upfronthosting.co.za>
Message-ID: <1288863454.53.0.711920336227.issue9015@psf.upfronthosting.co.za>


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

It's still an issue with 2.7, and even with 3.2a2, see issue9611.

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

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

From report at bugs.python.org  Thu Nov  4 10:50:58 2010
From: report at bugs.python.org (Martin Spacek)
Date: Thu, 04 Nov 2010 09:50:58 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1288864258.08.0.793442063634.issue9611@psf.upfronthosting.co.za>


Martin Spacek <python at mspacek.mm.st> added the comment:

We've got a near duplicate Issue9015. This thread seems more considered though :) Note that writing more than 2**32-1 bytes at once results in a hung process with 100% CPU in 64-bit Windows, which has to be killed with Task Manager. So I think that qualifies as a crash. This is apparently due to fwrite limitations in msvc, even in win64.

----------
components: +IO
nosy: +mspacek

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

From report at bugs.python.org  Thu Nov  4 11:35:12 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Nov 2010 10:35:12 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1288866912.84.0.452239578271.issue9611@psf.upfronthosting.co.za>


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

Fortunately, the lower-level write() has no such bug, at least when used in binary mode as FileIO does: it's almost a direct call to WriteFile().
This issue is more considered because it's not a bug in the Microsoft CRT, but in the Python implementation of the IO stack.

About the issue, I'd suggest to just clamp the length to 2**32-1, and don't bother retrying; leave this to the buffered layer.

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

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

From report at bugs.python.org  Thu Nov  4 12:27:44 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 11:27:44 +0000
Subject: [issue10308] Modules/getpath.c bugs
In-Reply-To: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za>
Message-ID: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za>


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

Patches for getpath.c in Python 2.7 and 3.2a3:

2.7 chunk#2: copy_absolute() would use uninitialized data if getcwd()
failed.  The fix is equivalent to what 3.2a3 does.

3.2a3 chunk#2: search_for_exec_prefix() did 'unsigned value >= 0' on the
PyUnicode_AsWideChar() result.  (The fix just renames n to k of signed
type, and moves the variables.  An outer uninitialized 'size_t n' is in
scope, so renaming the inner n to k leaves 'n=fread()' still a size_t.)

Chunk #1, both versions: Fix an unlikely 'n+k' wraparound bug while I'm
at it.  The code has just checked that MAXPATHLEN-n will not wrap.

----------
files: getpath.diff
keywords: patch
messages: 120390
nosy: hfuru
priority: normal
severity: normal
status: open
title: Modules/getpath.c bugs
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19486/getpath.diff

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

From report at bugs.python.org  Thu Nov  4 12:43:47 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 11:43:47 +0000
Subject: [issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
In-Reply-To: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>
Message-ID: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>


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

dlmalloc uses mremap() which is undeclared on Linux, needs _GNU_SOURCE.
This can break at least on hosts where void* = 64 bits and int (default
return type) 32 bits, since some bits in the return type are lost.

A minimal patch is:

--- Modules/_ctypes/libffi/src/dlmalloc.c
+++ Modules/_ctypes/libffi/src/dlmalloc.c
@@ -459,2 +459,4 @@
 #define MMAP_CLEARS 0 /* WINCE and some others apparently don't clear */
+#elif !defined _GNU_SOURCE
+#define _GNU_SOURCE 1           /* mremap() in Linux sys/mman.h */
 #endif  /* WIN32 */

However the (char*)CALL_MREMAP() cast looks like a broken fix for this,
it suppresses a warning instead of fixing it.  Maybe you should remove
the cast and instead assign CALL_MREMAP() to a void*, to catch any
similar trouble in the future.

----------
components: Extension Modules
messages: 120391
nosy: hfuru
priority: normal
severity: normal
status: open
title: dlmalloc.c needs _GNU_SOURCE for mremap()
type: behavior
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov  4 12:50:46 2010
From: report at bugs.python.org (Baiju M)
Date: Thu, 04 Nov 2010 11:50:46 +0000
Subject: [issue10297] decimal module documentation is misguiding
In-Reply-To: <1288780221.67.0.597486897879.issue10297@psf.upfronthosting.co.za>
Message-ID: <1288871446.47.0.0541787548509.issue10297@psf.upfronthosting.co.za>


Changes by Baiju M <baiju.m.mail at gmail.com>:


----------
nosy: +baijum

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

From report at bugs.python.org  Thu Nov  4 12:51:20 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 11:51:20 +0000
Subject: [issue10310] signed:1 bitfields rarely make sense
In-Reply-To: <1288871480.25.0.737532033065.issue10310@psf.upfronthosting.co.za>
Message-ID: <1288871480.25.0.737532033065.issue10310@psf.upfronthosting.co.za>


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

In Python 2.7 and 3.2a3, Modules/_io/textio.c uses signed:1 bitfields.

They have value -1 or 0 in two's complement, but are not used thus here:
gcc complains of <bitfield> = 1 overflow.  If the point was that they
are assigned signed values, well, unsigned:1 is promoted to signed int.

I also fix a strange (int) cast doing (truncate flag to int) & 1.
My guess is someone shut up a compiler warning about the above,
by cleaning up in the wrong place.  I kept a cast in case that's
not it, and some compiler would get noisy anyway.

There are possibly-signed 1-bit fields Modules/_ctypes/_ctypes_test.c:
struct BITS too, but I don't know what that code is for.  It does not
specify signedness of the bitfields, which (as with char) makes it the
compiler's choice.  That's usually a bad idea, but maybe that code is
for exploring the compiler?

----------
components: IO
files: signed-1-bitfield.diff
keywords: patch
messages: 120392
nosy: hfuru
priority: normal
severity: normal
status: open
title: signed:1 bitfields rarely make sense
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19487/signed-1-bitfield.diff

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

From report at bugs.python.org  Thu Nov  4 12:53:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Nov 2010 11:53:02 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288871582.51.0.0557967608571.issue10273@psf.upfronthosting.co.za>


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

It should be noted that, if we re-use assertSameElements, the default behavior should be preserved for compatibility with 3.1, and that is different (and possibly less useful) than the one of assertItemsEqual. Ambiguities could be solved easily specifying the args explicitly every time though.

Regarding assertLT I'm still -1. The current names are imho the best compromise between being short and descriptive.
They also match nicely assertEqual (assertLT <-> assertEQ; assertLessThan <-> assertEqualTo; but assertLess <-> assertEqual).
Also it might not be immediately obvious what assertGE does, if one is not familiar with the special methods or if taken out of context (it's easy to recognize it if it's together with assertLT/LE/GT, but alone might just look a specialized method with a bad name).
Moreover people who are used to the current spelling will have to notice the change, note that one name is now deprecated, update their code, remember if the correct name is assertLess or assertLT, wonder if assertEqual has been deprecated in favor of assertEQ too, remember the version where the name changed (e.g. if they try assertLT on 3.1 it won't work) and so on.

----------

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

From report at bugs.python.org  Thu Nov  4 12:54:35 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 11:54:35 +0000
Subject: [issue10310] signed:1 bitfields rarely make sense
In-Reply-To: <1288871480.25.0.737532033065.issue10310@psf.upfronthosting.co.za>
Message-ID: <1288871675.49.0.740127158863.issue10310@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/issue10310>
_______________________________________

From report at bugs.python.org  Thu Nov  4 12:54:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 11:54:41 +0000
Subject: [issue10308] Modules/getpath.c bugs
In-Reply-To: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za>
Message-ID: <1288871681.77.0.848955321393.issue10308@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/issue10308>
_______________________________________

From report at bugs.python.org  Thu Nov  4 12:55:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 11:55:21 +0000
Subject: [issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
In-Reply-To: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>
Message-ID: <1288871721.25.0.634264681743.issue10309@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/issue10309>
_______________________________________

From report at bugs.python.org  Thu Nov  4 12:55:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 11:55:49 +0000
Subject: [issue10133] multiprocessing: conn_recv_string() broken error handling
In-Reply-To: <1287346495.15.0.809946654619.issue10133@psf.upfronthosting.co.za>
Message-ID: <1288871749.32.0.951430280397.issue10133@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/issue10133>
_______________________________________

From report at bugs.python.org  Thu Nov  4 12:56:46 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 11:56:46 +0000
Subject: [issue10086] test_sysconfig failure with site-packages
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1288871806.67.0.523630484836.issue10086@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/issue10086>
_______________________________________

From report at bugs.python.org  Thu Nov  4 12:57:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 11:57:25 +0000
Subject: [issue2921] enable embedding: declare/#define only py* symbols in
	#includes
In-Reply-To: <1211232563.03.0.480695098403.issue2921@psf.upfronthosting.co.za>
Message-ID: <1288871845.83.0.00710305110284.issue2921@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/issue2921>
_______________________________________

From report at bugs.python.org  Thu Nov  4 12:59:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 11:59:28 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1288871968.5.0.975993119991.issue10070@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/issue10070>
_______________________________________

From report at bugs.python.org  Thu Nov  4 12:59:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 11:59:42 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>
Message-ID: <1288871982.25.0.198161709574.issue10231@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/issue10231>
_______________________________________

From report at bugs.python.org  Thu Nov  4 12:59:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 11:59:47 +0000
Subject: [issue960325] "--require <feature>" option for configure/make (fail
	if building not possible)
Message-ID: <1288871987.3.0.0286268511895.issue960325@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/issue960325>
_______________________________________

From report at bugs.python.org  Thu Nov  4 13:04:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 12:04:23 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1288872263.44.0.770002964701.issue9611@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/issue9611>
_______________________________________

From report at bugs.python.org  Thu Nov  4 13:15:31 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Nov 2010 12:15:31 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1288872931.51.0.331511812553.issue9732@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file19483/static.py

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

From report at bugs.python.org  Thu Nov  4 13:15:34 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Nov 2010 12:15:34 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1288872934.44.0.886080485674.issue9732@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file19484/test_static.py

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

From report at bugs.python.org  Thu Nov  4 13:17:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 12:17:10 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1288873030.04.0.369951983014.issue9611@psf.upfronthosting.co.za>


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

> About the issue, I'd suggest to just clamp the length to 2**32-1, and
> don't bother retrying; leave this to the buffered layer.

Yes, I think it's reasonable.
(or perhaps clamp to something page-aligned, such as 2**32-4096).
Also, the signal issue which was raised by Martin above has since been fixed in r84239.

----------

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

From report at bugs.python.org  Thu Nov  4 13:18:18 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 12:18:18 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288873098.65.0.47223283391.issue10311@psf.upfronthosting.co.za>
Message-ID: <1288873098.65.0.47223283391.issue10311@psf.upfronthosting.co.za>


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

Signal handlers that can change errno, must restore it.
I enclose a patch for <2.7, 3.2a3>/Modules/signalmodule.c
which also rearranges the code to make this a bit easier.

The patch does   if (errno != save_errno) errno = save_errno;
instead of just  errno = save_errno;
in case it's less thread-safe to write than to read errno,
which would not surprise me but may be pointless paranoia.

I don't know what needs to be done on non-Unix systems,
like Windows' WSAError stuff.

----------
components: Interpreter Core
files: signalmodule-errno.diff
keywords: patch
messages: 120395
nosy: hfuru
priority: normal
severity: normal
status: open
title: Signal handlers must preserve errno
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19488/signalmodule-errno.diff

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

From report at bugs.python.org  Thu Nov  4 13:20:59 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Nov 2010 12:20:59 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1288873259.43.0.314231981583.issue9732@psf.upfronthosting.co.za>


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

Further updated implementation. Now handles data descriptors correctly but removes the code that resolves the builtin descriptors (calling __get__ on slot and attribute descriptors).

As it was resolving some descriptors but not all, and resolving getset descriptors could still trigger execution in C extensions, Benjamin felt it was more consistent and cleaner to return descriptor objects rather than resolving them. As a bonus it makes the code shorter too.

I would add to the documentation some example code showing how to handle the descriptor if the user wants to resolve them herself. (Example code shown in the tests.)

The only remaining cases that are handled incorrectly are pathological ones. (See the notes in the tests.)

----------
Added file: http://bugs.python.org/file19489/static.py

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

From report at bugs.python.org  Thu Nov  4 13:21:14 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 04 Nov 2010 12:21:14 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1288873274.97.0.437469046864.issue9732@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file19490/test_static.py

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

From report at bugs.python.org  Thu Nov  4 13:24:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 12:24:09 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288873098.65.0.47223283391.issue10311@psf.upfronthosting.co.za>
Message-ID: <1288873449.1.0.190737639261.issue10311@psf.upfronthosting.co.za>


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

This is a good idea IMO. It would be better if you minimized style changes, so that the patch is easier to review.
Also, is the while loop around write() necessary here?

----------
nosy: +exarkun, loewis, pitrou
stage:  -> patch review
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Nov  4 13:36:19 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 04 Nov 2010 12:36:19 +0000
Subject: [issue5391] mmap: read_byte/write_byte and object type
In-Reply-To: <1235818949.96.0.83052759976.issue5391@psf.upfronthosting.co.za>
Message-ID: <1288874179.7.0.706602461831.issue5391@psf.upfronthosting.co.za>


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

Thank for pointing this out. I've looked at bytearray and
bytes implementations, they actually return unsigned value.
I fixed this in r86159(py3k) and r86160(release31-maint).

----------

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

From report at bugs.python.org  Thu Nov  4 13:49:02 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 12:49:02 +0000
Subject: [issue10312] intcatcher() can deadlock
In-Reply-To: <1288874942.68.0.464773855859.issue10312@psf.upfronthosting.co.za>
Message-ID: <1288874942.68.0.464773855859.issue10312@psf.upfronthosting.co.za>


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

Parser/intrcheck.c:intcatcher() can do FILE* operations, which can
deadlock if the interrupt happens while a FILE* operation on the same
FILE holds a mutex for the FILE.  I've seen this happen elsewhere.

It'd rather be a pity to remove Py_Exit(), so I suggest
switch(interrupted++) gets a case 3 or 4: which does _exit(1),
and 'interrupted = 0;' is moved there from case 2.

Also 'interrupted' should be volatile sig_atomic_t, and
the function should save/restore errno as in Issue 10311.

BTW, you could use strlen(message) instead of sizeof(message)-1.

----------
components: Interpreter Core
files: intrcheck.diff
keywords: patch
messages: 120399
nosy: hfuru
priority: normal
severity: normal
status: open
title: intcatcher() can deadlock
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19491/intrcheck.diff

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

From report at bugs.python.org  Thu Nov  4 13:50:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 12:50:10 +0000
Subject: [issue10312] intcatcher() can deadlock
In-Reply-To: <1288874942.68.0.464773855859.issue10312@psf.upfronthosting.co.za>
Message-ID: <1288875010.14.0.996034961636.issue10312@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Nov  4 13:51:51 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 12:51:51 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288873449.1.0.190737639261.issue10311@psf.upfronthosting.co.za>
Message-ID: <hbf.20101104n8qm@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Parser/intrcheck.c:intcatcher() should do the same.  Covered in Issue
10312.

Antoine Pitrou writes:
> This is a good idea IMO. It would be better if you minimized style
> changes, so that the patch is easier to review.

I'm afraid the un-rearranged code would be fairly ugly, so I cleaned
up first.  Single exit point.

> Also, is the while loop around write() necessary here?

Whoops, I'd forgotten I did that too, it was on my TODO list to
check if Python makes it unnecessary by making write restartable.
I don't remember if that's possible to ensure on all modern Posixes

----------

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

From report at bugs.python.org  Thu Nov  4 13:53:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 12:53:09 +0000
Subject: [issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
In-Reply-To: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>
Message-ID: <1288875189.73.0.46558087712.issue10309@psf.upfronthosting.co.za>


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


----------
assignee:  -> theller
nosy: +theller

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

From report at bugs.python.org  Thu Nov  4 13:54:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 12:54:22 +0000
Subject: [issue10310] signed:1 bitfields rarely make sense
In-Reply-To: <1288871480.25.0.737532033065.issue10310@psf.upfronthosting.co.za>
Message-ID: <1288875262.44.0.891717624124.issue10310@psf.upfronthosting.co.za>


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


----------
nosy: +amaury.forgeotdarc
stage:  -> patch review
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Nov  4 14:02:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 13:02:33 +0000
Subject: [issue10306] Weakref callback exceptions should be turned into
	warnings.
In-Reply-To: <1288842596.1.0.996476383192.issue10306@psf.upfronthosting.co.za>
Message-ID: <1288875753.66.0.0405544355497.issue10306@psf.upfronthosting.co.za>


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

The behaviour of weakrefs here mirrors what is already done for __del__ exceptions. Using warnings would mean that exceptions can get silenced implicitly (for example, if an exception happens twice at the same location) which is not very Pythonic: generally, if you want to silence an exception, you have to do it explicitly through try...except.

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

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

From report at bugs.python.org  Thu Nov  4 14:13:39 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 13:13:39 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>
Message-ID: <1288876419.37.0.749379845623.issue10231@psf.upfronthosting.co.za>


Changes by Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:


----------
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Nov  4 14:14:29 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 13:14:29 +0000
Subject: [issue10133] multiprocessing: conn_recv_string() broken error handling
In-Reply-To: <1287346495.15.0.809946654619.issue10133@psf.upfronthosting.co.za>
Message-ID: <1288876469.79.0.835343470216.issue10133@psf.upfronthosting.co.za>


Changes by Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:


----------
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Nov  4 14:14:44 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 13:14:44 +0000
Subject: [issue10308] Modules/getpath.c bugs
In-Reply-To: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za>
Message-ID: <1288876484.93.0.0595335700476.issue10308@psf.upfronthosting.co.za>


Changes by Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:


----------
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Nov  4 14:15:41 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 13:15:41 +0000
Subject: [issue10309] dlmalloc.c needs _GNU_SOURCE for mremap()
In-Reply-To: <1288871027.11.0.979430970782.issue10309@psf.upfronthosting.co.za>
Message-ID: <1288876541.09.0.0779233842382.issue10309@psf.upfronthosting.co.za>


Changes by Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:


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

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

From report at bugs.python.org  Thu Nov  4 14:19:21 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 13:19:21 +0000
Subject: [issue10312] intcatcher() can deadlock
In-Reply-To: <1288874942.68.0.464773855859.issue10312@psf.upfronthosting.co.za>
Message-ID: <1288876761.82.0.0696245115479.issue10312@psf.upfronthosting.co.za>


Changes by Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:


----------
versions: +Python 2.7, Python 3.1

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

From report at bugs.python.org  Thu Nov  4 14:26:59 2010
From: report at bugs.python.org (Julian)
Date: Thu, 04 Nov 2010 13:26:59 +0000
Subject: [issue10306] Weakref callback exceptions should be turned into
	warnings.
In-Reply-To: <1288842596.1.0.996476383192.issue10306@psf.upfronthosting.co.za>
Message-ID: <1288877219.02.0.394472590329.issue10306@psf.upfronthosting.co.za>


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

Thank you, Antoine, you make a good point.

In my example, I am suppressing the warning, which, I agree isn't a good idea.

In my real life usage, I was getting an unexpected exception in a callback in code written by another person. I wanted not to suppress the warning, but to turn it into an exception to help trace the cause.

Thinking about this further, (if it was a warning, as I suggest,) I now believe that would raise that exception into the garbage collector which might have some unpredictable consequences. I have rejected my own Issue for this reason.

I maintain that the current solution isn't terribly helpful. Getting this output to stderr is neither helpful to me, in development (i.e. nothing in the error indicated it was related to the weakref functionality) nor my users in production (fortunately the problem was caught before then!)

However, I concede my proposal isn't the right solution.

Thank you again for your comment.

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

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

From report at bugs.python.org  Thu Nov  4 14:41:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Nov 2010 13:41:25 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288873098.65.0.47223283391.issue10311@psf.upfronthosting.co.za>
Message-ID: <1288878085.55.0.396677454989.issue10311@psf.upfronthosting.co.za>


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

This issue is not really relevant on Windows:
- signals are actually run in a new thread specially created.
- errno is a thread-local variable; its value is thus local to the signal handler, same for WSAGetLastError().

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

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

From report at bugs.python.org  Thu Nov  4 14:44:14 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 04 Nov 2010 13:44:14 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1288878254.89.0.669664523326.issue9931@psf.upfronthosting.co.za>


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

I've created the patch to fix this. (This patch comes from
#9055)

----------
keywords: +patch
Added file: http://bugs.python.org/file19492/py3k_check_if_gui_is_really_available.patch

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

From report at bugs.python.org  Thu Nov  4 14:44:30 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 04 Nov 2010 13:44:30 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1288878270.51.0.00831903394687.issue9931@psf.upfronthosting.co.za>


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


----------
dependencies:  -test_issue_8959_b fails when run from a service

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

From report at bugs.python.org  Thu Nov  4 14:45:04 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 13:45:04 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288878085.55.0.396677454989.issue10311@psf.upfronthosting.co.za>
Message-ID: <hbf.20101104o78j@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Amaury Forgeot d'Arc writes:
> This issue is not really relevant on Windows:
> - signals are actually run in a new thread specially created.
> - errno is a thread-local variable; its value is thus local to the
>   signal handler, same for WSAGetLastError().

Nice.  Then I suggest a config macro for whether this is needed.
Either a test for windows, or an autoconf thing in case some Unixes
are equally sensible.  (Linux isn't, I checked.)

----------

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

From report at bugs.python.org  Thu Nov  4 14:57:16 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Nov 2010 13:57:16 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288873098.65.0.47223283391.issue10311@psf.upfronthosting.co.za>
Message-ID: <1288879036.02.0.07176555682.issue10311@psf.upfronthosting.co.za>


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

> Nice.  Then I suggest a config macro for whether this is needed.
> Either a test for windows, or an autoconf thing in case some Unixes
> are equally sensible.  (Linux isn't, I checked.)

I'm quite sure that all Unixes invoke signal handlers in some existing thread. So even if errno is thread-local, it needs to be saved and restored.
OTOH this is really a micro optimization.

----------

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

From report at bugs.python.org  Thu Nov  4 15:03:17 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 14:03:17 +0000
Subject: [issue10313] Reassure user: test_os BytesWarning is OK
In-Reply-To: <1288879397.21.0.548228653771.issue10313@psf.upfronthosting.co.za>
Message-ID: <1288879397.21.0.548228653771.issue10313@psf.upfronthosting.co.za>


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

A test giving a strange warning can make a poor user nervous.  Here's
a minimal patch to calm his nerves.  It would be better to only give
the message if python -b (not -bb) is active, but I do not know how.

diff -prU2 Lib/test/test_os.py Lib/test/test_os.py
--- Lib/test/test_os.py
+++ Lib/test/test_os.py
@@ -443,4 +443,7 @@ class EnvironTests(mapping_tests.BasicTe
         test_env = {'PATH': os.pathsep.join(test_path)}
 
+        if os.supports_bytes_environ:
+            print("This test may give some 'BytesWarning's.", file=sys.stderr)
+
         saved_environ = os.environ
         try:

----------
components: Tests
messages: 120407
nosy: hfuru
priority: normal
severity: normal
status: open
title: Reassure user: test_os BytesWarning is OK
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Thu Nov  4 15:21:45 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 14:21:45 +0000
Subject: [issue960325] "--require <feature>" option for configure/make (fail
	if building not possible)
Message-ID: <1288880505.63.0.301968960864.issue960325@psf.upfronthosting.co.za>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Once upon a time, Terry J. Reedy wrote:
> Hallvard, do you still consider this a live issue?

If this general behavior remains, yes.

It's been a while since I had a computer without these libraries to
test it on.  (Which is why I punted and then forgot to answer, sorry.)

----------

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

From report at bugs.python.org  Thu Nov  4 15:36:52 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 14:36:52 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288879036.02.0.07176555682.issue10311@psf.upfronthosting.co.za>
Message-ID: <hbf.20101104p4sg@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Amaury Forgeot d'Arc writes:
> OTOH this is really a micro optimization.

["this" = only saving/restoring errno when needed]
True, but practically nothing is officially safe to do in signal
handlers, so it's good to avoid code which can be avoided there.
If one can be bothered to, that is.

----------

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

From report at bugs.python.org  Thu Nov  4 15:38:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Nov 2010 14:38:37 +0000
Subject: [issue10313] Reassure user: test_os BytesWarning is OK
In-Reply-To: <1288879397.21.0.548228653771.issue10313@psf.upfronthosting.co.za>
Message-ID: <1288881517.92.0.178689946987.issue10313@psf.upfronthosting.co.za>


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

I don't see any bytes warnings when I run test_os with -b or -bb on linux on py3k trunk.  (If there were such a warning and it was expected, the fix would be to capture the warning and ignore it.)

Under what circumstances do you see this warning?

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

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

From report at bugs.python.org  Thu Nov  4 15:42:01 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 04 Nov 2010 14:42:01 +0000
Subject: [issue10313] Reassure user: test_os BytesWarning is OK
In-Reply-To: <1288881517.92.0.178689946987.issue10313@psf.upfronthosting.co.za>
Message-ID: <hbf.20101104p851@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

R. David Murray writes:
> I don't see any bytes warnings when I run test_os with -b or -bb on
> linux on py3k trunk.  (If there were such a warning and it was expected,
> the fix would be to capture the warning and ignore it.)
> 
> Under what circumstances do you see this warning?

Python 3.2a3, test_os with python -b.

----------

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

From report at bugs.python.org  Thu Nov  4 15:50:07 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 04 Nov 2010 14:50:07 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1288882207.24.0.171940326754.issue10273@psf.upfronthosting.co.za>


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


----------
nosy: +flox, gregory.p.smith

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

From report at bugs.python.org  Thu Nov  4 15:50:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 14:50:08 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288873098.65.0.47223283391.issue10311@psf.upfronthosting.co.za>
Message-ID: <1288882208.61.0.379860480119.issue10311@psf.upfronthosting.co.za>


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

> ["this" = only saving/restoring errno when needed]
> True, but practically nothing is officially safe to do in signal
> handlers, so it's good to avoid code which can be avoided there.
> If one can be bothered to, that is.

I think it is extremely unlikely that mutating errno in a signal handler is unsafe (after all, the library functions called from that handler can mutate errno too: that's the whole point of the patch IIUC). Adding some configure machinery for this seems unwarranted to me.

----------

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

From report at bugs.python.org  Thu Nov  4 15:55:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 14:55:37 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288873098.65.0.47223283391.issue10311@psf.upfronthosting.co.za>
Message-ID: <1288882537.9.0.304460920785.issue10311@psf.upfronthosting.co.za>


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

By the way, I'd like to clear out a potential misunderstanding: the function you are patching doesn't call Python signal handlers in itself (those registered using signal.signal()). It only schedules them for later execution. If you want to save errno around Python signal handlers themselves, PyErr_CheckSignals must be patched as well.

----------

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

From report at bugs.python.org  Thu Nov  4 16:10:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 15:10:02 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1288883402.85.0.253841988342.issue1602@psf.upfronthosting.co.za>


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

I wrote a small function to call WriteConsoleOutputA() and  WriteConsoleOutputW() in Python to do some tests. It works correclty, except if I change the code page using chcp command. It looks like the problem is that the chcp command changes the console code page and the ANSI code page, but it should only changes the ANSI code page (and not the console code page).


chcp command
============

The chcp command changes the console code page, but in practice, the console still expects the OEM code page (eg. cp850 on my french setup). Example:

C:\...> python.exe -c "import sys; print(sys.stdout.encoding")
cp850
C:\...> chcp 65001
C:\...> python.exe
Fatal Python error: Py_Initialize: can't initialize sys standard streams
LookupError: unknown encoding: cp65001
C:\...> SET PYTHONIOENCODING=utf-8
C:\...> python.exe
>>> import sys
>>> sys.stdout.write("\xe9\n")
??
2
>>> sys.stdout.buffer.write("\xe9\n".encode("utf8"))
??
3
>>> sys.stdout.buffer.write("\xe9\n".encode("cp850"))
?
2

os.device_encoding(1) uses GetConsoleOutputCP() which gives 65001. It should maybe use GetOEMCP() instead? Or chcp command should be fixed?

Set the console code page looks to be a bad idea, because if I type "?" using my keyboard, a random character (eg. U+0002) is displayed instead...


WriteConsoleOutputA() and WriteConsoleOutputW()
===============================================

Without touching the code page
------------------------------

If the character can be rendered by the current font (eg. U+00E9): WriteConsoleOutputA() and WriteConsoleOutputW() work correctly.

If the character cannot be rendered by the current font, but there is a replacment character (eg. U+0141 replaced by U+0041): WriteConsoleOutputA() cannot be used (U+0141 cannot be encoded to the code page), WriteConsoleOutputW() writes U+0141 but the console contains U+0041 (I checked using ReadConsoleOutputW()) and U+0041 is displayed. It works like the mbcs encoding, the behaviour looks correct.

If the character cannot be rendered by the current font, but there is a replacment character (eg. U+042D): WriteConsoleOutputA() cannot be used (U+042D cannot be encoded to the code page), WriteConsoleOutputW() writes U+042D but U+003d (?) is displayed instead. The behaviour looks correct.

chcp 65001
----------

Using "chcp 65001" command (+ "set PYTHONIOENCODING=utf-8" to avoid the fatal error), it becomes worse: the result depends on the font...

Using raster font:
 - (ANSI) write "\xe9".encode("cp850") using WriteConsoleOutputA() displays U+00e9 (?), whereas the console output code page is cp65001 (I checked using GetConsoleOutputCP())
 - (ANSI) write "\xe9".encode("utf-8") using WriteConsoleOutputA() displays ?? (mojibake!)
 - (UNICODE) write "\xe9" using WriteConsoleOutputW() displays... a random character (U+0002, U+0008, U+0069, U+00b0, ...)

Using Lucida (TrueType font): 
 - (ANSI) write "\xe9".encode("cp850") using WriteConsoleOutputA() displays U+0000 !?
 - (UNICODE) write "\xe9" using WriteConsoleOutputW() works correctly (display U+00e9), even with "\u0141", it works correctly (display U+0141)

----------

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

From report at bugs.python.org  Thu Nov  4 16:15:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 04 Nov 2010 15:15:03 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1288883703.21.0.0442184880417.issue1602@psf.upfronthosting.co.za>


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

sys_write_stdtout.patch: Create sys.write_stdout() test function to call WriteConsoleOutputA() or WriteConsoleOutputW() depending on the input types (bytes or str).

----------
keywords: +patch
Added file: http://bugs.python.org/file19493/sys_write_stdout.patch

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

From report at bugs.python.org  Thu Nov  4 16:22:04 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Thu, 04 Nov 2010 15:22:04 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1288884124.37.0.862334248872.issue1602@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx

If you want any kind of Unicode output in the console, the font must be an ?official? MS console TTF (?official? as defined by the Windows version); I believe only Lucida Console and Consolas are the ones with all MS private settings turned on inside the font file.

----------

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

From report at bugs.python.org  Thu Nov  4 16:54:21 2010
From: report at bugs.python.org (Shashank)
Date: Thu, 04 Nov 2010 15:54:21 +0000
Subject: [issue10030] Patch for zip decryption speedup
In-Reply-To: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>
Message-ID: <1288886061.85.0.430850492474.issue10030@psf.upfronthosting.co.za>


Shashank <shashank.sunny.singh at gmail.com> added the comment:

I had uploaded an incorrect patch. New corrected patch against trunk (on Mac OS uploaded).

----------
Added file: http://bugs.python.org/file19494/zipdecrypt.patch

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

From report at bugs.python.org  Thu Nov  4 17:03:29 2010
From: report at bugs.python.org (Shashank)
Date: Thu, 04 Nov 2010 16:03:29 +0000
Subject: [issue10030] Patch for zip decryption speedup
In-Reply-To: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>
Message-ID: <1288886609.9.0.225543964496.issue10030@psf.upfronthosting.co.za>


Changes by Shashank <shashank.sunny.singh at gmail.com>:


Removed file: http://bugs.python.org/file19494/zipdecrypt.patch

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

From report at bugs.python.org  Thu Nov  4 17:04:00 2010
From: report at bugs.python.org (Shashank)
Date: Thu, 04 Nov 2010 16:04:00 +0000
Subject: [issue10030] Patch for zip decryption speedup
In-Reply-To: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>
Message-ID: <1288886640.61.0.265002750287.issue10030@psf.upfronthosting.co.za>


Changes by Shashank <shashank.sunny.singh at gmail.com>:


Added file: http://bugs.python.org/file19495/zipdecrypt.patch

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

From report at bugs.python.org  Thu Nov  4 17:31:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 16:31:38 +0000
Subject: [issue10314] Improve JSON encoding with sort_keys=True
In-Reply-To: <1288888298.44.0.485408020143.issue10314@psf.upfronthosting.co.za>
Message-ID: <1288888298.44.0.485408020143.issue10314@psf.upfronthosting.co.za>


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

This patch makes sorting of keys when encoding a dict into JSON faster by not calling pure Python code.

----------
components: Library (Lib)
files: jsonsort.patch
keywords: patch
messages: 120418
nosy: pitrou
priority: normal
severity: normal
status: open
title: Improve JSON encoding with sort_keys=True
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file19496/jsonsort.patch

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

From report at bugs.python.org  Thu Nov  4 17:50:05 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Nov 2010 16:50:05 +0000
Subject: [issue10314] Improve JSON encoding with sort_keys=True
In-Reply-To: <1288888298.44.0.485408020143.issue10314@psf.upfronthosting.co.za>
Message-ID: <1288889405.49.0.212738430764.issue10314@psf.upfronthosting.co.za>


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

+1

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

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

From report at bugs.python.org  Thu Nov  4 17:51:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 16:51:59 +0000
Subject: [issue10314] Improve JSON encoding with sort_keys=True
In-Reply-To: <1288888298.44.0.485408020143.issue10314@psf.upfronthosting.co.za>
Message-ID: <1288889519.77.0.618836663345.issue10314@psf.upfronthosting.co.za>


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

Ok, committed in r86169.

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

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

From report at bugs.python.org  Thu Nov  4 17:55:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 04 Nov 2010 16:55:06 +0000
Subject: [issue10198] wave module writes corrupt wav file for zero-length
	writeframes
In-Reply-To: <1288107337.09.0.986719080657.issue10198@psf.upfronthosting.co.za>
Message-ID: <1288889706.17.0.0856626539559.issue10198@psf.upfronthosting.co.za>


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

I asked that because I didn?t see the fix backported :)

----------

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

From report at bugs.python.org  Thu Nov  4 18:04:22 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 04 Nov 2010 17:04:22 +0000
Subject: [issue6081] str.format_map()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1288890262.02.0.378549007056.issue6081@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
title: str.format_from_mapping() -> str.format_map()

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

From report at bugs.python.org  Thu Nov  4 18:07:39 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 04 Nov 2010 17:07:39 +0000
Subject: [issue6081] str.format_map()
In-Reply-To: <1242948196.62.0.545811632191.issue6081@psf.upfronthosting.co.za>
Message-ID: <1288890459.68.0.767295608182.issue6081@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Committed to 3.2 in r86170.

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

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

From report at bugs.python.org  Thu Nov  4 18:30:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Nov 2010 17:30:15 +0000
Subject: [issue10313] Reassure user: test_os BytesWarning is OK
In-Reply-To: <1288879397.21.0.548228653771.issue10313@psf.upfronthosting.co.za>
Message-ID: <1288891815.59.0.839843495782.issue10313@psf.upfronthosting.co.za>


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

Can you give the exact command line you are using to run it, and the OS and version, and perhaps a printenv?  I can't reproduce it in 3.1 or 3.2a3.

----------

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

From report at bugs.python.org  Thu Nov  4 18:30:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Nov 2010 17:30:59 +0000
Subject: [issue10313] Reassure user: test_os BytesWarning is OK
In-Reply-To: <1288879397.21.0.548228653771.issue10313@psf.upfronthosting.co.za>
Message-ID: <1288891859.78.0.397702326454.issue10313@psf.upfronthosting.co.za>


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

Running it with -E and seeing if that changes the behavior would also be useful.

----------

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

From report at bugs.python.org  Thu Nov  4 18:35:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 04 Nov 2010 17:35:36 +0000
Subject: [issue10198] wave module writes corrupt wav file for zero-length
	writeframes
In-Reply-To: <1288107337.09.0.986719080657.issue10198@psf.upfronthosting.co.za>
Message-ID: <1288892136.61.0.10098394272.issue10198@psf.upfronthosting.co.za>


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

I always to the backports batched for these minor and docs fixes.

----------

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

From report at bugs.python.org  Thu Nov  4 18:55:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 04 Nov 2010 17:55:09 +0000
Subject: [issue10298] zipfile: incorrect comment size will prevent extracting
In-Reply-To: <1288792839.67.0.901999285278.issue10298@psf.upfronthosting.co.za>
Message-ID: <1288893309.81.0.420109931237.issue10298@psf.upfronthosting.co.za>


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


----------
keywords: +needs review
nosy: +alanmcintyre
stage:  -> patch review
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Thu Nov  4 18:57:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 04 Nov 2010 17:57:13 +0000
Subject: [issue10198] wave module writes corrupt wav file for zero-length
	writeframes
In-Reply-To: <1288107337.09.0.986719080657.issue10198@psf.upfronthosting.co.za>
Message-ID: <1288893433.1.0.0239197527044.issue10198@psf.upfronthosting.co.za>


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

Perfect, sorry for doubting you ;)

----------

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

From report at bugs.python.org  Thu Nov  4 19:39:26 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 04 Nov 2010 18:39:26 +0000
Subject: [issue3699] test_bigaddrspace broken
In-Reply-To: <1219841607.12.0.523528748152.issue3699@psf.upfronthosting.co.za>
Message-ID: <1288895966.13.0.736567868447.issue3699@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

The attached patch implements the same tests of byte for string objects.

----------
assignee:  -> sandro.tosi
stage:  -> patch review
Added file: http://bugs.python.org/file19497/issue3699-py3k-v2.patch

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

From report at bugs.python.org  Thu Nov  4 20:14:05 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Thu, 04 Nov 2010 19:14:05 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288898045.39.0.00197610544328.issue1926@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

Hi Steven,

> I also don't understand why START_TLS and AUTHINFO need to change
> how the module is interfaced to (separating log in/authentication, etc)

Because once you have used AUTHINFO, STARTTLS is no longer a valid command in a session.
The authentication part is currently delt with in the init function (in nntplib) so it needs to be separated because one could want to first use STARTTLS, and then AUTHINFO. Currently, AUTHINFO is sent just after the initial log in; it is therefore better to have AUTHINFO handled in another function.

----------

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

From report at bugs.python.org  Thu Nov  4 20:22:36 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Nov 2010 19:22:36 +0000
Subject: [issue10243] Packaged Pythons
In-Reply-To: <1288421190.78.0.406160800778.issue10243@psf.upfronthosting.co.za>
Message-ID: <1288898556.64.0.629774869036.issue10243@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Nov  4 20:44:35 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Nov 2010 19:44:35 +0000
Subject: [issue960325] "--require <feature>" option for configure/make (fail
	if building not possible)
Message-ID: <1288899875.17.0.241244944921.issue960325@psf.upfronthosting.co.za>


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

I am closing this as some combination of wrong, inapplicable, out-of-date, and postponed.

1. In 3.1, ssl *is* documented as optional in the sense of dependent on an external library. "This module uses the OpenSSL library. It is available on all modern ... platforms, as long as OpenSSL is installed on that platform." For bz2, there is "This module provides a comprehensive interface for the bz2 compression library." If the library is not there, then the module obviously cannot function. Tkinter depends on tcl/tT being installed. I believe some crypto modules also require possibly absent libraries. (The PSF/L?wis Windows installer nicely provides all.) 

If someone wants to review the docs for all such dependencies (and perhaps whatever build docs or help strings or comments there are) and propose doc revision, that could be a separate issue.

2. I think the current default build process is right for most users.

3. Except for the PSF provided binaries, building is ultimately out of our hands. Distributions do what they do. I presume individual persons and organizations can patch the default build files to be stricter if they wish. If they cannot, neither can we ;-).

4. This seems to have become pretty much a non-issue. The OP says he has no further concrete interest because "It's been a while since I had a computer without these libraries...". I am suspecting this is pretty much true for everyone who might otherwise care enough to provide a patch.

----------
resolution:  -> out of date
stage:  -> needs patch
status: open -> closed

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

From report at bugs.python.org  Thu Nov  4 20:51:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Nov 2010 19:51:00 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1288900260.38.0.0942919063995.issue9611@psf.upfronthosting.co.za>


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

I propose a different solution: On Windows, instead of calling write(), we call WriteFile directly. We try to faithfully follow the CRT implementation as much as possible, knowing that what we write to actually is a binary file (in particular, the file handle should get locked). We should perhaps make an exception for the standard handles (0,1,2), and fall back to call the CRT write unless we determine they are also in binary mode.

----------

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

From report at bugs.python.org  Thu Nov  4 21:02:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 20:02:00 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1288900260.38.0.0942919063995.issue9611@psf.upfronthosting.co.za>
Message-ID: <1288900916.3539.75.camel@localhost.localdomain>


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

> I propose a different solution: On Windows, instead of calling
> write(), we call WriteFile directly.

If I'm not mistaken, WriteFile takes the length as a DWORD, which is
still 32 bits under Win64.

----------

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

From report at bugs.python.org  Thu Nov  4 21:14:26 2010
From: report at bugs.python.org (Henning Hraban Ramm)
Date: Thu, 04 Nov 2010 20:14:26 +0000
Subject: [issue10315] smtplib.SMTP_SSL new in 2.6
In-Reply-To: <1288901666.81.0.218057119797.issue10315@psf.upfronthosting.co.za>
Message-ID: <1288901666.81.0.218057119797.issue10315@psf.upfronthosting.co.za>


New submission from Henning Hraban Ramm <hraban at fiee.net>:

The docs tell us that smtplib.SMTP_SSL was only changed in 2.6, but it is new (i.e. it didn't exist in 2.5.x).

----------
assignee: docs at python
components: Documentation
messages: 120432
nosy: docs at python, hraban
priority: normal
severity: normal
status: open
title: smtplib.SMTP_SSL new in 2.6
versions: Python 2.6

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

From report at bugs.python.org  Thu Nov  4 21:17:30 2010
From: report at bugs.python.org (Max Skaller)
Date: Thu, 04 Nov 2010 20:17:30 +0000
Subject: [issue10243] Packaged Pythons
In-Reply-To: <1288851592.49.0.19819499978.issue10243@psf.upfronthosting.co.za>
Message-ID: <AANLkTinKJczZ9fOvbKS9i0qq=KBypkfzXCwY6GtpoiT+@mail.gmail.com>


Max Skaller <max.skaller at gmail.com> added the comment:

On Thu, Nov 4, 2010 at 5:19 PM, Ned Deily <report at bugs.python.org> wrote:

>
> Ned Deily <nad at acm.org> added the comment:
>
> For what it's worth, the python.org installers for Mac OS X do include a
> libpython shared library.  As of Python 2.7 (and 3.2), the installer
> includes a symlink to make it easier to find:
>
> $ cd /Library/Frameworks/Python.framework/Versions/2.7/lib
> $ ls -l libpython2.7.dylib
>

Ok.. so why is it called Python instead of Python.dylib?

/Library/Frameworks/Python.framework>file Python
Python: broken symbolic link to Versions/Current/Python

/Library/Frameworks/Python.framework/Versions/3.1>file Python
Python: Mach-O universal binary with 2 architectures
Python (for architecture ppc):  Mach-O dynamically linked shared library ppc
Python (for architecture i386): Mach-O dynamically linked shared library
i386

Hmm .. i386? Oh dear, I'm running Snow Leopard and I generate 64 bit code.

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

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10243>
_______________________________________
-------------- next part --------------
<br><br><div class="gmail_quote">On Thu, Nov 4, 2010 at 5:19 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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); 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>
For what it&#39;s worth, the <a href="http://python.org" target="_blank">python.org</a> installers for Mac OS X do include a libpython shared library. ??As of Python 2.7 (and 3.2), the installer includes a symlink to make it easier to find:<br>

<br>
$ cd /Library/Frameworks/Python.framework/Versions/2.7/lib<br>
$ ls -l libpython2.7.dylib<br></blockquote></div><br>Ok.. so why is it called Python instead of Python.dylib?<br><br>/Library/Frameworks/Python.framework&gt;file Python<br>Python: broken symbolic link to Versions/Current/Python<br>
<br>/Library/Frameworks/Python.framework/Versions/3.1&gt;file Python<br>Python: Mach-O universal binary with 2 architectures<br>Python (for architecture ppc):?? Mach-O dynamically linked shared library ppc<br>Python (for architecture i386): Mach-O dynamically linked shared library i386<br>
<br>Hmm .. i386? Oh dear, I&#39;m running Snow Leopard and I generate 64 bit code.<br><br>

From report at bugs.python.org  Thu Nov  4 21:22:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Nov 2010 20:22:06 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1288900916.3539.75.camel@localhost.localdomain>
Message-ID: <4CD315EA.5070309@v.loewis.de>


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

> If I'm not mistaken, WriteFile takes the length as a DWORD, which is
> still 32 bits under Win64.

Oops, ignore me, then... I agree that clamping is fine, assuming the
buffering layer takes that into account.

----------

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

From report at bugs.python.org  Thu Nov  4 21:22:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Nov 2010 20:22:59 +0000
Subject: [issue10243] Packaged Pythons
In-Reply-To: <1288421190.78.0.406160800778.issue10243@psf.upfronthosting.co.za>
Message-ID: <1288902179.79.0.0630999739246.issue10243@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Thu Nov  4 21:24:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 20:24:21 +0000
Subject: [issue10293] PyMemoryView object has obsolete members
In-Reply-To: <1288689996.27.0.790374524403.issue10293@psf.upfronthosting.co.za>
Message-ID: <1288902261.99.0.46447964601.issue10293@psf.upfronthosting.co.za>


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

Well, there's this strange-looking thing in PyMemoryView_GetContiguous:

    if (buffertype == PyBUF_SHADOW) {
        /* return a shadowed memory-view object */
        view->buf = dest;
        mem->base = PyTuple_Pack(2, obj, bytes);

... but I don't really want to bother. Let's remove it.

----------

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

From report at bugs.python.org  Thu Nov  4 21:30:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 20:30:53 +0000
Subject: [issue10293] PyMemoryView object has obsolete members
In-Reply-To: <1288689996.27.0.790374524403.issue10293@psf.upfronthosting.co.za>
Message-ID: <1288902653.14.0.1648735792.issue10293@psf.upfronthosting.co.za>


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

Done in r86174.

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

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

From report at bugs.python.org  Thu Nov  4 21:50:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 20:50:41 +0000
Subject: [issue3699] test_bigaddrspace broken
In-Reply-To: <1219841607.12.0.523528748152.issue3699@psf.upfronthosting.co.za>
Message-ID: <1288903841.02.0.74578680965.issue3699@psf.upfronthosting.co.za>


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

I've made cosmetic changes and applied in r86175 (3.2) and r86176 (3.1). Thank you!

----------
priority: high -> normal
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Thu Nov  4 21:56:11 2010
From: report at bugs.python.org (Peter Hall)
Date: Thu, 04 Nov 2010 20:56:11 +0000
Subject: [issue10316] tkFileDialog.askopenfilenames scrambling multiple file
	selection
In-Reply-To: <1288904171.11.0.911089821654.issue10316@psf.upfronthosting.co.za>
Message-ID: <1288904171.11.0.911089821654.issue10316@psf.upfronthosting.co.za>


New submission from Peter Hall <Peter.F.Hall at nasa.gov>:

I am running the following :

Linux Centos version 2.6.18
Python version 2.5
tk version 8.5
tcl version 8.5


I have a Python GUI program (importing Tkinter and tkFileDialog)
which prompts the user to select a (one to many) list of file names. 
The code is :

fileList = tkFileDialog.askopenfilenames(initialdir=self.startfiledir,
                                         title="Select Files for Processing",
                                         filetypes=self.ftypes, multiple=1)

where "startfiledir" and "ftypes" are defined elsewhere.
When this code is run a file selection box pops up
listing the chosen directory. Selecting just one file works fine.

To select multiple files the user highlights a selection
of the displayed files by dragging the cursor over them 
with "SHIFT left-mouse-button" pressed. 
It also lists ALL the selected files in the "File names:" selection field
at the bottom of the selection box. These are separated by spaces.
Clicking "Open" results in the selection box program trying to treat
the entire list as a single file name.
IE. It looks for a single file called "/home/mydir/file1 file2 file3 file4".
Since there is no such file an error pop-up box appears with a 
"File ... does not exist." message.

It appears that the file name list is not being parsed into indivdual file names.
I have tried combinations with "askopenfilename" instead of "askopenfilenames"
and including/omitting "multiple=1". 
I have also tried "multiple=bool(1)" and "multiple=xxx"
where "xxx=1" and "xxx=bool(1)".
None of these change the behaviour.

Is there a fault with my code ?
Is this a bug in "tkFileDialog.askopenfilenames" ?
Is there a workaround ?

Suggestions are welcome.

----------
components: Tkinter
messages: 120438
nosy: pfhall
priority: normal
severity: normal
status: open
title: tkFileDialog.askopenfilenames scrambling multiple file selection
versions: Python 2.5

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

From report at bugs.python.org  Thu Nov  4 21:57:03 2010
From: report at bugs.python.org (Peter Hall)
Date: Thu, 04 Nov 2010 20:57:03 +0000
Subject: [issue10316] tkFileDialog.askopenfilenames scrambling multiple file
	selection
In-Reply-To: <1288904171.11.0.911089821654.issue10316@psf.upfronthosting.co.za>
Message-ID: <1288904223.93.0.0404012776002.issue10316@psf.upfronthosting.co.za>


Changes by Peter Hall <Peter.F.Hall at nasa.gov>:


----------
type:  -> behavior

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

From report at bugs.python.org  Thu Nov  4 21:59:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 20:59:32 +0000
Subject: [issue10313] Reassure user: test_os BytesWarning is OK
In-Reply-To: <1288879397.21.0.548228653771.issue10313@psf.upfronthosting.co.za>
Message-ID: <1288904372.33.0.549260824736.issue10313@psf.upfronthosting.co.za>


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

I guess you're not seeing them because Victor silenced them a couple of days ago in r85902.
Hallvard, if you update your py3k working copy, do these warnings disappear?

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

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

From report at bugs.python.org  Thu Nov  4 22:04:35 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 04 Nov 2010 21:04:35 +0000
Subject: [issue10243] Packaged Pythons
In-Reply-To: <1288421190.78.0.406160800778.issue10243@psf.upfronthosting.co.za>
Message-ID: <1288904675.83.0.327960891463.issue10243@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It's called Python because that's the way frameworks on OS X are generally structured: the shared library file has the same name as the framework.  The Apple developer docs have lots of information on frameworks.

Prior to 2.7 and the upcoming 3.2 releases, python.org installers (including for 3.1) have been 32-bit only.  Starting with 2.7 and the latest 3.2 alpha, there are two OS X installer downloads for each release, one 32-bit only (10.3 and later) and the other 32-bit/64-bit for use on 10.6.  Also the Apple-supplied Python 2.6 in 10.6 is 32-bit/64-bit.  Otherwise, if you need 64-bit for earlier releases, you will need to look elsewhere.  For example, some of the third-party open source distributors for OS X like MacPorts support 64-bit builds of Python 2.6 and 3.1. Or you will need to build from scratch.

----------

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

From report at bugs.python.org  Thu Nov  4 22:08:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 21:08:01 +0000
Subject: [issue10302] Add class-functions to hash many small objects with
	hashlib
In-Reply-To: <1288824257.88.0.548360154902.issue10302@psf.upfronthosting.co.za>
Message-ID: <1288904881.66.0.850369392521.issue10302@psf.upfronthosting.co.za>


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

This sounds dangerously like a micro-optimization to me, and I'm not sure an additional API is ok for that.

----------
nosy: +gregory.p.smith, pitrou

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

From report at bugs.python.org  Thu Nov  4 22:11:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 04 Nov 2010 21:11:41 +0000
Subject: [issue10313] Reassure user: test_os BytesWarning is OK
In-Reply-To: <1288879397.21.0.548228653771.issue10313@psf.upfronthosting.co.za>
Message-ID: <1288905101.59.0.820152196604.issue10313@psf.upfronthosting.co.za>


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

Ah, then this report is probably out of date.  I just realized that I ran my 3.2a3 test incorrectly, so my report that I didn't see them there is invalid.

----------

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

From report at bugs.python.org  Thu Nov  4 22:19:09 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Nov 2010 21:19:09 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1288905549.43.0.888749248457.issue9611@psf.upfronthosting.co.za>


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

On a second thought... is there another example where a *blocking* stream does not write all the data without raising an exception?

----------

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

From report at bugs.python.org  Thu Nov  4 22:24:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Nov 2010 21:24:12 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1288905549.43.0.888749248457.issue9611@psf.upfronthosting.co.za>
Message-ID: <4CD32478.2050903@v.loewis.de>


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

> On a second thought... is there another example where a *blocking* stream does not write all the data without raising an exception?

Why do you think this would be somehow an example for a blocking stream
that does not write all data without raising an exception?

----------

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

From report at bugs.python.org  Thu Nov  4 22:28:39 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 04 Nov 2010 21:28:39 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1281893142.91.0.972520708976.issue9611@psf.upfronthosting.co.za>
Message-ID: <1288906119.67.0.611612929514.issue9611@psf.upfronthosting.co.za>


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

> Why do you think this would be somehow an example for a blocking stream
> that does not write all data without raising an exception?
Well, that's what "clamping" means, isn't it?

----------

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

From report at bugs.python.org  Thu Nov  4 22:31:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 21:31:23 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1288905549.43.0.888749248457.issue9611@psf.upfronthosting.co.za>
Message-ID: <1288906279.3539.77.camel@localhost.localdomain>


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

> On a second thought... is there another example where a *blocking*
> stream does not write all the data without raising an exception?

It can happen with pipes or sockets, if some buffer can only store part
of the data. Or any regular stream if a signal is received after part of
the data has been written.

----------

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

From report at bugs.python.org  Thu Nov  4 22:36:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 21:36:51 +0000
Subject: [issue10283] New parameter for an NNTP newsgroup pattern in LIST
	ACTIVE
In-Reply-To: <1288642864.21.0.311033761057.issue10283@psf.upfronthosting.co.za>
Message-ID: <1288906611.09.0.900898821384.issue10283@psf.upfronthosting.co.za>


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

That's a fine addition, I've committed it in r86177.

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

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

From report at bugs.python.org  Thu Nov  4 22:37:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 04 Nov 2010 21:37:34 +0000
Subject: [issue9611] FileIO not 64-bit safe under Windows
In-Reply-To: <1288906119.67.0.611612929514.issue9611@psf.upfronthosting.co.za>
Message-ID: <4CD3279B.7020102@v.loewis.de>


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

Am 04.11.2010 22:28, schrieb Amaury Forgeot d'Arc:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
>> Why do you think this would be somehow an example for a blocking stream
>> that does not write all data without raising an exception?
> Well, that's what "clamping" means, isn't it?

Ah, then I misunderstood. We certainly should discard any data.
I understood the proposal as rejecting write attempts for larger blocks
with an exception.

----------

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

From report at bugs.python.org  Thu Nov  4 22:40:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 21:40:17 +0000
Subject: [issue10279] test_gc failure on Windows x64
In-Reply-To: <1288629245.88.0.812868116264.issue10279@psf.upfronthosting.co.za>
Message-ID: <1288906817.55.0.170989597137.issue10279@psf.upfronthosting.co.za>


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

%Id is actually the expansion of PY_FORMAT_SIZE_T.

Include/pyport.h says:

/* PY_FORMAT_SIZE_T is a platform-specific modifier for use in a printf
 * format to convert an argument with the width of a size_t or Py_ssize_t.
 * C99 introduced "z" for this purpose, but not all platforms support that;
 * e.g., MS compilers use "I" instead.

Perhaps this is outdated or simply wrong?

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

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

From report at bugs.python.org  Thu Nov  4 22:40:24 2010
From: report at bugs.python.org (Lukas Lueg)
Date: Thu, 04 Nov 2010 21:40:24 +0000
Subject: [issue10302] Add class-functions to hash many small objects with
	hashlib
In-Reply-To: <1288824257.88.0.548360154902.issue10302@psf.upfronthosting.co.za>
Message-ID: <1288906824.67.0.475740527709.issue10302@psf.upfronthosting.co.za>


Lukas Lueg <lukas.lueg at gmail.com> added the comment:

Thanks for your comment; it is a very valid point to consider. However, as a vector-based implementation is roughly three to four times faster  than what the current API can provide by design (reduced overhead and GIL-relaxation not included), I may disagree with it.

I'm willing to make a proposal (read: patch) if you and the other overlords have enough confidence in this API-change and it has a chance to get submitted.

----------

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

From report at bugs.python.org  Thu Nov  4 22:41:25 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 04 Nov 2010 21:41:25 +0000
Subject: [issue9675] segfault: PyDict_SetItem: Assertion `value' failed.
In-Reply-To: <1282683108.48.0.667769171779.issue9675@psf.upfronthosting.co.za>
Message-ID: <1288906885.89.0.427088793324.issue9675@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Move the CObject use to a py3k warning instead of an error in r86178.

I still need to solve improve error management in bsddb. This bug remains open for a while.

----------

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

From report at bugs.python.org  Thu Nov  4 22:43:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 21:43:11 +0000
Subject: [issue10279] test_gc failure on Windows x64
In-Reply-To: <1288629245.88.0.812868116264.issue10279@psf.upfronthosting.co.za>
Message-ID: <1288906991.84.0.640756472874.issue10279@psf.upfronthosting.co.za>


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

Well, the issue seems to be simpler. This piece of code calls PyErr_WarnFormat, which doesn't use the platform's printf but Python's own format codes as documented in http://docs.python.org/dev/c-api/unicode.html#PyUnicode_FromFormat

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Thu Nov  4 22:46:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 21:46:30 +0000
Subject: [issue10279] test_gc failure on Windows x64
In-Reply-To: <1288629245.88.0.812868116264.issue10279@psf.upfronthosting.co.za>
Message-ID: <1288907190.82.0.994370475969.issue10279@psf.upfronthosting.co.za>


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

Could you check the following patch works for you?

----------
assignee:  -> brian.curtin
keywords: +patch
Added file: http://bugs.python.org/file19499/gcprint.patch

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

From report at bugs.python.org  Thu Nov  4 22:50:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 04 Nov 2010 21:50:21 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288907421.55.0.72053422709.issue7061@psf.upfronthosting.co.za>


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

I am attaching a patch that adds a hack that allows to run turtle doctests using turtle.run_doctests() function.  Running this function has revealed numerous mistakes in doctests that are corrected in the patch.

The patch is against release27 branch because there are even more problems in py3k.

I don't think run_doctests hack belongs to turtle module.  I think it would be more appropriate to place it in test.test_turtle.

I have also not been able to figure out how to make global functions' doctests runnable.  The current patch disables them by mangling the >>> prompts in docstrings.

----------
Added file: http://bugs.python.org/file19500/issue7061-docstrings-r27.diff

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

From report at bugs.python.org  Thu Nov  4 22:55:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 04 Nov 2010 21:55:30 +0000
Subject: [issue10302] Add class-functions to hash many small objects with
	hashlib
In-Reply-To: <1288906824.67.0.475740527709.issue10302@psf.upfronthosting.co.za>
Message-ID: <1288907723.3539.86.camel@localhost.localdomain>


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

> Thanks for your comment; it is a very valid point to consider.
> However, as a vector-based implementation is roughly three to four
> times faster  than what the current API can provide by design (reduced
> overhead and GIL-relaxation not included), I may disagree with it.

I fear that this kind of optimization is a moving target. If some CPU
architecture gains hardware support for cryptographic hashes, OpenSSL
will support it and be much faster than Python's parallel version.

> I'm willing to make a proposal (read: patch) if you and the other
> overlords have enough confidence in this API-change and it has a
> chance to get submitted.

If the only advantage is some speedup on parallel hashing of
many-small-strings, I don't think a new API is warranted for such a
specialized use case.

----------

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

From report at bugs.python.org  Thu Nov  4 23:11:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 04 Nov 2010 22:11:26 +0000
Subject: [issue6305] islice doesn't accept large stop values
In-Reply-To: <1245309263.43.0.625809679675.issue6305@psf.upfronthosting.co.za>
Message-ID: <1288908686.97.0.309708580429.issue6305@psf.upfronthosting.co.za>


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

In 3.1.2, range handles large numbers.
>>> list(range(1000000000, 50000000000, 10000000000))
[1000000000, 11000000000, 21000000000, 31000000000, 41000000000]
# those are all billions

This means that the 'equivalent' code in the doc will work.

----------
nosy: +terry.reedy

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

From report at bugs.python.org  Thu Nov  4 23:20:17 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 04 Nov 2010 22:20:17 +0000
Subject: [issue10302] Add class-functions to hash many small objects with
	hashlib
In-Reply-To: <1288824257.88.0.548360154902.issue10302@psf.upfronthosting.co.za>
Message-ID: <1288909217.09.0.391839774924.issue10302@psf.upfronthosting.co.za>


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

I concur with Overlord Antoine ;-)

The API of "hashfunc *files" looks like something that should be done at the command line in bash.   For the most part, I think users are better-off using normal Python loops so they can do something with the computed hashes as the files are read.

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

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

From report at bugs.python.org  Fri Nov  5 00:01:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 04 Nov 2010 23:01:08 +0000
Subject: [issue10279] test_gc failure on Windows x64
In-Reply-To: <1288629245.88.0.812868116264.issue10279@psf.upfronthosting.co.za>
Message-ID: <1288911668.23.0.734160499102.issue10279@psf.upfronthosting.co.za>


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

Works for me.

----------
assignee: brian.curtin -> pitrou

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

From report at bugs.python.org  Fri Nov  5 00:51:56 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 04 Nov 2010 23:51:56 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1288914716.92.0.28985883195.issue5412@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


Removed file: http://bugs.python.org/file19010/issue5412.diff

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

From report at bugs.python.org  Fri Nov  5 00:54:17 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 04 Nov 2010 23:54:17 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1288914857.66.0.112204692113.issue5412@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Patch updated yet again:

 * optional .get() arguments are now keyword only. This is a bit
   backwards incompatible but:

   * protects users of mapping protocol access from invoking get() as if
     the last positional argument was the `fallback` value (it would be
     `raw` for (Safe)ConfigParsers and `vars` for RawConfigParsers)

   * so it will improve API compatibility between Raw and others

   * it will make the client code more readable, e.g.:

      anyParser.get('section', 'value', fallback=True)

      vs.

      rawParser.get('section', 'value', {}, True)
      safeParser.get('section', 'value', 0, {}, True)
      parserUsedWrong('section', 'value', True) # NOT a fallback! 

 * mapping protocol access is now quite thoroughly documented

 * renamed `default` arguments to get() to `fallback`. This is *not*
   backwards incompatible because those arguments were just recently
   added by me. I chose to rename them since because of DEFAULTSECT
   there already is a well-defined "default value" concept. Now the
   situation is much clearer, e.g. the docs can simply state: "default
   values have precedence over fallback values." and this is
   unambiguous.

As for some suggestions to just provide the section dictionaries
directly, this won't work because of interpolation and the terrific
DEFAULT section special case, e.g.  if a config file contains a DEFAULT
section and other sections lack a value, it will be returned instead on
get(). Also, DEFAULT values are used in interpolations. On top of that,
the provided section proxies ensure while setting that the database
holds only strings (which it should by design).

There is still one paragraph to be finished (Customizing Parser
Behaviour). This has to wait for tomorrow.

----------
Added file: http://bugs.python.org/file19501/issue5412.diff

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

From report at bugs.python.org  Fri Nov  5 01:05:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 00:05:54 +0000
Subject: [issue10279] test_gc failure on Windows x64
In-Reply-To: <1288629245.88.0.812868116264.issue10279@psf.upfronthosting.co.za>
Message-ID: <1288915554.25.0.481068214588.issue10279@psf.upfronthosting.co.za>


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

Committed in r86179.

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

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

From report at bugs.python.org  Fri Nov  5 01:14:54 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Nov 2010 00:14:54 +0000
Subject: [issue10316] tkFileDialog.askopenfilenames scrambling multiple file
	selection
In-Reply-To: <1288904171.11.0.911089821654.issue10316@psf.upfronthosting.co.za>
Message-ID: <1288916094.5.0.815612752953.issue10316@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Works for me on a current Debian Linux system with a Debian Python 2.5.5 + Tcl/Tk 8.5 and with Python 2.6.1 + Tcl/Tk 8.5 on OS X 10.6 and with Python 2.7 + Tcl/Tk 8.4 on OS X 10.6. In all cases, the tkFileDialog.askopenfilenames returns a tuple of absolute file paths.  (BTW, only security issues are accepted for Python 2.5 at this time).

----------
nosy: +ned.deily
resolution:  -> works for me
status: open -> closed

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

From report at bugs.python.org  Fri Nov  5 01:16:06 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 05 Nov 2010 00:16:06 +0000
Subject: [issue9675] segfault: PyDict_SetItem: Assertion `value' failed.
In-Reply-To: <1282683108.48.0.667769171779.issue9675@psf.upfronthosting.co.za>
Message-ID: <1288916166.59.0.557225304287.issue9675@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Better bsddb error control. Please, review.

"""
[jcea at babylon5 release27-maint]$ ./python
Python 2.7.0+ (release27-maint:86176:86178M, Nov  5 2010, 00:30:) 
[GCC 4.5.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
>>> exit()
"""

"""
[jcea at babylon5 release27-maint]$ ./python -3
Python 2.7.0+ (release27-maint:86176:86178M, Nov  5 2010, 00:30:) 
[GCC 4.5.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import bsddb
__main__:1: DeprecationWarning: in 3.x, the bsddb module has been removed; please use the pybsddb project instead
/home/python/svn-hg/release27-maint/Lib/bsddb/__init__.py:67: DeprecationWarning: CObject type is not supported in 3.x. Please use capsule objects instead.
  import _bsddb
"""

"""
[jcea at babylon5 release27-maint]$ ./python -3 -Werror
Python 2.7.0+ (release27-maint:86176:86178M, Nov  5 2010, 00:30:)
[GCC 4.5.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import warnings
>>> warnings.filterwarnings('ignore',
... "in 3.x, the bsddb module has been removed; please use the pybsddb project instead",
... category=DeprecationWarning)
>>> import bsddb
Exception DeprecationWarning: DeprecationWarning('CObject type is not supported in 3.x. Please use capsule objects instead.',) in <module '_bsddb' (built-in)> ignored
>>> exit()
"""

Why is my "PyErr_Warn()" not being printed?

The code: (py_api is the CObject, will be NULL if an exception happened)

"""
    if (py_api) {
        PyDict_SetItemString(d, "api", py_api);
        Py_DECREF(py_api);
    } else { /* Something bad happened */
        PyErr_WriteUnraisable(m);
        PyErr_Warn(PyExc_RuntimeWarning,
                "_bsddb/_pybsddb C API will be not available");
        PyErr_Clear();
    }
"""

Commit r86180.

Now I have to up-port this patch to the upcoming pybssddb 5.1.1.

----------

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

From report at bugs.python.org  Fri Nov  5 01:27:17 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 05 Nov 2010 00:27:17 +0000
Subject: [issue9675] segfault: PyDict_SetItem: Assertion `value' failed.
In-Reply-To: <1282683108.48.0.667769171779.issue9675@psf.upfronthosting.co.za>
Message-ID: <1288916837.63.0.973391479441.issue9675@psf.upfronthosting.co.za>


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


----------
assignee:  -> jcea
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Fri Nov  5 02:05:07 2010
From: report at bugs.python.org (StevenJ)
Date: Fri, 05 Nov 2010 01:05:07 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288919107.48.0.763346414905.issue1926@psf.upfronthosting.co.za>


StevenJ <sjohnson at sakuraindustries.com> added the comment:

Hi Julien,

>> I also don't understand why START_TLS and AUTHINFO need to change
>> how the module is interfaced to (separating log in/authentication, etc)

> Because once you have used AUTHINFO, STARTTLS is no longer a valid
> command in a session.

I understand this, but doesn't this mean the init function needs to change to something like:

init:
  if capability STARTTLS is advertised 
    STARTLS stuff
    reget capabilities because STARTTLS changed them probably

  Now handle AUTHINFO Stuff

Is there a case where a server advertises STARTTLS and one would not use it?  If so then couldn't that just be handled with an option to the class inhibiting it?

This is one of the reasons why I proposed dividing the job across two features. 
1. Simple NNTPS which seems to be the most common secured NNTP in use at the moment and is easy to implement, and verify (either as an improvement to the NNTP class or as a new NNTP_SSL class). 
2. SASL AUTHINFO/STARTTLS Extension handling implementation and improvements.  

There are also other bugs with properly handling capabilities at start related to this, are there not? http://bugs.python.org/issue10287

----------

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

From report at bugs.python.org  Fri Nov  5 02:06:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 05 Nov 2010 01:06:09 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288919169.05.0.446388431157.issue1926@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/issue1926>
_______________________________________

From report at bugs.python.org  Fri Nov  5 03:08:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Nov 2010 02:08:21 +0000
Subject: [issue1702036] Make Turtle thread-safe so it does not crash
Message-ID: <1288922901.78.0.252655095143.issue1702036@psf.upfronthosting.co.za>


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

I think threading is a red herring here.  The issue is really a duplicate of #6639.

----------
nosy: +belopolsky
status: open -> pending
superseder:  -> turtle: _tkinter.TclError: invalid command name ".10170160"

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

From report at bugs.python.org  Fri Nov  5 03:19:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Nov 2010 02:19:40 +0000
Subject: [issue1702036] Make Turtle thread-safe so it does not crash
Message-ID: <1288923580.72.0.970145070096.issue1702036@psf.upfronthosting.co.za>


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

On a closer look at the first post, I see that there are two parts to the issue.  The first is indeed a duplicate of #6639, but the second is thread related.   I am attaching the OP's code in a script file for convenience.  Running ninja.py under python3 produces 

RuntimeError: main thread is not in main loop

in every ninja thread.  This looks like tkinter limitation, but I think it is possible to work around it in turtle, so this is a valid feature request.

+1

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

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

From report at bugs.python.org  Fri Nov  5 03:40:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Nov 2010 02:40:56 +0000
Subject: [issue10317] Add TurtleShell to turtle
In-Reply-To: <1288924856.05.0.699658333719.issue10317@psf.upfronthosting.co.za>
Message-ID: <1288924856.05.0.699658333719.issue10317@psf.upfronthosting.co.za>


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

In r84640, Raymond added TurtleShell to the cmd module documentation as an example of a simple interpreter that can be written using that module.  I propose adding this code to turtle.py and make it runnable as python -m turtle.

----------
components: Library (Lib)
keywords: easy
messages: 120466
nosy: belopolsky, rhettinger
priority: normal
severity: normal
stage: needs patch
status: open
title: Add TurtleShell to turtle
type: feature request
versions: Python 3.2

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

From report at bugs.python.org  Fri Nov  5 03:52:29 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 05 Nov 2010 02:52:29 +0000
Subject: [issue10293] PyMemoryView object has obsolete members
In-Reply-To: <1288689996.27.0.790374524403.issue10293@psf.upfronthosting.co.za>
Message-ID: <1288925549.22.0.502387785964.issue10293@psf.upfronthosting.co.za>


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

Ah, the SHADOW member...
Weird.
Anyway, I have been hacking around in the memory view.  One thing that it does, and makes me uncomfortable since I think it is breaking the new buffer protocol, is to 
a) PyObject_GetBuffer()
b) Modify the resulting local Py_buffer
c) releaseing that modified Py_buffer when it calls PyBuffer_Release()

I don't think one can do that, strictly speaking.  You don't know what the buffer_releasebuffer() slot actually does, it might use the Py_buffer's "buf" member to release internal data, so I don't think it is permissable to mess with it.

I was hacking away at the MemoryView to make it behave differently, perhaps more like the SHADOW buffer concept:  When you call buffer_getbuffer on a memoryview, it returns a new Py_buffer that reflects its own view of the underlying object.  In other words, it doesn't call PyObject_GetBuffer again on the underlying object  A memoryview object should, IMHO, only perform that call once on the underlying object, and then serve its own view to its clients.

Slicing memoryview objects should also be done differently.  Rather than calling PyObject_GetBuffer() on the underlying object, it should rather refer to the origina MemoryView object, and create a local modification of that view.

The only problem with this approact that I have found (having run the testsuite) is that the buffer_getbuffer slot now has to do more work, since it cannot simply call PyObject_GetBuffer() on some underlying object.  It must now interpret flags and other things....

----------

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

From report at bugs.python.org  Fri Nov  5 04:10:10 2010
From: report at bugs.python.org (Allan McRae)
Date: Fri, 05 Nov 2010 03:10:10 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>


New submission from Allan McRae <allan at archlinux.org>:

The following files are incorrectly installed with a "#!/usr/bin/env python" shebang when using "make altinstall":

usr/lib/python2.7/base64.py
usr/lib/python2.7/bsddb/dbshelve.py
usr/lib/python2.7/bsddb/test/test_dbtables.py
usr/lib/python2.7/cgi.py
usr/lib/python2.7/cgi.py
usr/lib/python2.7/Cookie.py
usr/lib/python2.7/cProfile.py
usr/lib/python2.7/difflib.py
usr/lib/python2.7/distutils/tests/test_build_scripts.py
usr/lib/python2.7/distutils/tests/test_install_scripts.py
usr/lib/python2.7/distutils/unixccompiler.py
usr/lib/python2.7/encodings/rot_13.py
usr/lib/python2.7/idlelib/PyShell.py
usr/lib/python2.7/keyword.py
usr/lib/python2.7/lib2to3/pgen2/token.py
usr/lib/python2.7/lib2to3/tests/data/different_encoding.py
usr/lib/python2.7/lib2to3/tests/pytree_idempotency.py
usr/lib/python2.7/mailbox.py
usr/lib/python2.7/mimify.py
usr/lib/python2.7/pdb.py
usr/lib/python2.7/platform.py
usr/lib/python2.7/profile.py
usr/lib/python2.7/pydoc.py
usr/lib/python2.7/quopri.py
usr/lib/python2.7/smtpd.py
usr/lib/python2.7/smtplib.py
usr/lib/python2.7/symbol.py
usr/lib/python2.7/tabnanny.py
usr/lib/python2.7/tarfile.py
usr/lib/python2.7/test/curses_tests.py
usr/lib/python2.7/test/pystone.py
usr/lib/python2.7/test/regrtest.py
usr/lib/python2.7/test/re_tests.py
usr/lib/python2.7/test/test_al.py
usr/lib/python2.7/test/test_anydbm.py
usr/lib/python2.7/test/test_array.py
usr/lib/python2.7/test/test_binhex.py
usr/lib/python2.7/test/test_bsddb.py
usr/lib/python2.7/test/test_bz2.py
usr/lib/python2.7/test/test_cd.py
usr/lib/python2.7/test/test_cl.py
usr/lib/python2.7/test/test_cmd.py
usr/lib/python2.7/test/test_codecencodings_cn.py
usr/lib/python2.7/test/test_codecencodings_hk.py
usr/lib/python2.7/test/test_codecencodings_jp.py
usr/lib/python2.7/test/test_codecencodings_kr.py
usr/lib/python2.7/test/test_codecencodings_tw.py
usr/lib/python2.7/test/test_codecmaps_cn.py
usr/lib/python2.7/test/test_codecmaps_hk.py
usr/lib/python2.7/test/test_codecmaps_jp.py
usr/lib/python2.7/test/test_codecmaps_kr.py
usr/lib/python2.7/test/test_codecmaps_tw.py
usr/lib/python2.7/test/test_dl.py
usr/lib/python2.7/test/test_dumbdbm.py
usr/lib/python2.7/test/test_eof.py
usr/lib/python2.7/test/test_errno.py
usr/lib/python2.7/test/test___future__.py
usr/lib/python2.7/test/test_gl.py
usr/lib/python2.7/test/test_gzip.py
usr/lib/python2.7/test/test_imageop.py
usr/lib/python2.7/test/test_imgfile.py
usr/lib/python2.7/test/test_logging.py
usr/lib/python2.7/test/test_marshal.py
usr/lib/python2.7/test/test_multibytecodec.py
usr/lib/python2.7/test/test_multibytecodec_support.py
usr/lib/python2.7/test/test_multiprocessing.py
usr/lib/python2.7/test/test_popen2.py
usr/lib/python2.7/test/test_popen.py
usr/lib/python2.7/test/test_random.py
usr/lib/python2.7/test/test_sets.py
usr/lib/python2.7/test/test_smtpnet.py
usr/lib/python2.7/test/test_socket.py
usr/lib/python2.7/test/test_tcl.py
usr/lib/python2.7/test/test_urllib2_localnet.py
usr/lib/python2.7/test/test_urllib2net.py
usr/lib/python2.7/test/test_urllibnet.py
usr/lib/python2.7/test/test_urlparse.py
usr/lib/python2.7/test/test_userstring.py
usr/lib/python2.7/test/test_whichdb.py
usr/lib/python2.7/test/test_with.py
usr/lib/python2.7/timeit.py
usr/lib/python2.7/token.py
usr/lib/python2.7/trace.py
usr/lib/python2.7/UserString.py
usr/lib/python2.7/uu.py
usr/lib/python2.7/webbrowser.py
usr/lib/python2.7/whichdb.py

These should point to /usr/bin/python2.7 instead.

----------
components: Build
messages: 120468
nosy: allan
priority: normal
severity: normal
status: open
title: "make altinstall" installs many files with incorrect shebangs
versions: Python 2.7

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

From report at bugs.python.org  Fri Nov  5 06:38:40 2010
From: report at bugs.python.org (jrodman2)
Date: Fri, 05 Nov 2010 05:38:40 +0000
Subject: [issue10319] SocketServer.TCPServer truncates responses on close (in
	some situations)
In-Reply-To: <1288935519.72.0.951711716225.issue10319@psf.upfronthosting.co.za>
Message-ID: <1288935519.72.0.951711716225.issue10319@psf.upfronthosting.co.za>


New submission from jrodman2 <jrodman at pythontracker.spamportal.net>:

Behavior exists in at least Python 2.5 through 3.1.

The issue regards the socketserver's handling of the tcp sockets it works with.  On object reaping, the sockets are properly closed (in some versions explicitly, in others implicitly).  However, closing a socket with unread data will in some operating systems prevent sent data from being sent.  Notably this occurs on Linux and Windows (I tested on Debian testing x86_64 and Windows Vista x86).

Extensive tcpdump sessions and a lot of head scratching finally clarified the issue.  The OS would send an RST packet after just the first bit of data handed over to the socket implementation, in typical cases meaning hte first line of text python is writing would be sent to the client, but no more, causing invalid HTTP replies.

Here is a change to force the socket to be drained on close.  It is of no matter that more data may arrive on the socket post-drain, because the socket implementation in the operating system should be happy to send off what was already queued by the python program at this point.

Testing bears this out, across many platforms here.

Here is one way to accomplish this in python 2.x, in 3.x the equivalent file is socketserver.py, but has the same issue.  It lacks the explicit request.close() call, bgut this seems a matter of aesthetics.

Note that the use of select.select() is documented by Linux to be unsafe for this purpose in some circumstances, and may be on other platforms as well.

I sort of would rather have sockets have a socket.drain() function which is known to be safe and correct for this type of socket programming issue.  If that would be more appropriate, please suggest.

select(2)
       Under  Linux, select() may report a socket file descriptor as "ready for reading", while nevertheless a subsequent
       read blocks.  This could for example happen when data has arrived but upon examination has wrong checksum  and  is
       discarded.   There may be other circumstances in which a file descriptor is spuriously reported as ready.  Thus it
       may be safer to use O_NONBLOCK on sockets that should not block.

--- SocketServer.py.orig	2010-11-04 21:36:23.000000000 -0700
+++ SocketServer.py	2010-11-04 21:38:19.000000000 -0700
@@ -445,6 +445,13 @@
 
     def close_request(self, request):
         """Called to clean up an individual request."""
+        # drain socket
+        request.setblocking(0)
+        try:
+            while True:
+                request.recv(4096)
+        except socket.error, e:
+            pass
         request.close()

----------
messages: 120469
nosy: jrodman2
priority: normal
severity: normal
status: open
title: SocketServer.TCPServer truncates responses on close (in some situations)
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Fri Nov  5 08:34:12 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 05 Nov 2010 07:34:12 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288942452.88.0.931355211696.issue7061@psf.upfronthosting.co.za>


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

Why shouldn't global function doctests be runnable?

----------

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

From report at bugs.python.org  Fri Nov  5 08:38:04 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 05 Nov 2010 07:38:04 +0000
Subject: [issue10315] smtplib.SMTP_SSL new in 2.6
In-Reply-To: <1288901666.81.0.218057119797.issue10315@psf.upfronthosting.co.za>
Message-ID: <1288942684.23.0.689903188027.issue10315@psf.upfronthosting.co.za>


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

Thanks, fixed in r86189.

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

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

From report at bugs.python.org  Fri Nov  5 08:48:39 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 05 Nov 2010 07:48:39 +0000
Subject: [issue10317] Add TurtleShell to turtle
In-Reply-To: <1288924856.05.0.699658333719.issue10317@psf.upfronthosting.co.za>
Message-ID: <1288943319.42.0.916428323694.issue10317@psf.upfronthosting.co.za>


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

It's better as a demo for cmd than as a useful utility for the turtle module.  Also, we want people using turtle to learn Python, not to bypass the language altogether.

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

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

From report at bugs.python.org  Fri Nov  5 09:38:09 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 05 Nov 2010 08:38:09 +0000
Subject: [issue10320] printf %qd is nonstandard
In-Reply-To: <1288946289.37.0.37131892978.issue10320@psf.upfronthosting.co.za>
Message-ID: <1288946289.37.0.37131892978.issue10320@psf.upfronthosting.co.za>


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

Modules/_ctypes/callproc.c:PyCArg_repr() uses sprintf(%qd, long long),
which is a GNU (and more?) extension.  ISO C99 says %lld.

Instead, use "%" PY_FORMAT_LONG_LONG "d" from pyconfig.h/pyport.h.
Kills off #ifdef MS_WIN32 too.  If Python must support C libraries
that handle %qd but not %lld, configure.in seems the right place.

Index: ./Modules/_ctypes/callproc.c
@@ -468,8 +468,3 @@ PyCArg_repr(PyCArgObject *self)
     case 'Q':
-        sprintf(buffer,
-#ifdef MS_WIN32
-            "<cparam '%c' (%I64d)>",
-#else
-            "<cparam '%c' (%qd)>",
-#endif
+        sprintf(buffer, "<cparam '%c' (%" PY_FORMAT_LONG_LONG "d)>",
             self->tag, self->value.q);

pyport.h tests (defined(MS_WIN64) || defined(MS_WINDOWS)) instead of
#ifdef MS_WIN32 for when to use %I64d. I assume that's more up to date.

----------
assignee: theller
components: ctypes
messages: 120473
nosy: hfuru, theller
priority: normal
severity: normal
status: open
title: printf %qd is nonstandard
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Nov  5 10:03:14 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 05 Nov 2010 09:03:14 +0000
Subject: [issue10313] Reassure user: test_os BytesWarning is OK
In-Reply-To: <1288904372.33.0.549260824736.issue10313@psf.upfronthosting.co.za>
Message-ID: <hbf.20101105j1vq@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Antoine Pitrou writes:
> Hallvard, if you update your py3k working copy, do these warnings disappear?

Yes, switching to the svn version shuts them up.

----------

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

From report at bugs.python.org  Fri Nov  5 10:07:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 09:07:41 +0000
Subject: [issue10321] Add support for Message objects and binary data to
	smtplib.sendmail
In-Reply-To: <1288948061.88.0.822892450886.issue10321@psf.upfronthosting.co.za>
Message-ID: <1288948061.88.0.822892450886.issue10321@psf.upfronthosting.co.za>


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

The attached patch adds support to smtplib.SMTP.sendmail for the 'msg' argument to be, in addition to the currently accepted ASCII-only string, either a bytes string or a Message object.  It also adds support for byte strings to smtplib.SMPT.data.

Binary support is straightforward: if a byte string is passed, it is subject to leading '.' quoting but otherwise transmitted as is (that is, no \r\n transformation is done, unlike the string case).

For Message object support, the Message is serialized via BytesGenerator, meaning that a message parsed from a bytes source can be successfully re-transmitted via smtplib.  In addition to_addrs and from_addr can be set to None, in which case the addresses are obtained from the appropriate Message object headers (and, for safety, any Bcc header is deleted).

Although this patch is complete with docs, I'm not convinced this is the correct API.

First is the question of whether or not Message object support should be added.  It is in the patch because I started the work with the idea that serializing a Message via BytesGenerator was the "right way" to get binary data into smtplib, but as the implementation fell out I in fact ended up adding support for arbitrary binary data to sendmail (and data).  So in fact the Message object handling is not required in smtplib.

The feature is, however, clearly useful.  Perhaps, however, it should live in email as one or more helper methods instead.  I prefer having it in smtplib, but would like the opinions of others.

The second question is whether or not either functionality should be added to the existing sendmail method, or whether new methods should be created instead.  The alternative API might be:

    send_bytes(from_addr, to_addrs, msg, mail_options, rcpt_options)
    send_message(msg, mail_options, rcpt_options, from_addr=None, to_addrs=None)

Having completed the patch I'm neutral on this API refactoring, and again welcome other opinions.  'send_bytes' doesn't really seem like the right name, since it implies sending arbitrary bytes when in fact what is happening is a complete message transaction.  'send_bytesmail'?  Ugly :(

(See also issue 8050 and issue 4403.)

Note that I'd like to get some variation of this in (that at a minimum at least supports passing binary data to sendmail) before beta1, since it is the logical compliment to the new bytes support in the email package.

----------
assignee: r.david.murray
components: Library (Lib)
files: sendmail_message.patch
keywords: patch
messages: 120475
nosy: Allison.Vollmann, barry, ccgus, exarkun, giampaolo.rodola, pitrou, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add support for Message objects and binary data to smtplib.sendmail
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19502/sendmail_message.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10321>
_______________________________________

From report at bugs.python.org  Fri Nov  5 10:08:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 09:08:31 +0000
Subject: [issue4403] regression from 2.6: smtplib.py requiring ascii for
	sending messages
In-Reply-To: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
Message-ID: <1288948111.27.0.895594644095.issue4403@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm closing this issue as invalid, since as Martin pointed out you can't send unicode over the wire.

However, see issue 8050 where I've attached a patch that adds support for sending binary data as a by-product of adding support for Message objects.

>From Martin's msg76301 I gather he initially expected sendmail to take only binary data, which would it seems to me probably be the better API.  However at this point we are stuck with supporting ASCII-only strings in the API as well.

As a further note, however, the original example in this issue would have produced a non-RFC-conformant message when used in python 2.x.  You can't just send 8bit data willy-nilly, there are rules that should be followed.  Which is why the issue 8050 patch adds support for using Message objects, since the email package knows what those rules are...

----------
nosy: +r.david.murray
resolution:  -> invalid
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4403>
_______________________________________

From report at bugs.python.org  Fri Nov  5 10:11:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 09:11:07 +0000
Subject: [issue8050] smtplib SMTP.sendmail (TypeError: expected string or
	buffer)
In-Reply-To: <1267628417.9.0.660961800232.issue8050@psf.upfronthosting.co.za>
Message-ID: <1288948267.4.0.0586118615542.issue8050@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See issue 10321 for a proposal to add Message support to smtplib.

----------
nosy:  -Allison.Vollmann

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8050>
_______________________________________

From report at bugs.python.org  Fri Nov  5 10:12:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 09:12:20 +0000
Subject: [issue4403] regression from 2.6: smtplib.py requiring ascii for
	sending messages
In-Reply-To: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
Message-ID: <1288948340.42.0.260777839997.issue4403@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm closing this issue as invalid, since as Martin pointed out you can't send unicode over the wire.

However, see issue 10321 where I've attached a patch that adds support for sending binary data as a by-product of adding support for Message objects.

>From Martin's msg76301 I gather he initially expected sendmail to take only binary data, which would it seems to me probably be the better API.  However at this point we are stuck with supporting ASCII-only strings in the API as well.

As a further note, however, the original example in this issue would have produced a non-RFC-conformant message when used in python 2.x.  You can't just send 8bit data willy-nilly, there are rules that should be followed.  Which is why the issue 10321 patch adds support for using Message objects, since the email package knows what those rules are...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4403>
_______________________________________

From report at bugs.python.org  Fri Nov  5 10:12:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 09:12:26 +0000
Subject: [issue4403] regression from 2.6: smtplib.py requiring ascii for
	sending messages
In-Reply-To: <1227499144.72.0.0111235228814.issue4403@psf.upfronthosting.co.za>
Message-ID: <1288948346.6.0.684454527931.issue4403@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg120476

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4403>
_______________________________________

From report at bugs.python.org  Fri Nov  5 10:18:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 09:18:59 +0000
Subject: [issue10313] Reassure user: test_os BytesWarning is OK
In-Reply-To: <1288879397.21.0.548228653771.issue10313@psf.upfronthosting.co.za>
Message-ID: <1288948739.06.0.264649729937.issue10313@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/issue10313>
_______________________________________

From report at bugs.python.org  Fri Nov  5 10:49:58 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 05 Nov 2010 09:49:58 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288882537.9.0.304460920785.issue10311@psf.upfronthosting.co.za>
Message-ID: <hbf.20101105jw67@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Antoine Pitrou writes:
> By the way, I'd like to clear out a potential misunderstanding: the
> function you are patching doesn't call Python signal handlers in itself
> (those registered using signal.signal()). (...)

Good point - I'm talking C signal handlers, not Python signal handlers.

> If you want to save errno around Python signal handlers
> themselves, PyErr_CheckSignals must be patched as well.

Probably not.  I don't know Python's errno conventions, if any, but
it's usually a bug to use errno at any distance from the error.  The C
code near the error can save errno if it wants it later.  It can't do
that around C signal handlers, since those can get called anywhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10311>
_______________________________________

From report at bugs.python.org  Fri Nov  5 11:06:35 2010
From: report at bugs.python.org (=?utf-8?q?R=C3=BCgheimer?=)
Date: Fri, 05 Nov 2010 10:06:35 +0000
Subject: [issue10322] sys.argv and quoted arguments on command line
In-Reply-To: <1288951595.56.0.0656691082387.issue10322@psf.upfronthosting.co.za>
Message-ID: <1288951595.56.0.0656691082387.issue10322@psf.upfronthosting.co.za>


New submission from R?gheimer <frueghei at pasteur.fr>:

Words in quoted command line arguments containing whitespace are split into separate entries of the argument vector sys.argv. This implemetation (quote removal + word splitting) removes information required to read string arguments passed via the command line.

The expected behaviour would be to unquote the argument, but not to conduct word splitting within the quoted text.

----
Test program output:

> ./argtest arg1 arg2 "this should be a single argument"
  
  ['./argtest', 'arg1', 'arg2', 'this', 'should', 'be', 'a', 'single', 'argument']
----

(observed with Python 3.1.2 (r312:79147, Oct 28 2010, 14:12:33)
[GCC 4.1.2 20080704 (Red Hat 4.1.2-48)] on linux2

----------
components: None
files: argtest
messages: 120480
nosy: fcr
priority: normal
severity: normal
status: open
title: sys.argv and quoted arguments on command line
type: behavior
versions: Python 2.5, Python 3.1
Added file: http://bugs.python.org/file19503/argtest

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10322>
_______________________________________

From report at bugs.python.org  Fri Nov  5 11:07:41 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 05 Nov 2010 10:07:41 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288882208.61.0.379860480119.issue10311@psf.upfronthosting.co.za>
Message-ID: <hbf.20101105k7nm@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Antoine Pitrou writes:
> I think it is extremely unlikely that mutating errno in a signal handler
> is unsafe (after all, the library functions called from that handler can
> mutate errno too: that's the whole point of the patch IIUC). Adding some
> configure machinery for this seems unwarranted to me.

Fine by me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10311>
_______________________________________

From report at bugs.python.org  Fri Nov  5 11:13:39 2010
From: report at bugs.python.org (Shashank)
Date: Fri, 05 Nov 2010 10:13:39 +0000
Subject: [issue10323] Final state of underlying sequence in islice
In-Reply-To: <1288952019.84.0.665724422308.issue10323@psf.upfronthosting.co.za>
Message-ID: <1288952019.84.0.665724422308.issue10323@psf.upfronthosting.co.za>


New submission from Shashank <shashank.sunny.singh at gmail.com>:

-- Converting the discussion here http://mail.python.org/pipermail/python-list/2010-November/1259601.html to a bug report (+nosy for everyone that responded, quoting the initial message for context)

Are there any promises made with regard to final state of the underlying sequence that islice slices?
for example consider this

>>> from itertools import *
>>> c = count()
>>> list(islice(c, 1, 3, 50))
[1]
>>> c.next()
51

Now, the doc [1] says "If stop is None, then iteration continues until the iterator is exhausted, if at all; otherwise, it stops at the specified position".
It clearly is not stopping at stop (3).

Further, the doc gives an example of how this is *equivalent* to a generator defined in the same section. It turns out, these two are not exactly the
same if the side-effect of the code is considered on the underlying sequence.

Redefining islice using the generator function defined in the doc gives different (and from one pov, expected) result
>>> def islice(iterable, *args):
...     # islice('ABCDEFG', 2) --> A B
...
>>> c = count()
>>> list(islice(c, 1, 3, 50))
[1]
>>> c.next()
2

While "fixing" this should be rather easy in terms of the change in code required it might break any code depending
on this seemingly incorrect behavior

----------
components: Interpreter Core
messages: 120482
nosy: ned.deily, rhettinger, shashank, terry.reedy
priority: normal
severity: normal
status: open
title: Final state of underlying sequence in islice
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10323>
_______________________________________

From report at bugs.python.org  Fri Nov  5 11:25:31 2010
From: report at bugs.python.org (Shashank)
Date: Fri, 05 Nov 2010 10:25:31 +0000
Subject: [issue10323] Final state of underlying sequence in islice
In-Reply-To: <1288952019.84.0.665724422308.issue10323@psf.upfronthosting.co.za>
Message-ID: <1288952731.18.0.627612454683.issue10323@psf.upfronthosting.co.za>


Shashank <shashank.sunny.singh at gmail.com> added the comment:

@Raymond: I don't have a particular use case where I had a problem with this behavior. I came across this "problem" when looking at this issue http://bugs.python.org/issue6305.

An important problem that can happen with this behavior is that it does extra work that is not needed. Consider the case (it appears in Lib/test/test_itertools.py):

islice(count(), 1, 10, maxsize)

where maxsize is MAX_Py_ssize_t

Current implementation goes all the way up to maxsize when it should have just stopped at 10.

You are probably right in saying that the caller can make sure that the parameters are such that such cases don't arise but I would still like to see python doing the best possible thing as far as possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10323>
_______________________________________

From report at bugs.python.org  Fri Nov  5 12:25:02 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Nov 2010 11:25:02 +0000
Subject: [issue10322] sys.argv and quoted arguments on command line
In-Reply-To: <1288951595.56.0.0656691082387.issue10322@psf.upfronthosting.co.za>
Message-ID: <1288956302.0.0.200729750459.issue10322@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I don't see this behavior on MacOS:

$ ./argtest arg1 arg2 "this should be a single argument"
2.6.1 (r261:67515, Feb 11 2010, 15:47:53) 
[GCC 4.2.1 (Apple Inc. build 5646)]
['./argtest', 'arg1', 'arg2', 'this should be a single argument']

This splitting is done by the shell (Unix-like systems) or by the C runtime (Windows), not by Python. What OS are you running?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10322>
_______________________________________

From report at bugs.python.org  Fri Nov  5 12:39:27 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Nov 2010 11:39:27 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1288957167.4.0.980058001567.issue10318@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Is there any reason for the test files to have a shebang line at all? I think those should be removed, which would cut the problem in half.

Also, given "-m", I'm not sure any of the files in the stdlib should have a shebang line. Is there really an expectation that these should be run directly? Is anyone really running UserString.py as a script in order to run its tests?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Nov  5 13:00:24 2010
From: report at bugs.python.org (=?utf-8?q?R=C3=BCgheimer?=)
Date: Fri, 05 Nov 2010 12:00:24 +0000
Subject: [issue10322] sys.argv and quoted arguments on command line
In-Reply-To: <1288951595.56.0.0656691082387.issue10322@psf.upfronthosting.co.za>
Message-ID: <1288958424.02.0.685375959461.issue10322@psf.upfronthosting.co.za>


R?gheimer <frueghei at pasteur.fr> added the comment:

2.6.18-194.17.1.el5 #1 SMP Wed Sep 29 12:51:33 EDT 2010 i686 i686 i386 GNU/Linux

GNU bash, version 3.2.25(1)-release (i686-redhat-linux-gnu)

I wrote test program in C to do the same thing as before and the arguments are treated properly:

> ./testcargs arg1 arg2 "this should be one arg"
argument 0 is:    ./testcargs
argument 1 is:    arg1
argument 2 is:    arg2
argument 3 is:    this should be one arg

My suspicion is that sys implementation goes into a branch intended for a different OS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10322>
_______________________________________

From report at bugs.python.org  Fri Nov  5 13:13:16 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Nov 2010 12:13:16 +0000
Subject: [issue10322] sys.argv and quoted arguments on command line
In-Reply-To: <1288951595.56.0.0656691082387.issue10322@psf.upfronthosting.co.za>
Message-ID: <1288959196.84.0.93957387313.issue10322@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The python version works for me also on a Fedora box with 3.2 and 2.7.

What shell are you using?

Did you compile this python yourself, or did it come with your distro?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10322>
_______________________________________

From report at bugs.python.org  Fri Nov  5 13:23:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 12:23:09 +0000
Subject: [issue10322] sys.argv and quoted arguments on command line
In-Reply-To: <1288951595.56.0.0656691082387.issue10322@psf.upfronthosting.co.za>
Message-ID: <1288959789.07.0.669894680856.issue10322@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Works fine for me on Gentoo linux.

What exactly is 'python' in your path, and what happens if you do /usr/bin/python3 argtest?

I'm 99.99% certain this is not a bug in Python, otherwise it would have been reported long before now, since it would represent a major change in behavior.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10322>
_______________________________________

From report at bugs.python.org  Fri Nov  5 13:30:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 12:30:27 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1288960227.01.0.383279288519.issue10318@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Benjamin did some cleanup in this area in at least py3k, so he might have some thoughts, making him nosy.

----------
nosy: +benjamin.peterson, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Nov  5 13:31:22 2010
From: report at bugs.python.org (Nicolas Kaiser)
Date: Fri, 05 Nov 2010 12:31:22 +0000
Subject: [issue10324] Modules/binascii.c: simplify expressions
In-Reply-To: <1288960282.63.0.36896617849.issue10324@psf.upfronthosting.co.za>
Message-ID: <1288960282.63.0.36896617849.issue10324@psf.upfronthosting.co.za>


New submission from Nicolas Kaiser <nikai at nikai.net>:

Hi there!

I noticed two expressions that can be simplified like:
 (a || (!a && b)) => (a || b)

Best regards,
Nicolas Kaiser
---
--- a/Modules/binascii.c	2010-11-05 13:21:22.075303326 +0100
+++ b/Modules/binascii.c	2010-11-05 13:24:16.986174756 +0100
@@ -1337,8 +1337,7 @@ binascii_b2a_qp (PyObject *self, PyObjec
             ((data[in] == '\t' || data[in] == ' ') && (in + 1 == datalen)) ||
             ((data[in] < 33) &&
              (data[in] != '\r') && (data[in] != '\n') &&
-             (quotetabs ||
-            (!quotetabs && ((data[in] != '\t') && (data[in] != ' '))))))
+             (quotetabs || ((data[in] != '\t') && (data[in] != ' ')))))
         {
             if ((linelen + 3) >= MAXLINESIZE) {
                 linelen = 0;
@@ -1410,8 +1409,7 @@ binascii_b2a_qp (PyObject *self, PyObjec
             ((data[in] == '\t' || data[in] == ' ') && (in + 1 == datalen)) ||
             ((data[in] < 33) &&
              (data[in] != '\r') && (data[in] != '\n') &&
-             (quotetabs ||
-            (!quotetabs && ((data[in] != '\t') && (data[in] != ' '))))))
+             (quotetabs || ((data[in] != '\t') && (data[in] != ' ')))))
         {
             if ((linelen + 3 )>= MAXLINESIZE) {
                 odata[out++] = '=';

----------
components: Extension Modules
messages: 120490
nosy: nikai
priority: normal
severity: normal
status: open
title: Modules/binascii.c: simplify expressions
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10324>
_______________________________________

From report at bugs.python.org  Fri Nov  5 13:37:09 2010
From: report at bugs.python.org (Nicolas Kaiser)
Date: Fri, 05 Nov 2010 12:37:09 +0000
Subject: [issue10324] Modules/binascii.c: simplify expressions
In-Reply-To: <1288960282.63.0.36896617849.issue10324@psf.upfronthosting.co.za>
Message-ID: <1288960629.39.0.00281279042582.issue10324@psf.upfronthosting.co.za>


Changes by Nicolas Kaiser <nikai at nikai.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19504/python-binascii.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10324>
_______________________________________

From report at bugs.python.org  Fri Nov  5 14:09:27 2010
From: report at bugs.python.org (=?utf-8?q?Frank_R=C3=BCgheimer?=)
Date: Fri, 05 Nov 2010 13:09:27 +0000
Subject: [issue10322] sys.argv and quoted arguments on command line
In-Reply-To: <1288951595.56.0.0656691082387.issue10322@psf.upfronthosting.co.za>
Message-ID: <1288962567.32.0.600127347217.issue10322@psf.upfronthosting.co.za>


Frank R?gheimer <frueghei at pasteur.fr> added the comment:

You are right, it seems to work when the file is passed directly into python so the quotes are stripped somewhere before python even gets to see them. 

Thanks

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10322>
_______________________________________

From report at bugs.python.org  Fri Nov  5 14:11:26 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Nov 2010 13:11:26 +0000
Subject: [issue10322] sys.argv and quoted arguments on command line
In-Reply-To: <1288951595.56.0.0656691082387.issue10322@psf.upfronthosting.co.za>
Message-ID: <1288962686.95.0.540531419178.issue10322@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
components:  -None
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10322>
_______________________________________

From report at bugs.python.org  Fri Nov  5 14:56:12 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 05 Nov 2010 13:56:12 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <1288965372.95.0.322439917087.issue10325@psf.upfronthosting.co.za>
Message-ID: <1288965372.95.0.322439917087.issue10325@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Include/pyport.h invites potential compile errors with the definitions
  #define PY_LLONG_MIN LLONG_MIN
  #define PY_LLONG_MAX LLONG_MAX
  #define PY_ULLONG_MAX ULLONG_MAX
which can fall back to gcc variants or to
  #else
  /* Otherwise, rely on two's complement. */
  #define PY_ULLONG_MAX (~0ULL)
  #define PY_LLONG_MAX  ((long long)(PY_ULLONG_MAX>>1))
  #define PY_LLONG_MIN (-PY_LLONG_MAX-1)

Code developed with the former #definitions might use them in '#if's,
and then break when it meets a host where the fallbacks are used.

It would be safer if either all the macros and pyconfig variants used
casts, or all used predefined constants - from configure if needed.

The signed variants would break because '#if's do not accept casts.

PY_ULLONG_MAX is more insidious: If it meets a host which supports
a type bigger than unsigned long long, then preprocessor arithmetic
will happen in that type. ~0ULL in #if statements is then actually
the same as ~ULLL or whatever it would be spelled.  This one
definitely needs a cast to protect from the surprise that
preprocessor value != value outside preprocessor.

You get the same effect with ~0U vs ~0UL on a 64-bit compiler,
and ~0U vs ~0ULL on a C99 compiler:
#if (~0U) == (~0ULL)
# error "oops"
#endif

Incidentally, the "two's complement" comment is wrong.
It also relies on unsigned long long being widest type with no
padding bits, and -LLONG_MAX-1 not being a trap representation.
~0ULL is not two's complement since it is unsigned, it works
because it has the same result as -1ULL which is defined to
have the max value.
The PY_LLONG_MIN definitions rely on two's complement. If
anyone cared, one could avoid that with
#define PY_LLONG_MIN (-PY_LLONG_MAX-(/*two's complement*/(-1LL & 3)==3))


Anyway.  If they use casts, fix PY_TIMEOUT_MAX in 3.2a3 pythread.h:
#define PY_MIN(x, y) ((x) < (y) ? (x) : (y))
#define PY_TIMEOUT_MAXTMP instead of PY_TIMEOUT_MAX, and then
#ifndef NT_THREADS
#define PY_TIMEOUT_MAX PY_TIMEOUT_MAXTMP
#else
#define PY_TIMEOUT_MAX PY_MIN(Py_LL(0xFFFFFFFF)*1000, PY_TIMEOUT_MAXTMP)
#endif

----------
components: Interpreter Core
messages: 120492
nosy: hfuru
priority: normal
severity: normal
status: open
title: PY_LLONG_MAX & co - preprocessor constants or not?
type: compile error
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:06:31 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 05 Nov 2010 14:06:31 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1288965991.87.0.463621687445.issue10318@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Removing shebang lines from svn completely and only *adding* them during installation steps as appropriate may be an interesting approach. (I noted that my grep of my local build found only correct references to python3.2 in the built scripts directory)

I'll add the list of Py3k files that are unexpectedly referencing something other than "/usr/bin/env python3" in SVN as well (note that this is a straight grep, without checking to see if any of them are *meant* to be referring to Python 2.x):

Doc/distutils/setupscript.rst does not use python3 in the example
Doc/faq/library.rst (multiple instances)
Doc/howto/unicode.rst
Doc/howto/webservers.rst
Doc/library/cgi.rst
Doc/library/logging.rst
Doc/library/urllib.request.rst
Doc/using/unix.rst

Lib/test/test_logging.py: #! /usr/bin/env python

Lib/cgi.py: #! /usr/bin/env python

Mac/BuildScript/build-installer.py: #! /usr/bin/env python
Mac/Tools/fixapplepython23.py: #! /usr/bin/env python
Mac/Tools/bundlebuilder.py: #! /usr/bin/env python

Tools/gdb/libpython.py: #! /usr/bin/env python
Tools/pybench/clockres.py: #!/usr/bin/env python
Tools/pybench/pybench.py: #!/usr/local/bin/python -O
Tools/pybench/Setup.py: #!python
Tools/pybench/systimes.py: #!/usr/bin/env python
Tools/pynche/pynche: #! /usr/bin/env python
Tools/pynche/pynche.pyw: #! /usr/bin/env python
Tools/scripts/2to3.py: #! /usr/bin/env python
Tools/scripts/gprof2html.py: #! /usr/bin/env python32.3
Tools/scripts/reindent-rst.py: #!/usr/bin/env python
Tools/world/world: #! /usr/bin/env python

The spec file in Misc/RPM also has multiple references to fixing shebang lines, but I don't know anything about spec files, so I didn't even try to check if it was doing the right thing.

----------
nosy: +ncoghlan
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:07:46 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 05 Nov 2010 14:07:46 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1288966066.43.0.147874623485.issue10318@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

For the record, my list is from an svn checkout of r86191

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:16:15 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 05 Nov 2010 14:16:15 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1288966575.74.0.102568930526.issue10318@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

A few more deeper in the py3k source tree:

Doc/tools/docutils/_string_template_compat.py
Doc/tools/docutils/readers/python/pynodes.py
Doc/tools/sphinx/pycode/pgen2/token.py
Lib/lib2to3/tests/data/different_encoding.py

Adding Georg, since this affects the docs as well as the source code.

----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:16:24 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 05 Nov 2010 14:16:24 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1288966584.75.0.930719712574.issue10318@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee: docs at python -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:17:29 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 05 Nov 2010 14:17:29 +0000
Subject: [issue10326] Can't pickle unittest.TestCase instances
In-Reply-To: <1288966649.03.0.6620170389.issue10326@psf.upfronthosting.co.za>
Message-ID: <1288966649.03.0.6620170389.issue10326@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

In Python 2.7 a change was introduced to TestCase which involves storing a dictionary of method objects on TestCase instances. This makes them unpickleable.

unittest2 stores strings (method names) instead of method objects (a fix to make TestCase instances copyable under earlier versions of Python). The same fix could be applied to unittest.

----------
assignee: michael.foord
components: Library (Lib)
keywords: easy
messages: 120496
nosy: michael.foord
priority: low
severity: normal
stage: needs patch
status: open
title: Can't pickle unittest.TestCase instances
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10326>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:22:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 14:22:20 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <1288965372.95.0.322439917087.issue10325@psf.upfronthosting.co.za>
Message-ID: <1288966940.32.0.674082571633.issue10325@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/issue10325>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:27:55 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 05 Nov 2010 14:27:55 +0000
Subject: [issue5251] contextlib.nested inconsistent with, well,
	nested with statements due exceptions raised in __enter__
In-Reply-To: <1234548570.86.0.145574171135.issue5251@psf.upfronthosting.co.za>
Message-ID: <1288967275.14.0.524569341323.issue5251@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Reopening as a reminder to myself that I have a new PEP I want to write in this area. The idea is essentially a lighter weight alternative to PEP 377 that adds an optional __entered__ method to the context management protocol along the following lines:

_v = cm.__enter__()
try:
  if hasattr(cm, "__entered__"):
    VAL = cm.__entered__(_v)
  else:
    VAL = _v
  # do stuff
finally:
  cm.__exit__(*exception_status)

Providing a second, optional method that is executed *inside* the body will let CMs do things they can't do now (like skip the body of the with statement) without significantly affecting the behaviour of normal CMs. Notably, GeneratorContextManager will be able to use this to more gracefully handle the case where the generator doesn't yield a value.

I plan to flesh this out into a python-ideas post (and likely a subsequent PEP) at some point in the next few months.

----------
components: +Interpreter Core -Documentation
resolution: out of date -> postponed
status: closed -> open
versions: +Python 3.3 -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5251>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:31:53 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 05 Nov 2010 14:31:53 +0000
Subject: [issue10327] Abnormal SSL timeouts when using socket timeouts - once
	again
In-Reply-To: <1288967513.64.0.717673746201.issue10327@psf.upfronthosting.co.za>
Message-ID: <1288967513.64.0.717673746201.issue10327@psf.upfronthosting.co.za>


New submission from Pascal Chambon <chambon.pascal at gmail.com>:

On freebsd 8, using python 2.6.6, I've run into the bug already widely dealt with in these reports :
http://bugs.python.org/issue1380952
http://bugs.python.org/issue1153016

When using socket timeouts (eg. with socket.setdefaulttimeout()), whatever the timeout I use (eg. 10 seconds), I begin having random "SSLError: The read operation timed out" exceptions in my http calls, via urlopen or 3rd party libraries.

Here is an example of traceback ending:

...
  File "/usr/local/lib/python2.6/site-packages/ZSI-2.0-py2.6.egg/ZSI/client.py", line 349, in ReceiveRaw
    response = self.h.getresponse()
  File "/usr/local/lib/python2.6/httplib.py", line 990, in getresponse
    response.begin()
  File "/usr/local/lib/python2.6/httplib.py", line 391, in begin
    version, status, reason = self._read_status()
  File "/usr/local/lib/python2.6/httplib.py", line 349, in _read_status
    line = self.fp.readline()
  File "/usr/local/lib/python2.6/socket.py", line 427, in readline
    data = recv(1)
  File "/usr/local/lib/python2.6/ssl.py", line 215, in recv
    return self.read(buflen)
  File "/usr/local/lib/python2.6/ssl.py", line 136, in read
    return self._sslobj.read(len)
SSLError: The read operation timed out

I've checked the py2.6.6 sources, the patches described in previous reports are still applied (eg. SSL_pending() checks etc.), I have no idea of how so long socket timeouts might interfere with ssl operations...

----------
components: IO
messages: 120498
nosy: arekm, georg.brandl, maltehelmert, pakal, pristine777, tarek-ziade, twouters
priority: normal
severity: normal
status: open
title: Abnormal SSL timeouts when using socket timeouts - once again
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10327>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:33:48 2010
From: report at bugs.python.org (Alexander Schmolck)
Date: Fri, 05 Nov 2010 14:33:48 +0000
Subject: [issue10328] re.sub[n] doesn't seem to handle /Z replacements
	correctly in all cases
In-Reply-To: <1288967628.79.0.550964963089.issue10328@psf.upfronthosting.co.za>
Message-ID: <1288967628.79.0.550964963089.issue10328@psf.upfronthosting.co.za>


New submission from Alexander Schmolck <a.schmolck+bug at gmail.com>:

In certain cases a zero-width /Z match that should be replaced isn't.

An example might help:

 re.compile('(?m)(?P<trailing_ws>[ \t]+\r*$)|(?P<no_final_newline>(?<=[^\n])\Z)').subn(lambda m:next('<'+k+'>' for k,v in m.groupdict().items() if v is not None), 'foobar ')

this gives

 ('foobar<trailing_ws>', 1)

I would have expected

('foobar<trailing_ws><no_final_newline>', 2)

Contrast this with the following behavior:

 [m.span() for m in re.compile('(?P<trailing_ws>[ \t]+\r*$)|(?P<no_final_newline>(?<=[^\n])\Z)', re.M).finditer('foobar ')]

gives
 
 [(6, 7), (7, 7)]

The matches are clearly not overlapping and the re module docs for sub say "Return the string obtained by replacing the leftmost non-overlapping occurrences of pattern in string by the replacement repl.", so I would have expected two replacements.


This seems to be what perl is doing:

 echo -n 'foobar ' | perl -pe 's/(?m)(?P<trailing_ws>[ \t]+\r*$)|(?P<no_final_newline>(?<=[^\n])\Z)/<$&>/g'                    

gives
 foobar< ><>%

----------
components: Regular Expressions
messages: 120499
nosy: Alexander.Schmolck
priority: normal
severity: normal
status: open
title: re.sub[n] doesn't seem to handle /Z replacements correctly in all cases
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10328>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:40:47 2010
From: report at bugs.python.org (Malte Helmert)
Date: Fri, 05 Nov 2010 14:40:47 +0000
Subject: [issue10327] Abnormal SSL timeouts when using socket timeouts - once
	again
In-Reply-To: <1288967513.64.0.717673746201.issue10327@psf.upfronthosting.co.za>
Message-ID: <1288968047.99.0.34079409633.issue10327@psf.upfronthosting.co.za>


Malte Helmert <helmert at informatik.uni-freiburg.de> added the comment:

I checked if issue1153016 has reappeared for me (Ubuntu, Python 2.6.6), but it hasn't. Both the urllib and the imaplib examples given there work fine for me. Or at least opening the connections works fine for me, which it didn't at the time of issue1153016.

But you say you have random errors, so maybe I need to exercise this more heavily. Can you attach a test script that can be used to make the bug appear?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10327>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:43:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Nov 2010 14:43:44 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1288942452.88.0.931355211696.issue7061@psf.upfronthosting.co.za>
Message-ID: <AANLkTim0k85nY9F_9WFU=A4wyEq_J5QjZoVZ+j_2Z762@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 5, 2010 at 3:34 AM, Georg Brandl <report at bugs.python.org> wrote:
..
> Why shouldn't global function doctests be runnable?

They should - I just couldn't figure out a better hack that would work
for both mathods and functions.  Note that functions are
auto-generated in turtle from Screen and Turtle methods.  The doctests
are just method doctests with turtle. or screen. prefix dropped.  In
order to remove dependency between doctests, I create a new turtle for
each test and assign it to global "turtle" variable.  For some reason
similar approach did not work for functions.  I'll keep trying,
though.

On the other hand, since function doctests are auto-generated from
method doctests, there is little to be gained from running them
separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:52:21 2010
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 05 Nov 2010 14:52:21 +0000
Subject: [issue9244] multiprocessing.pool: Worker crashes if result can't be
	encoded
In-Reply-To: <1279021915.02.0.743108448879.issue9244@psf.upfronthosting.co.za>
Message-ID: <1288968741.33.0.878050573654.issue9244@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Fine w/ committing this Ask.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9244>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:53:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 14:53:07 +0000
Subject: [issue10327] Abnormal SSL timeouts when using socket timeouts - once
	again
In-Reply-To: <1288967513.64.0.717673746201.issue10327@psf.upfronthosting.co.za>
Message-ID: <1288968787.68.0.619949065685.issue10327@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> When using socket timeouts (eg. with socket.setdefaulttimeout()),
> whatever the timeout I use (eg. 10 seconds), I begin having random
> "SSLError: The read operation timed out" exceptions in my http calls,
> via urlopen or 3rd party libraries.

Well, this isn't a random error. It just signals that the timeout has expired. It's a pity that it raises SSLError rather than socket.timeout, though.

Or are you saying that the exception is raised too early? If so, it would be nice to have a way of reproducing.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10327>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:53:21 2010
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 05 Nov 2010 14:53:21 +0000
Subject: [issue7707] multiprocess.Queue operations during import can lead to
	deadlocks
In-Reply-To: <1263573315.16.0.465636049394.issue7707@psf.upfronthosting.co.za>
Message-ID: <1288968801.28.0.610200927049.issue7707@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Fine w/ committing this Ask.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7707>
_______________________________________

From report at bugs.python.org  Fri Nov  5 15:54:35 2010
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 05 Nov 2010 14:54:35 +0000
Subject: [issue8028] self.terminate() from a multiprocessing.Process raises
	AttributeError exception
In-Reply-To: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za>
Message-ID: <1288968875.76.0.946698080656.issue8028@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Fine w/ committing this Ask as-is ask. You are correct in the original intent of the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8028>
_______________________________________

From report at bugs.python.org  Fri Nov  5 16:01:38 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 05 Nov 2010 15:01:38 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

It seems that on Python 3 (i.e. the py3k branch) trace.py can not handle source that includes Unicode characters. Running the test suite with code coverage info via

   ./python Lib/test/regrtest.py -T -N -uurlfetch,largefile,network,decimal

sometimes fails with the following exception:

Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 1500, in <module>
    main()
  File "Lib/test/regrtest.py", line 696, in main
    r.write_results(show_missing=True, summary=True, coverdir=coverdir)
  File "/home/coverage/python/Lib/trace.py", line 319, in write_results
    lnotab, count)
  File "/home/coverage/python/Lib/trace.py", line 369, in write_results_file
    outfile.write(line.expandtabs(8))
UnicodeEncodeError: 'ascii' codec can't encode character '\xe4' in
position 30: ordinal not in range(128)

The script that produces code coverage info on http://coverage.livinglogic.de/ uses this feature to generate code coverage info.

Applying the attached patch (i.e. specifying an explicit encoding when opening the output file) fixes the problem.

----------
files: trace.diff
keywords: patch
messages: 120506
nosy: doerwalter, haypo
priority: normal
severity: normal
status: open
title: trace.py and unicode in Python 3
Added file: http://bugs.python.org/file19505/trace.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Fri Nov  5 16:07:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 15:07:07 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1288969627.51.0.768507977596.issue10329@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib)
nosy: +belopolsky
stage:  -> patch review
type:  -> behavior
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Fri Nov  5 16:22:51 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 05 Nov 2010 15:22:51 +0000
Subject: [issue10327] Abnormal SSL timeouts when using socket timeouts - once
	again
In-Reply-To: <1288967513.64.0.717673746201.issue10327@psf.upfronthosting.co.za>
Message-ID: <1288970571.44.0.534299092278.issue10327@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

The exception is raised too early, none of my calls takes more than 1-2 seconds and I've a default timeout set at 10s or more.

This occurs rather rarely, one or two times on some hundreds of calls. I'll make a little script to try to isolate the pb.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10327>
_______________________________________

From report at bugs.python.org  Fri Nov  5 16:25:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 05 Nov 2010 15:25:10 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1288970710.68.0.370433447497.issue10329@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Fri Nov  5 16:26:45 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Fri, 05 Nov 2010 15:26:45 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288970805.51.0.00394839332218.issue7061@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

What do you mean with "similar approach"?

Keep in mind, that functions derived form turtle methods,
call methods for the class variable _pen of class Turtle.
A new Turtle-object is bound to _pen, if it is not already
present, whenever one of these functions is called, via _getpen()

So perhaps _getpen() can do for you what you need?

(A similar approach is used for screen-oriented functions with turtle._screen.)

I'm very sorry that, due to time restrictions, for the next two or three months I'm not able to participate in these discussions as intensely as I'd like to.

Best regards,
Gregor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Fri Nov  5 16:38:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 15:38:19 +0000
Subject: [issue10328] re.sub[n] doesn't seem to handle /Z replacements
	correctly in all cases
In-Reply-To: <1288967628.79.0.550964963089.issue10328@psf.upfronthosting.co.za>
Message-ID: <1288971499.74.0.672352078123.issue10328@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/issue10328>
_______________________________________

From report at bugs.python.org  Fri Nov  5 16:40:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 05 Nov 2010 15:40:46 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1288971646.77.0.893727217128.issue10318@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You can ignore those under Doc/tools; they are neither part of the distribution and nor installed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Nov  5 16:53:39 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 05 Nov 2010 15:53:39 +0000
Subject: [issue10327] Abnormal SSL timeouts when using socket timeouts - once
	again
In-Reply-To: <1288967513.64.0.717673746201.issue10327@psf.upfronthosting.co.za>
Message-ID: <1288972419.46.0.781868697897.issue10327@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Humz on second thought you may be right, now I have some trouble reproducing the bugs (wich have been there since the beginning, though), so it may be that the webservice I call seldom takes 10+ seconds to answer (weird anyway).

I've placed timers in the codebase, the pb will eventually surface again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10327>
_______________________________________

From report at bugs.python.org  Fri Nov  5 17:56:49 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 05 Nov 2010 16:56:49 +0000
Subject: [issue10323] Final state of underlying sequence in islice
In-Reply-To: <1288952019.84.0.665724422308.issue10323@psf.upfronthosting.co.za>
Message-ID: <1288976209.61.0.480737391074.issue10323@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
components: +Documentation -Interpreter Core
priority: normal -> low
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10323>
_______________________________________

From report at bugs.python.org  Fri Nov  5 17:57:57 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 05 Nov 2010 16:57:57 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1288976277.34.0.165039409641.issue5412@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Documentation complete.

----------
Added file: http://bugs.python.org/file19506/issue5412.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Fri Nov  5 17:58:07 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 05 Nov 2010 16:58:07 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1288976287.13.0.196221481385.issue5412@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


Removed file: http://bugs.python.org/file19501/issue5412.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Fri Nov  5 18:18:23 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 05 Nov 2010 17:18:23 +0000
Subject: [issue10288] Remove deprecated C "character" handling macros
	ISUPPER() etc
In-Reply-To: <1288651306.95.0.100885156034.issue10288@psf.upfronthosting.co.za>
Message-ID: <1288977503.89.0.523828026365.issue10288@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Thanks for reviewing.

If I'm reading things correctly, the ISUPPER et al macros were added in 2.6 and 3.0, and deprecated in 2.7 and 3.1.

Tested with a full run of "-m test.regrtest -uall" here (x86_64 Fedora 13), with both 2-byte and 4-byte unicode; no failures:
    342 tests OK.
    7 tests skipped:
        test_gdb test_kqueue test_ossaudiodev test_startfile test_winreg
        test_winsound test_zipfile64
    Those skips are all expected on linux2.

I've fixed up the issue number in Misc/NEWS in my local tree.

The patch as-is doesn't make sense for 3.1 or 2.7 (the macros should remain within the maintenance branches, in deprecated form) - do I need to explicitly mark this revision (e.g. using "svnmerge.py block"?)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10288>
_______________________________________

From report at bugs.python.org  Fri Nov  5 18:18:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Nov 2010 17:18:59 +0000
Subject: [issue10317] Add TurtleShell to turtle
In-Reply-To: <1288924856.05.0.699658333719.issue10317@psf.upfronthosting.co.za>
Message-ID: <1288977539.54.0.213924486335.issue10317@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/issue10317>
_______________________________________

From report at bugs.python.org  Fri Nov  5 18:19:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Nov 2010 17:19:55 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1288977595.31.0.681390241559.issue10318@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Nov  5 18:20:39 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Nov 2010 17:20:39 +0000
Subject: [issue10288] Remove deprecated C "character" handling macros
	ISUPPER() etc
In-Reply-To: <1288651306.95.0.100885156034.issue10288@psf.upfronthosting.co.za>
Message-ID: <1288977639.89.0.166087683212.issue10288@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'd 'svnmerge block' them, just in case anyone decides to manually merge (which I doubt will happen, but you never know).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10288>
_______________________________________

From report at bugs.python.org  Fri Nov  5 18:25:38 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 05 Nov 2010 17:25:38 +0000
Subject: [issue10288] Remove deprecated C "character" handling macros
	ISUPPER() etc
In-Reply-To: <1288651306.95.0.100885156034.issue10288@psf.upfronthosting.co.za>
Message-ID: <1288977938.8.0.916859955341.issue10288@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Committed to py3k in r86210

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10288>
_______________________________________

From report at bugs.python.org  Fri Nov  5 18:33:39 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 05 Nov 2010 17:33:39 +0000
Subject: =?utf-8?q?=5Bissue10053=5D_Don=E2=80=99t_close_fd_when_FileIO=2E=5F=5Fini?=
	=?utf-8?b?dF9fIGZhaWxz?=
In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za>
Message-ID: <1288978419.85.0.0774822595468.issue10053@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Recently, the patch to close fd when FileIO#__init__
failed and closefd = True was checked in. Is this mean
this issue is invalid?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10053>
_______________________________________

From report at bugs.python.org  Fri Nov  5 18:34:04 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 05 Nov 2010 17:34:04 +0000
Subject: [issue1346238] A constant folding optimization pass for the AST
Message-ID: <1288978444.33.0.518286982937.issue1346238@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

FWIW, I'm working on fixing up the this patch to work against py3k; I'm assuming there's still interest in the AST visitor + specific optimization passes approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346238>
_______________________________________

From report at bugs.python.org  Fri Nov  5 18:47:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 05 Nov 2010 17:47:14 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <1288965372.95.0.322439917087.issue10325@psf.upfronthosting.co.za>
Message-ID: <1288979234.76.0.50707642444.issue10325@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report; I agree that there's a potential issue here, and I also think that all these definitions *should* be preprocessor defines.  (Idle question: does C99 require that LONG_MAX and friends are usable in the preprocessor?  I see it in e.g. 7.18.2p2 for INT32_MAX and friends, but I'm not sure if there's something similar for LONG_MAX and co.)

Can you suggest a suitable fix for the PY_ULLONG_MAX and PY_LLONG_MAX defines?  Note that a configure-based fix may need to take into account the special needs of Windows---for which configure isn't used, of course---and OS X---where the same code, based on a single run of configure, should be able to compile to the correct thing both in 32-bit and 64-bit mode, so that universal builds work;  see PC/pyconfig.h and Include/pymacconfig.h respectively for dealing with these issues.

BTW, do you know of any modern non-Windows platforms that don't define LLONG_MIN and LLONG_MAX?  It may well be that the "two's complement" fallback hasn't been exercised in recent years.

> Incidentally, the "two's complement" comment is wrong.
> It also relies on unsigned long long being widest type with no
> padding bits, and -LLONG_MAX-1 not being a trap representation.

Agreed---that comment needs to be better.  I think it's fine, though, for practical purposes to assume an absence of padding bits and no trap representation;  IIRC there are places internally (e.g., in the bitwise operators section of the 'int' type implementation) that already assume two's complement + no padding bits + no trap representation.  (I *thought* I had an old issue open somewhere about documenting---and possibly testing---these assumptions, but now I can't find it.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Fri Nov  5 18:52:35 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 05 Nov 2010 17:52:35 +0000
Subject: [issue10232] Tkinter issues with Scrollbar and custom widget list
In-Reply-To: <1288366788.46.0.695886030233.issue10232@psf.upfronthosting.co.za>
Message-ID: <1288979555.13.0.812827687679.issue10232@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I think issue4 happens because all frames are grid-forgotten
in redisp(), sometimes widget becomes empty. I think we can
close this issue as invalid.

P.S. Try this change in redisp()

        yy = 0
        for xx in self.frms[start:self.maxdisp+start]:
            xx.grid(in_=self,row=yy,column=0)
            yy += 1
        for xx in self.frms[self.active:self.maxdisp+self.active]:
            if xx in self.frms[start:self.maxdisp+start]:
                continue
            xx.grid_forget()

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10232>
_______________________________________

From report at bugs.python.org  Fri Nov  5 19:18:46 2010
From: report at bugs.python.org (Robert Lerche)
Date: Fri, 05 Nov 2010 18:18:46 +0000
Subject: [issue10232] Tkinter issues with Scrollbar and custom widget list
In-Reply-To: <1288366788.46.0.695886030233.issue10232@psf.upfronthosting.co.za>
Message-ID: <1288981126.67.0.484540808511.issue10232@psf.upfronthosting.co.za>


Robert Lerche <ral at msbit.com> added the comment:

Thank you, Hirokazu!  I see now -- deleting the rows first causes the scroll bar to shrink.  So I take it calling grid with a row/column that is already in the grid replaces the prior mapped widget.

[or should I say, "domo arigato Yamamoto-san"?]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10232>
_______________________________________

From report at bugs.python.org  Fri Nov  5 19:22:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Nov 2010 18:22:12 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1288981332.97.0.556899891266.issue10329@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I don't think trace.diff is proposed for commit.  I see it more as a supporting file for diagnosing the problem.

I see two problems here:

1. Apparently OP's system opens files with encoding set to 'ascii' by default. This is not the case on any of the systems I have access to (OSX and Linux).  I will try to reproduce this issue by setting LANG="en_US.ascii".

2. Regrtest attempts to write a no-ascii character into the trace results file.  I suspect this comes from test cases that test import from modules with non-ascii name or with non-ascii identifiers.

I am not sure there is anything we need to change here other than possibly skip tests that use non-ascii identifiers of the systems with default encoding set to ascii.  I would be +0 on adding errors='replace' or 'backshlashreplace' to the open() call in  write_results_file(), but hardcoding encoding="utf-8" is definitely not the right thing to do.

----------
stage: patch review -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Fri Nov  5 19:26:51 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 05 Nov 2010 18:26:51 +0000
Subject: [issue10027] os.lstat/os.stat don't set st_nlink on Windows
In-Reply-To: <1286289327.29.0.159315245099.issue10027@psf.upfronthosting.co.za>
Message-ID: <1288981611.28.0.905574607941.issue10027@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Works for me. I think it should be ok to commit.

----------
assignee:  -> ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Fri Nov  5 19:43:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 18:43:10 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1288982590.85.0.299607092654.issue10329@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I would be +0 on adding errors='replace' or 'backshlashreplace' to the 
> open() call in  write_results_file(), but hardcoding encoding="utf-8"
> is definitely not the right thing to do.

Who are the consumers of the trace files? Is there a formal specification or is Python the primary consumer?
If the former, then follow the specification (and/or amend it ;-)).
If the latter, you have the right to be creative; then utf-8 with the sounds like a most reasonable choice (possibly with an error handler such as "ignore" or "replace" to avoid barfing on lone surrogates).

Relying on the default encoding is not really a good idea, though. This is good for quick scripts or in the rare cases where it is by definition the expected behaviour. But in more elaborate cases you certainly want to decide the encoding by yourself.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Fri Nov  5 20:00:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 19:00:21 +0000
Subject: [issue1346238] A constant folding optimization pass for the AST
Message-ID: <1288983621.29.0.0374928300006.issue1346238@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346238>
_______________________________________

From report at bugs.python.org  Fri Nov  5 20:16:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 19:16:59 +0000
Subject: [issue10282] IMPLEMENTATION token differently delt with in NNTP
	capability
In-Reply-To: <1288642567.32.0.7785411032.issue10282@psf.upfronthosting.co.za>
Message-ID: <1288984619.53.0.5998414391.issue10282@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the new attribute in r86213.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10282>
_______________________________________

From report at bugs.python.org  Fri Nov  5 20:29:59 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Nov 2010 19:29:59 +0000
Subject: [issue10232] Tkinter issues with Scrollbar and custom widget list
In-Reply-To: <1288366788.46.0.695886030233.issue10232@psf.upfronthosting.co.za>
Message-ID: <1288985399.89.0.443464093544.issue10232@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Robert, I interpret your response to Hirokazu to mean that his suggestion works. Hence I am following his suggestion. Reopen is I erred.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10232>
_______________________________________

From report at bugs.python.org  Fri Nov  5 20:31:05 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Fri, 05 Nov 2010 19:31:05 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288985465.03.0.605253390282.issue1926@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

Hi Steven,

I agree with what you suggest for the implementation.


> Is there a case where a server advertises STARTTLS
> and one would not use it?

Yes, the overhead added by the encryption.  It is what people usually mention for the reason not to use it.
However, the TLS protocol allows to negotiate compression; in this case, it is very powerful!  LIST ACTIVE answers are for instance a lot faster.  The same for OVER answers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Fri Nov  5 20:36:20 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Fri, 05 Nov 2010 19:36:20 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1288985780.77.0.0241832324337.issue1926@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

(Note that smtplib can give ideas for an implementation of AUTHINFO SASL with PLAIN, LOGIN and CRAM-MD5 mechanisms.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Fri Nov  5 20:40:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Nov 2010 19:40:15 +0000
Subject: [issue10317] Add TurtleShell to turtle
In-Reply-To: <1288977539.64.0.0956225774062.issue10317@psf.upfronthosting.co.za>
Message-ID: <AANLkTikwCOv2wQGgWSrZtdNRHZQ8rDoO6aUjs-hMbrMP@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 5, 2010 at 1:18 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> nosy: +eric.araujo

Raymond has already rejected and closed this request, so I am not
optimistic that anything will happen here.  (I also understand that he
feels rather strongly about this because he closed the issue in just 5
hours!)

Nevertheless, let me answer Raymond's arguments for historical records:

> It's better as a demo for cmd than as a useful utility for the turtle module.

While I agree that TurtleShell is an excellent demo for the cmd
module, I find ReST files a poor place for example code, especially
multipage code like TurtleShell.   We do not have a procedure for
testing code presented in ReST files and such code regularly goes out
of date unnoticed.

At a minimum, I would like to see TurtleShell code moved into its own
file under Doc/includes/ and embedded in Doc/library/cmd.rst  using

.. literalinclude:: ../includes/turtleshell.py

directive.  See datetime.py and tzinfo-examples.py as an example of
this approach.

Doing so will help users that want to study TurtleShell code by
running and editing to get a working .py file.  (Sphinx can actually
make it even easier by supplying and easily accessible download link
for literalincludes.)

This will still not solve the problem of untested code in the manual,
but I this is a more general issue.  See #10225, for example.

> Also, we want people using turtle to learn Python, not to bypass the language altogether.

I agree and I can clearly see this a slippery slope before someone
would want to expand TurtleShell into a full-featured Logo
interpreter.  As it stands, however, I don't see a problem in letting
users command the turtle without twisting their fingers to enter
superfluous commas and parentheses.  (Remember, the target audience
may not even have full command of the shift key yet.)  We can also
teach TurtleShell to save history as a python program which will help
them to learn python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10317>
_______________________________________

From report at bugs.python.org  Fri Nov  5 20:42:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Nov 2010 19:42:51 +0000
Subject: [issue10317] Add TurtleShell to turtle
In-Reply-To: <1288924856.05.0.699658333719.issue10317@psf.upfronthosting.co.za>
Message-ID: <1288986171.12.0.958540496854.issue10317@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +gregorlingl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10317>
_______________________________________

From report at bugs.python.org  Fri Nov  5 20:55:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 19:55:50 +0000
Subject: [issue10311] Signal handlers must preserve errno
In-Reply-To: <1288873098.65.0.47223283391.issue10311@psf.upfronthosting.co.za>
Message-ID: <1288986950.45.0.553359817056.issue10311@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, fixed in r86214 (3.x), r86215 (3.1) and r86216 (2.7). Thanks for the patch!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10311>
_______________________________________

From report at bugs.python.org  Fri Nov  5 21:21:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 20:21:19 +0000
Subject: [issue10330] trace module doesn't work without threads
In-Reply-To: <1288988479.33.0.578006700843.issue10330@psf.upfronthosting.co.za>
Message-ID: <1288988479.33.0.578006700843.issue10330@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The trace module doesn't work when threading is disabled ("./configure --without-threads"). The following patch fixes this:

diff -r 345827dcf409 Lib/trace.py
--- a/Lib/trace.py      Fri Nov 05 20:58:28 2010 +0100
+++ b/Lib/trace.py      Fri Nov 05 21:20:09 2010 +0100
@@ -53,7 +53,10 @@ import linecache
 import os
 import re
 import sys
-import threading
+try:
+    import threading
+except ImportError:
+    import dummy_threading as threading
 import time
 import token
 import tokenize

----------
assignee: belopolsky
components: Library (Lib)
messages: 120529
nosy: belopolsky, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: trace module doesn't work without threads
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10330>
_______________________________________

From report at bugs.python.org  Fri Nov  5 21:28:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Nov 2010 20:28:40 +0000
Subject: [issue4391] optparse: use proper gettext plurals forms
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1288988920.97.0.867989546833.issue4391@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Now that argparse has been included in the standard library to supersede optparse, I?m not sure there is still value in fixing this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Fri Nov  5 21:30:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Nov 2010 20:30:54 +0000
Subject: [issue1098749] Single-line option to pygettext.py
Message-ID: <1288989054.93.0.078723400296.issue1098749@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/issue1098749>
_______________________________________

From report at bugs.python.org  Fri Nov  5 21:32:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Nov 2010 20:32:52 +0000
Subject: [issue5404] Cross-compiling Python
In-Reply-To: <1235984629.04.0.168155698084.issue5404@psf.upfronthosting.co.za>
Message-ID: <1288989172.5.0.0001424011189.issue5404@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/issue5404>
_______________________________________

From report at bugs.python.org  Fri Nov  5 21:45:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Nov 2010 20:45:12 +0000
Subject: [issue1649329] Extract file-finding and language-handling code from
	gettext.find
Message-ID: <1288989912.18.0.475682097933.issue1649329@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Barry said in http://mail.python.org/pipermail/python-dev/2009-March/087847.html :

  The class-based API for gettext takes streams, so resource_stream()
  would work just fine.  I think i18n plugins for Python do not
  necessarily need to use the classic gettext API.

The title as I changed it some time ago is thus invalid, so I?m changing it again.  This is still a request for separating the language selection code from the file finding.  Anyone feel free to enter a better title, this one is not very clear.

My first vote was to try to fix the code without writing a VFS, but OTOH maybe a lightweight ABC with mixin methods and a concrete implementation of the full gettext logic may be clear and educational here.  Shannon, if you?re still getting those emails, what do you think?

----------
assignee: tarek -> 
title: Support for non-filesystem-based catalogs in gettext -> Extract file-finding and language-handling code from gettext.find

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1649329>
_______________________________________

From report at bugs.python.org  Fri Nov  5 21:46:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Nov 2010 20:46:36 +0000
Subject: [issue8409] gettext should honor $LOCPATH environment variable
In-Reply-To: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za>
Message-ID: <1288989996.4.0.00477095459057.issue8409@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Should this be closed as invalid?

----------
nosy: +eric.araujo, lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8409>
_______________________________________

From report at bugs.python.org  Fri Nov  5 21:48:43 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 05 Nov 2010 20:48:43 +0000
Subject: [issue8409] gettext should honor $LOCPATH environment variable
In-Reply-To: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za>
Message-ID: <1288990123.93.0.126632502184.issue8409@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm not an expert on this, but I think it's still valid.  Maybe Martin has an opinion on it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8409>
_______________________________________

From report at bugs.python.org  Fri Nov  5 21:49:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Nov 2010 20:49:04 +0000
Subject: [issue2931] optparse: various problems with unicode and gettext
In-Reply-To: <1211297479.44.0.970954846769.issue2931@psf.upfronthosting.co.za>
Message-ID: <1288990144.96.0.955732765006.issue2931@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It would be nice to test argparse for the same behavior.

----------
nosy: +bethard, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2931>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:08:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Nov 2010 21:08:08 +0000
Subject: [issue10245] Fix resource warnings in test_telnetlib
In-Reply-To: <1288441077.58.0.74967624488.issue10245@psf.upfronthosting.co.za>
Message-ID: <1288991288.78.0.994426247573.issue10245@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/issue10245>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:08:32 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Nov 2010 21:08:32 +0000
Subject: [issue10245] Fix resource warnings in test_telnetlib
In-Reply-To: <1288441077.58.0.74967624488.issue10245@psf.upfronthosting.co.za>
Message-ID: <1288991312.15.0.941960599522.issue10245@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10245>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:10:00 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 05 Nov 2010 21:10:00 +0000
Subject: [issue10328] re.sub[n] doesn't seem to handle /Z replacements
	correctly in all cases
In-Reply-To: <1288967628.79.0.550964963089.issue10328@psf.upfronthosting.co.za>
Message-ID: <1288991400.41.0.385249765988.issue10328@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

It's a bug caused by trying to avoid getting stuck when a zero-width match is found. Basically the fix is to advance one character after a zero-width match, but that doesn't always give the correct result.

There are a number of related issues like issue #1647489 ("zero-length match confuses re.finditer()").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10328>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:16:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 21:16:15 +0000
Subject: [issue10180] File objects should not pickleable
In-Reply-To: <1287854367.84.0.526587779087.issue10180@psf.upfronthosting.co.za>
Message-ID: <1288991775.67.0.187101168057.issue10180@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r86220. I won't backport it since it would risk breaking existing code, although relying on this is really a bug in itself.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10180>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:20:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 05 Nov 2010 21:20:01 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1288992001.4.0.769148183501.issue7434@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/issue7434>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:23:30 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Nov 2010 21:23:30 +0000
Subject: [issue10270] Fix resource warnings in test_threading
In-Reply-To: <1288549842.1.0.819549161722.issue10270@psf.upfronthosting.co.za>
Message-ID: <1288992210.39.0.558891444803.issue10270@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
stage:  -> commit review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10270>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:30:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 21:30:26 +0000
Subject: [issue10331] test_gdb failure when warnings printed out
In-Reply-To: <1288992626.81.0.692321873477.issue10331@psf.upfronthosting.co.za>
Message-ID: <1288992626.81.0.692321873477.issue10331@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

There is this kind of failures on Barry's new buildbot. It looks like warning messages should be ignored when checking gdb output:


======================================================================
FAIL: test_NULL_ob_type (test.test_gdb.PrettyPrintTests)
Ensure that a PyObject* with NULL ob_type is handled gracefully
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-ppc/build/Lib/test/test_gdb.py", line 390, in test_NULL_ob_type
    'set v->ob_type=0')
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-ppc/build/Lib/test/test_gdb.py", line 361, in assertSane
    cmds_after_breakpoint=cmds_after_breakpoint)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-ppc/build/Lib/test/test_gdb.py", line 150, in get_gdb_repr
    import_site=import_site)
  File "/var/lib/buildbot/buildarea/3.x.warsaw-ubuntu-ppc/build/Lib/test/test_gdb.py", line 132, in get_stack_trace
    self.assertEquals(err, '')
AssertionError: '\nwarning: not using untrusted file "/home/barry/.gdbinit"\n' != ''
- 
- warning: not using untrusted file "/home/barry/.gdbinit"


See http://www.python.org/dev/buildbot/builders/PPC%20Ubuntu%203.x/builds/0/steps/test/logs/stdio

----------
assignee: dmalcolm
components: Tests
messages: 120537
nosy: barry, dmalcolm, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_gdb failure when warnings printed out
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10331>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:41:54 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 05 Nov 2010 21:41:54 +0000
Subject: [issue10331] test_gdb failure when warnings printed out
In-Reply-To: <1288992626.81.0.692321873477.issue10331@psf.upfronthosting.co.za>
Message-ID: <1288993314.3.0.280527573377.issue10331@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Seems to relate to this gdb feature:
http://sourceware.org/ml/gdb-patches/2005-05/msg00637.html

Barry: is your ~/.gdbinit world writable?

I can cook up a patch to ignore such warnings

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10331>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:48:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Nov 2010 21:48:25 +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: <1288993705.43.0.64342455247.issue10299@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

+1 from me on a table at the top of the functions page.
I am assuming that the markup will induce hotlinks.
The main problem I see is the need to hand rewrite when another function is added

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:53:46 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 05 Nov 2010 21:53:46 +0000
Subject: [issue10331] test_gdb failure when warnings printed out
In-Reply-To: <1288992626.81.0.692321873477.issue10331@psf.upfronthosting.co.za>
Message-ID: <1288994026.85.0.247709265545.issue10331@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Alternatively, it looks like having it owned by another user would do this.

For curiosity's sake, what's the output of:
  ls -al /home/barry/.gdbinit
on that buildbot?

Given that it's a security warning, should this simply be treated as misconfiguration, and be fixed on the buildbot?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10331>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:55:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 05 Nov 2010 21:55:48 +0000
Subject: [issue1346238] A constant folding optimization pass for the AST
Message-ID: <1288994148.33.0.0286429364653.issue1346238@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

David, it would be great if an optional AST optimization pass could do something that we don't already have (perhaps, loop invariant code motion when python is called with -OO or somesuch).  The AST tree makes it possible for the first time to provide some non-trivial optimizations, so aim high.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346238>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:56:23 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 05 Nov 2010 21:56:23 +0000
Subject: [issue10331] test_gdb failure when warnings printed out
In-Reply-To: <1288992626.81.0.692321873477.issue10331@psf.upfronthosting.co.za>
Message-ID: <1288994183.69.0.820060538304.issue10331@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

It is a misconfiguration.  I started my new buildbot with my environment active.  I've since killed that and restarted it with a clean ~buildbot environment.  So we shouldn't see this in my buildbots any more.

(FWIW, ~/.gdbinit is 644)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10331>
_______________________________________

From report at bugs.python.org  Fri Nov  5 22:59:43 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 05 Nov 2010 21:59:43 +0000
Subject: [issue10300] Documentation of three PyDict_* functions
In-Reply-To: <1288853283.95.0.565693563934.issue10300@psf.upfronthosting.co.za>
Message-ID: <AANLkTinASMxLOkNW1+7ZbkdPpFWLR5NGA-k+iHW+6Nhf@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

This is fixed now.

2010/11/4 Hagen F?rstenau <report at bugs.python.org>:
>
> Hagen F?rstenau <hagen at zhuliguan.net> added the comment:
>
> The ReST links in http://docs.python.org/py3k/c-api/dict.html#PyDict_Items seem to be broken.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10300>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10300>
_______________________________________

From report at bugs.python.org  Fri Nov  5 23:05:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 22:05:50 +0000
Subject: [issue10321] Add support for Message objects and binary data to
	smtplib.sendmail
In-Reply-To: <1288948061.88.0.822892450886.issue10321@psf.upfronthosting.co.za>
Message-ID: <1288994750.64.0.927161504573.issue10321@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

New patch that takes a middle ground on the API: sendmail accepts string and bytes, and a new method send_message accepts a Message object with a more convenient signature.  I think send_message does belong in smtplib since it would be awkward and unintuitive to put the helper function in email, since one needs to create an SMTP server to call sendmail.  

I am satisfied with this version; the delta against the existing code and docs is smaller and the API feels clean.

The new patch also updates a couple of the email package examples that use sendmail to use send_message (one of the sendmail examples is left untouched).

If there are no objections I'll commit this this weekend sometime.

----------
Added file: http://bugs.python.org/file19507/sendmail_message_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10321>
_______________________________________

From report at bugs.python.org  Fri Nov  5 23:13:42 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Nov 2010 22:13:42 +0000
Subject: [issue10303] small inconsistency in tutorial
In-Reply-To: <1288830081.73.0.485204964128.issue10303@psf.upfronthosting.co.za>
Message-ID: <1288995222.61.0.315663210388.issue10303@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The sentence should be deleted. Print is *not* used in any of the previous examples. This is the first mention of print() in the chapter and is nonsensical in context.

----------
keywords: +easy
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10303>
_______________________________________

From report at bugs.python.org  Fri Nov  5 23:20:47 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 05 Nov 2010 22:20:47 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1288995647.92.0.32062081694.issue10318@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I agree with Eric's comment about why have shebang lines at all for files in the standard library.  There isn't any use case or recommendation for ever putting /path/to/lib/pythonx.x or its subdirectories directly on a shell search path is there?

WRT the three files found in the Mac directory, I think all of these should be left alone for right now.  Specifically:

Mac/BuildScript/build-installer.py
   is the script used to build OS X installer images; at the moment, it depends on a system Python 2 as a build tool, primarily because of Sphinx, and there has been an effort to keep the Python 2 and Python 3 versions of the script in sync.  Eventually that will need to be changed.  The shebang line could simply be removed.

Mac/Tools/fixapplepython23.py:
    this one needs to be looked at a bit more as it runs during the installation process but only on OS X 10.3, a minor and dwindling niche of the user base.  I think that it actually depends on the Apple-installed system Python at run time.  I'll follow up on it.

Mac/Tools/bundlebuilder.py: #! /usr/bin/env python
    AFAIK, bundlebuilder is neither used during the build process of Python 3 nor is it installed.  It is used in the Python 2 build process.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Fri Nov  5 23:22:32 2010
From: report at bugs.python.org (James Hutchison)
Date: Fri, 05 Nov 2010 22:22:32 +0000
Subject: [issue10332] Multiprocessing maxtasksperchild results in hang
In-Reply-To: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>
Message-ID: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

v.3.2a3

If the maxtasksperchild argument is used, the program will just hang after whatever that value is rather than working as expected. Tested in Windows XP 32-bit

test code:

import multiprocessing

def f(x):
    return 0;

if __name__ == '__main__':
    pool = multiprocessing.Pool(processes=2,maxtasksperchild=1);
    results = list();
    for i in range(10):
        results.append(pool.apply_async(f, (i)));
    pool.close();
    pool.join();
    for r in results:
        print(r);
    print("Done");

----------
components: Library (Lib)
messages: 120547
nosy: Jimbofbx
priority: normal
severity: normal
status: open
title: Multiprocessing maxtasksperchild results in hang
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10332>
_______________________________________

From report at bugs.python.org  Fri Nov  5 23:24:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 22:24:31 +0000
Subject: [issue10332] Multiprocessing maxtasksperchild results in hang
In-Reply-To: <1288995752.47.0.110889938296.issue10332@psf.upfronthosting.co.za>
Message-ID: <1288995871.28.0.184794385624.issue10332@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +asksol, jnoller
type:  -> behavior
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10332>
_______________________________________

From report at bugs.python.org  Fri Nov  5 23:28:57 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Nov 2010 22:28:57 +0000
Subject: [issue10304] error in tutorial triple-string example
In-Reply-To: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>
Message-ID: <1288996137.4.0.0926914706198.issue10304@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

1. Rather than add a blank line to the output, the input should have the newline suppressed with \ (which has been done in previous examples).
  print("""\

2. It is rather difficult to see that there is no blank at the end (highlight with mouse). I can imagine that either the formatter or display system might delete even if in the master .rst file. In interactive use, the interpreter will go to a new line anyway before printing the >>> prompt.

The intent and effect of end=' ' is that the outputs are all on one line (as with 2.x print) instead of each on a separate line

----------
nosy: +terry.reedy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10304>
_______________________________________

From report at bugs.python.org  Fri Nov  5 23:29:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Nov 2010 22:29:12 +0000
Subject: [issue10304] error in tutorial triple-string example
In-Reply-To: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>
Message-ID: <1288996152.59.0.550201248754.issue10304@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10304>
_______________________________________

From report at bugs.python.org  Fri Nov  5 23:33:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 22:33:55 +0000
Subject: [issue10321] Add support for Message objects and binary data to
	smtplib.sendmail
In-Reply-To: <1288948061.88.0.822892450886.issue10321@psf.upfronthosting.co.za>
Message-ID: <1288996435.98.0.511581338422.issue10321@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

One more patch update.  This one includes the versionadded/version changed and a minimal What's New entry.

----------
Added file: http://bugs.python.org/file19508/sendmail_message_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10321>
_______________________________________

From report at bugs.python.org  Fri Nov  5 23:37:20 2010
From: report at bugs.python.org (Malte Helmert)
Date: Fri, 05 Nov 2010 22:37:20 +0000
Subject: [issue10304] error in tutorial triple-string example
In-Reply-To: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>
Message-ID: <1288996640.4.0.934027495891.issue10304@psf.upfronthosting.co.za>


Malte Helmert <helmert at informatik.uni-freiburg.de> added the comment:

> 1. Rather than add a blank line to the output, the input should have
> the newline suppressed with \ (which has been done in previous
> examples).
> print("""\

I think that would be didactically bad after just mentioning that newlines in triple-quoted strings don't have to be escaped etc.
I think this would confuse the reader.

Better use print("""Usage...


> In interactive use, the interpreter will go to a new line anyway
> before printing the >>> prompt.

It won't (at least in Python 3.1). I just tried it.

> The intent and effect of end=' ' is that the outputs are all on one
> line (as with 2.x print) instead of each on a separate line

Sure. But I think that in an example that is essentially about whitespace produced by print, the actual whitespace in the output should match the actual behaviour of print. One why to get rid of this problem altogether is to add a 'print "done!"' or whatever at the end, or use a different separator from " ".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10304>
_______________________________________

From report at bugs.python.org  Fri Nov  5 23:57:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Nov 2010 22:57:08 +0000
Subject: [issue10324] Modules/binascii.c: simplify expressions
In-Reply-To: <1288960282.63.0.36896617849.issue10324@psf.upfronthosting.co.za>
Message-ID: <1288997828.26.0.772250092288.issue10324@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As near as I can tell, since && and || are logical rather than bitwise, and since the variable reference 'quotetabs' has no side effect, you are correct. Have you run the unittest on a patched build?

----------
nosy: +terry.reedy
stage:  -> commit review
type: feature request -> performance
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10324>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:00:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 05 Nov 2010 23:00:52 +0000
Subject: [issue10328] re.sub[n] doesn't seem to handle /Z replacements
	correctly in all cases
In-Reply-To: <1288967628.79.0.550964963089.issue10328@psf.upfronthosting.co.za>
Message-ID: <1288998052.45.0.848140393957.issue10328@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10328>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:01:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 05 Nov 2010 23:01:31 +0000
Subject: [issue10304] error in tutorial triple-string example
In-Reply-To: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>
Message-ID: <1288998091.81.0.834405612339.issue10304@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think the commit hook might object to the trailing blank (I'm not sure it applies to rst files, but I think it does).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10304>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:02:46 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 05 Nov 2010 23:02:46 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1288998166.54.0.261982647397.issue10241@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

The attached patch seems better.  The copies of module dicts stored in the interpreter state are dereferenced when the interpreter shuts down.

----------
Added file: http://bugs.python.org/file19509/module_m_copy2.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10241>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:05:41 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Fri, 05 Nov 2010 23:05:41 +0000
Subject: [issue10333] Remove ancient backwards compatibility GC API
In-Reply-To: <1288998341.4.0.536091524037.issue10333@psf.upfronthosting.co.za>
Message-ID: <1288998341.4.0.536091524037.issue10333@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

I think it should be safe to remove some backwards compatibility cruft.  This was introduced during the 2.3 development cycle.

----------
files: gc_cruft.txt
messages: 120554
nosy: nascheme
priority: low
severity: normal
status: open
title: Remove ancient backwards compatibility GC API
Added file: http://bugs.python.org/file19510/gc_cruft.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10333>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:06:38 2010
From: report at bugs.python.org (Philippe Devalkeneer)
Date: Fri, 05 Nov 2010 23:06:38 +0000
Subject: [issue8033] sqlite: broken long integer handling for arguments to
	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1288998398.42.0.559760706893.issue8033@psf.upfronthosting.co.za>


Philippe Devalkeneer <phil.le.bienheureux at gmail.com> added the comment:

Hello,
Here is a patch to fix it :) 
( and don't blame me too much if something is not correct, it's the first patch I submit :) )

Philippe

----------
keywords: +patch
nosy: +flupke
Added file: http://bugs.python.org/file19511/broken_long_int_sqlite_functions.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:08:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Nov 2010 23:08:13 +0000
Subject: [issue10330] trace module doesn't work without threads
In-Reply-To: <1288988479.33.0.578006700843.issue10330@psf.upfronthosting.co.za>
Message-ID: <1288998493.67.0.538108766398.issue10330@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I wish I could test this patch but on OSX I get

$ ./configure --without-threads
$ make
Traceback (most recent call last):
  File "/Users/sasha/Work/python-svn/py3k/Lib/site.py", line 519, in <module>
    main()
  File "/Users/sasha/Work/python-svn/py3k/Lib/site.py", line 507, in main
    known_paths = addusersitepackages(known_paths)
  File "/Users/sasha/Work/python-svn/py3k/Lib/site.py", line 253, in addusersitepackages
    user_site = getusersitepackages()
  File "/Users/sasha/Work/python-svn/py3k/Lib/site.py", line 228, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/Users/sasha/Work/python-svn/py3k/Lib/site.py", line 218, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/Users/sasha/Work/python-svn/py3k/Lib/sysconfig.py", line 580, in get_config_var
    return get_config_vars().get(name)
  File "/Users/sasha/Work/python-svn/py3k/Lib/sysconfig.py", line 458, in get_config_vars
    import re
  File "/Users/sasha/Work/python-svn/py3k/Lib/re.py", line 121, in <module>
    import functools
  File "/Users/sasha/Work/python-svn/py3k/Lib/functools.py", line 15, in <module>
    from collections import OrderedDict
  File "/Users/sasha/Work/python-svn/py3k/Lib/collections.py", line 16, in <module>
    from reprlib import recursive_repr as _recursive_repr
  File "/Users/sasha/Work/python-svn/py3k/Lib/reprlib.py", line 8, in <module>
    from _thread import get_ident
ImportError: No module named _thread

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10330>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:12:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 23:12:59 +0000
Subject: [issue10333] Remove ancient backwards compatibility GC API
In-Reply-To: <1288998341.4.0.536091524037.issue10333@psf.upfronthosting.co.za>
Message-ID: <1288998779.13.0.849786326158.issue10333@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Looks good to me. I suppose everything builds fine?

----------
components: +Extension Modules, Interpreter Core
nosy: +pitrou
stage:  -> commit review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10333>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:21:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 05 Nov 2010 23:21:49 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1288999309.59.0.556108054178.issue10197@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

() is used to launch a command in a sub-shell and {} is used to group commands, for example to set up a stream redirection for all commands in brackets.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:32:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 05 Nov 2010 23:32:05 +0000
Subject: [issue10330] trace module doesn't work without threads
In-Reply-To: <1288988479.33.0.578006700843.issue10330@psf.upfronthosting.co.za>
Message-ID: <1288999925.58.0.502533740976.issue10330@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

dummy_threading feels a bit like black magic to me.  What do you think about something like issue10330.diff attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file19512/issue10330.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10330>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:35:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 05 Nov 2010 23:35:23 +0000
Subject: [issue10330] trace module doesn't work without threads
In-Reply-To: <1288999925.58.0.502533740976.issue10330@psf.upfronthosting.co.za>
Message-ID: <1289000116.3563.20.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> dummy_threading feels a bit like black magic to me.  What do you think
> about something like issue10330.diff attached.

It's fine for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10330>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:59:09 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 05 Nov 2010 23:59:09 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1289001549.87.0.389268475185.issue10252@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Is it really true that 3.x's distutils is source compatible with 2.3?

For 3.x I'd like to see the with statement used.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Sat Nov  6 00:59:54 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 05 Nov 2010 23:59:54 +0000
Subject: [issue1346238] A constant folding optimization pass for the AST
Message-ID: <1289001594.62.0.713384511884.issue1346238@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I've been working on this against the py3k branch.  I'm attaching what I've got so far.

I foolishly didn't check the tlee-ast-optimize branch, instead using file6850 as a base.

Rune Holm/titanstar, I assume you've signed a PSF contributor agreement?

Changes since titanstar's original patch:
  - rework to apply against py3k
  - reformatted tabs to 4-space indentation; tried to reformat to PEP-7 as much as possible
  - added stmt types: With_kind, Nonlocal_kind
  - added expr types: IfExp_kind, Bytes_kind, SetComp_kind, DictComp_kind, Ellipsis_Kind
  - removed Print_kind, Exec_kind, Repr_kind
  - reworked Raise_kind
  - added "col_offset" and "arena" arguments; pass in the PyArena from the compiler as the context of the visitor
  - removal of all "free_expr" and "asdl_seq_free" calls on the assumption that PyArena now handles all of this (am I correct in thinking this?)
  - String -> Bytes in create_ast_from_constant_object
  - added test_optimize selftest suite, though this is based on bytecode disassembly, rather than direct inspection of the AST
  - I've fixed it up so it compiles and passes regrtest, but I suspect I've missed optimization possibilities

I did a little performance testing using the py3k version of the benchmark suite; currently it's a slight regression for some tests, a slight improvement for others; nothing impressive yet.

Thomas Lee's AST optimization branch (branched from r62457) has lots of interesting work:
  e.g. http://svn.python.org/view/python/branches/tlee-ast-optimize/Python/optimize.c?view=log

This appears to not be quite the same starting point; he added a PyCF_NO_OPTIMIZE flag to Include/pythonrun.h (and other places), which seems like a good way to see the effect of the optimization pass.  He also removed the peepholer; maybe it's worth doing that, but it seems worth at least keeping the test suite around to ensure a lack of regressions.

I can look at cherrypicking Thomas' work/porting it to py3k.

Re: "aiming high": I'd love to add new optimizations, but it's not clear to me what's permissable.  In particular, is it permissable for an optimization pass to assume that there are no external modifications to the locals within a frame?

It's possible to write code like this:
    frame = inspect.currentframe()
    inspect.getouterframes(frame)[-depth][0].f_locals[name] = value
to manipulate locals; whether or not this actually affects running code in the current implementation of CPython seems hit-or-miss to me right now, I think depending on exactly when fastlocals get written back to the f_locals dictionary (I could have miswritten the precise code).

By strategically manipulating locals in other frames, we can break pretty-much any typical compiler optimization: locals can appear or change from under us, or change attribute values, or gain side-effects to their __getattr__ (e.g. writing to disk).

If it is permissable for an optimization pass to assume that there are no external modifications to the locals within a frame, then issue 4264 might be one to investigate: this is a patch on top of Tom Lee's work (to do local type-inference to replace list.append with LIST_APPEND).   Ideas for other optimizations would be most welcome.

----------
Added file: http://bugs.python.org/file19513/py3k-ast-optimization-2010-11-05-001.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346238>
_______________________________________

From report at bugs.python.org  Sat Nov  6 01:10:15 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 06 Nov 2010 00:10:15 +0000
Subject: [issue1346238] A constant folding optimization pass for the AST
Message-ID: <1289002215.12.0.462304330739.issue1346238@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Another optimization idea: detect local dictionaries that are only ever used in non-mutating ways, and convert them to constants, rather than rebuilding the dict from scratch each time.

See e.g. htmlparser.py:adjustSVGAttributes etc within the bm_html5lib benchmark (though this doesn't seem to be ported to py3k yet)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346238>
_______________________________________

From report at bugs.python.org  Sat Nov  6 01:27:25 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 06 Nov 2010 00:27:25 +0000
Subject: [issue10302] Add class-functions to hash many small objects with
	hashlib
In-Reply-To: <1288824257.88.0.548360154902.issue10302@psf.upfronthosting.co.za>
Message-ID: <1289003245.66.0.653378763929.issue10302@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This is an application specific optimization that I'd like to see as its own library or a feature added to NSS or OpenSSL. Regardless if you want this for python, write an extension module and put it on pypy before aiming for the stdlib.  I understand the optimization potential but it is a bit obscure.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10302>
_______________________________________

From report at bugs.python.org  Sat Nov  6 01:30:37 2010
From: report at bugs.python.org (Nicolas Kaiser)
Date: Sat, 06 Nov 2010 00:30:37 +0000
Subject: [issue10324] Modules/binascii.c: simplify expressions
In-Reply-To: <1288960282.63.0.36896617849.issue10324@psf.upfronthosting.co.za>
Message-ID: <1289003437.57.0.658971963554.issue10324@psf.upfronthosting.co.za>


Nicolas Kaiser <nikai at nikai.net> added the comment:

That's ./Lib/test/test_unittest.py?

With patched builds of Python 2.6.5 and 3.1.2:

----------------------------------------------------------------------
Ran 126 tests in 0.015s

OK

----------------------------------------------------------------------
Ran 187 tests in 0.054s

OK

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10324>
_______________________________________

From report at bugs.python.org  Sat Nov  6 01:40:21 2010
From: report at bugs.python.org (Santoso Wijaya)
Date: Sat, 06 Nov 2010 00:40:21 +0000
Subject: [issue8033] sqlite: broken long integer handling for arguments to
	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1289004021.58.0.591676543402.issue8033@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santa.ant at me.com>:


----------
nosy: +santa4nt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Sat Nov  6 02:02:53 2010
From: report at bugs.python.org (Alex)
Date: Sat, 06 Nov 2010 01:02:53 +0000
Subject: [issue1346238] A constant folding optimization pass for the AST
Message-ID: <1289005373.84.0.252680867012.issue1346238@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

ISTM that you don't need to worry about mutating locals, the locals() function is explicitly documented as not necessarily affecting local variables (not sure if frame objects have the same documentation).

If you want a free optimization opportunity: BINARY_SUBSCR with a list for the first argument who's contents are all constant, this can be optimized to turn it into a tuple which can be load const'd (as we do in the case of an in check), note that this cannot be used in the case of::

    l = [1, 2, 3]
    l[v]

As v.__index__ could theoretically mutate l.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346238>
_______________________________________

From report at bugs.python.org  Sat Nov  6 02:11:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 01:11:12 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1289005872.32.0.291083969086.issue10252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed in the py3k branch in r86223, r86224 and r86226.  Thanks for the report and starting patch.

Eric: This compatibility policy was instated because a newer version of distutils may be used/is often used to install distributions for older Pythons.  In the 2.x line, this was enforced.  I checked the current py3k code with the oldest version I have, 2.4, and it?s not entirely compatible.  Python 3.x is developed as a clean break from 2.x (no versionchanged directives in docs,?etc.), so what?s the status of the distutils compatibility policy?  I think that the reasons are still valid, so keeping 2.x source compat in py3k is a nice thing to do for our users.  Even if we?re working on distutils2 (which will have releases for 2.4-3.2), distutils is still widely used and we expect a long transition period.

I can bring this up on python-dev if you think it?s needed.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Sat Nov  6 02:18:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 06 Nov 2010 01:18:33 +0000
Subject: [issue10330] trace module doesn't work without threads
In-Reply-To: <1288988479.33.0.578006700843.issue10330@psf.upfronthosting.co.za>
Message-ID: <1289006313.99.0.441470123186.issue10330@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I'll commit tonight.  BTW, on a without-threads build:


>>> import dummy_threading
>>> dummy_threading.settrace
>>> dummy_threading.settrace.__module__
'threading'

In other words, dummy_threading.settrace is always the same as threading.settrace. Since threading.settrace just sets a global variable which is probably not used by dummy_threading, OP's patch is probably fine, but may not be as future proof.

----------
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10330>
_______________________________________

From report at bugs.python.org  Sat Nov  6 02:39:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 01:39:23 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1289007563.39.0.309664894158.issue10252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(Not closing yet: Some calls of os.popen and subprocess.Popen are still to be fixed, and then there?s the backport.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Sat Nov  6 02:39:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 06 Nov 2010 01:39:43 +0000
Subject: [issue10330] trace module doesn't work without threads
In-Reply-To: <1288988479.33.0.578006700843.issue10330@psf.upfronthosting.co.za>
Message-ID: <1289007583.52.0.481732356024.issue10330@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r86229, merged in r86231 (3.1) and r86233 (2.7).

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10330>
_______________________________________

From report at bugs.python.org  Sat Nov  6 03:22:51 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 06 Nov 2010 02:22:51 +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: <1289010171.3.0.24257538874.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101106.zip is a new version of the regex module.

Fix for issue 10328, which regex also shared.

----------
Added file: http://bugs.python.org/file19514/issue2636-20101106.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Nov  6 03:55:06 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Nov 2010 02:55:06 +0000
Subject: [issue10304] error in tutorial triple-string example
In-Reply-To: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>
Message-ID: <1289012106.84.0.224800246626.issue10304@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I should have said that IDLE puts >>> on a new line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10304>
_______________________________________

From report at bugs.python.org  Sat Nov  6 03:56:59 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 06 Nov 2010 02:56:59 +0000
Subject: [issue10324] Modules/binascii.c: simplify expressions
In-Reply-To: <1288960282.63.0.36896617849.issue10324@psf.upfronthosting.co.za>
Message-ID: <1289012219.51.0.751446781166.issue10324@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

test_binascii.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10324>
_______________________________________

From report at bugs.python.org  Sat Nov  6 04:03:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 06 Nov 2010 03:03:09 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288982590.85.0.299607092654.issue10329@psf.upfronthosting.co.za>
Message-ID: <AANLkTim0uAV2bctthcgAJwrv8o=weaBLma_b-JyQTmzq@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 5, 2010 at 2:43 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
> Who are the consumers of the trace files? Is there a formal specification
> or is Python the primary consumer?

The trace files contain annotated python source code.  There is no
formal specification that I am aware of as these files are intended
for human consumption.

..
> Relying on the default encoding is not really a good idea, though. This is good for quick scripts or
> in the rare cases where it is by definition the expected behaviour. But in more elaborate cases you
> certainly want to decide the encoding by yourself.

I agree and the correct encoding seems to be the encoding of the
original source file that trace annotates.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Sat Nov  6 04:21:59 2010
From: report at bugs.python.org (Mark Roddy)
Date: Sat, 06 Nov 2010 03:21:59 +0000
Subject: [issue10326] Can't pickle unittest.TestCase instances
In-Reply-To: <1288966649.03.0.6620170389.issue10326@psf.upfronthosting.co.za>
Message-ID: <1289013719.02.0.139854800994.issue10326@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

Patch which makes TestCase pickle-able for Python 2.7, includes unit test

----------
keywords: +patch
nosy: +MarkRoddy
Added file: http://bugs.python.org/file19515/python27.pickle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10326>
_______________________________________

From report at bugs.python.org  Sat Nov  6 04:22:53 2010
From: report at bugs.python.org (Mark Roddy)
Date: Sat, 06 Nov 2010 03:22:53 +0000
Subject: [issue10326] Can't pickle unittest.TestCase instances
In-Reply-To: <1288966649.03.0.6620170389.issue10326@psf.upfronthosting.co.za>
Message-ID: <1289013773.45.0.549808729128.issue10326@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

Attaching patch which makes TestCase pickle-able for Python 3.2, includes unit test

----------
Added file: http://bugs.python.org/file19516/python3k.pickle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10326>
_______________________________________

From report at bugs.python.org  Sat Nov  6 04:56:16 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 06 Nov 2010 03:56:16 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1289015776.02.0.876047336546.issue5412@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Code
====

- The __name__-aversion in the mapping interface is a little
  heavy-handed, but given the implementation of __name__ elsewhere, I
  think this can be revisited separately if anyone cares enough.

  In particular, it should be allowed to give an __name__ value
  explicitly and have it exposed:

      >>> import configparser
      >>> import io

      >>> cp = configparser.RawConfigParser()
      >>> cp.read_file(io.StringIO('[sect]\n__name__ = FooBar\n'))

      >>> cp.get('sect', '__name__')
      'FooBar'

      >>> cp['sect']['__name__']
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
        File ".../py3k/Lib/configparser.py", line 1132, in __getitem__
          raise ValueError(self._noname)
      ValueError: __name__ special key access and modification not supported through the mapping interface.

  In this example, the __name__ key isn't special, it's just a key.

Documentation
=============

- I dislike the 'fallback'/'default' terminology problem; everywhere
  else, the fallback is called 'default'.  This really points to
  configparser (ne ConfigParser) not having been fully thought out
  before it was released as part of Python.  There's probably nothing
  to be done about it at this point.

  Has anyone attempted to determine how widely used the "defaults"
  (mis-)feature is?  I've not seen a good user for it as implemented
  outside the original application ConfigParser was written for
  (though others probably exist that have a similar need).

- There's no value in saying

      `None` can be provided as a `fallback` value.

  (regardless of the terminology).  None is a value like any other, and
  the docs already indicate it is used if provided.  If anything need be
  said, identify the exception raised if the default isn't provided and
  no value is present.

  Identifying None as a possible value isn't needed or done in any of
  the mapping descriptions, so let's not add it here, even for the
  methods that don't correlate to mapping methods.

- I dislike the documentation style where we indicate arguments are
  keyword-only using a bare * in the signature, and then repeat that in
  prose (this is not the only place this happens).  It's redundant
  (more work to maintain) and more verbose than helpful.

I still need to give the new docs a thorough read.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Sat Nov  6 05:07:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 04:07:41 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1289016461.71.0.900060157169.issue10252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

[Pp]open objects closed in r86234.

All fixes ported to 3.1 in r86237, 2.7 in r86238.  Cheers!

----------
resolution:  -> fixed
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/issue10252>
_______________________________________

From report at bugs.python.org  Sat Nov  6 05:10:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 06 Nov 2010 04:10:00 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1289016600.21.0.75147972422.issue10329@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch, issue10329.diff fixes the issue by setting the encoding of the coverage file to that of the source file.  I am not 100% happy with this patch for the following reasons:

1. It opens the source file one more time.  This is probably acceptable because existing code already opens it at least four times when -m (show missing) option is selected.  (Twice in find_executable_linenos() and twice in linecache.getlines().  Fixing that would require refactoring of linecache code.

2. This will not work for source code not stored in a file, but provided by a __loader__.get_source() method.  However it looks like trace will not work at all in this case, so fixing that is a separate issue.

----------
assignee:  -> belopolsky
keywords: +needs review
Added file: http://bugs.python.org/file19517/issue10329.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Sat Nov  6 05:13:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 04:13:40 +0000
Subject: [issue10229] Refleak run of test_gettext fails
In-Reply-To: <1288348294.62.0.0907397506052.issue10229@psf.upfronthosting.co.za>
Message-ID: <1289016820.0.0.331437126365.issue10229@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed in r86239.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10229>
_______________________________________

From report at bugs.python.org  Sat Nov  6 05:38:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 04:38:14 +0000
Subject: [issue10229] Refleak run of test_gettext fails
In-Reply-To: <1288348294.62.0.0907397506052.issue10229@psf.upfronthosting.co.za>
Message-ID: <1289018294.28.0.857060987888.issue10229@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Added NEWS entry in r86241.  Fix (including NEWS entry) backported to 3.1 in r862442 and 2.7 in r86243.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10229>
_______________________________________

From report at bugs.python.org  Sat Nov  6 05:54:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 04:54:25 +0000
Subject: [issue9281] Race condition with mkdir/makedirs in distutils2
In-Reply-To: <1279342839.57.0.133468665449.issue9281@psf.upfronthosting.co.za>
Message-ID: <1289019265.96.0.550028339999.issue9281@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed in r86244 (py3k), r86245 (3.1), r86246 (2.7), thanks!

For distutils2, I?d like to commit a comprehensive fix.  Do you want to expand your patch to cover all instances of mkdir/makedirs?

----------
components:  -Distutils
status: pending -> open
title: Race condition in distutils.dir_util.mkpath() -> Race condition with mkdir/makedirs in distutils2
versions:  -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9281>
_______________________________________

From report at bugs.python.org  Sat Nov  6 06:26:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 05:26:39 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1289021199.82.0.287303754877.issue10273@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/issue10273>
_______________________________________

From report at bugs.python.org  Sat Nov  6 06:38:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 05:38:32 +0000
Subject: [issue10228] Refleak run of test_dbm fails when several dbm modules
	are available
In-Reply-To: <1288347112.92.0.717435942769.issue10228@psf.upfronthosting.co.za>
Message-ID: <1289021912.16.0.648646257475.issue10228@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A quick look makes me think the bug is in the test, not the code.

----------
nosy: +eric.araujo, giampaolo.rodola, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10228>
_______________________________________

From report at bugs.python.org  Sat Nov  6 07:13:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 06:13:42 +0000
Subject: [issue7908] remove leftover macos9 support code
In-Reply-To: <1265898907.53.0.125133680219.issue7908@psf.upfronthosting.co.za>
Message-ID: <1289024022.86.0.424998211824.issue7908@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, see also #9508.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7908>
_______________________________________

From report at bugs.python.org  Sat Nov  6 07:14:43 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 06 Nov 2010 06:14:43 +0000
Subject: [issue10205] Can't have two tags with the same QName
In-Reply-To: <1288122049.66.0.916624044666.issue10205@psf.upfronthosting.co.za>
Message-ID: <1289024083.39.0.646966802268.issue10205@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/issue10205>
_______________________________________

From report at bugs.python.org  Sat Nov  6 07:18:46 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 06 Nov 2010 06:18:46 +0000
Subject: [issue6269] threading documentation makes no mention of the GIL
In-Reply-To: <1244752636.53.0.230892071938.issue6269@psf.upfronthosting.co.za>
Message-ID: <1289024326.45.0.111706073951.issue6269@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/issue6269>
_______________________________________

From report at bugs.python.org  Sat Nov  6 07:19:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 06:19:49 +0000
Subject: [issue9508] python3.2 reversal of distutils reintrocud macos9 support
In-Reply-To: <1280927222.45.0.841645452377.issue9508@psf.upfronthosting.co.za>
Message-ID: <1289024389.4.0.727307029603.issue9508@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed in r86248, thanks.  BTW, my commit removes a bit more than yours originally did.

In 2.7, the unused distutils.sysconfig._init_mac function is still left over.  I don?t know if killing dead code is acceptable in a stable version.  Benjamin?

----------
assignee: tarek -> eric.araujo
nosy: +benjamin.peterson, eric.araujo
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9508>
_______________________________________

From report at bugs.python.org  Sat Nov  6 07:26:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 06:26:35 +0000
Subject: [issue3902] Packages containing only extension modules have to
	contain __init__.py
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1289024795.56.0.897218793915.issue3902@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Reclassifying as request for doc enhancement.  I?ll check the distutils2 doc and add a line about this problem if I find the text is not clear enough.

Someone finding this report thanks to the ?easy? keyword can feel free to propose a patch.

----------
components: +Distutils2, Documentation -Distutils
keywords: +easy
stage:  -> needs patch
title: distutils does not create __init__.py for packages containing extension modules -> Packages containing only extension modules have to contain __init__.py
versions: +3rd party -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Sat Nov  6 07:28:03 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Nov 2010 06:28:03 +0000
Subject: [issue10334] Add new reST directive for links to source code
In-Reply-To: <1289024882.94.0.454472669489.issue10334@psf.upfronthosting.co.za>
Message-ID: <1289024882.94.0.454472669489.issue10334@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

In a few cases where the pure python source code is a helpful adjunct to the documentation, I've added some links using the "seealso" directive:

  .. seealso::
  
     Latest version of the `ast module Python source code
     <http://svn.python.org/view/python/branches/release27-maint/Lib/ast.py?view=markup>`_


It would be great if a new directive could be introduced for this purpose.  Something like:

.. sourcecode Lib/ast.py


With a directive, we could easily point the root directory to different releases or to a local source directory for local doc build.

----------
assignee: georg.brandl
components: Documentation
messages: 120587
nosy: georg.brandl, rhettinger
priority: low
severity: normal
status: open
title: Add new reST directive for links to source code
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10334>
_______________________________________

From report at bugs.python.org  Sat Nov  6 07:42:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 06:42:24 +0000
Subject: [issue4931] distutils does not show any error msg when can't build C
	module extensions due to a missing C compiler
In-Reply-To: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>
Message-ID: <1289025744.75.0.647076549215.issue4931@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Giampaolo, can you test Amaury?s patch?  I?d prefer some testing before committing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4931>
_______________________________________

From report at bugs.python.org  Sat Nov  6 07:45:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 06:45: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: <1289025938.05.0.149752547832.issue9709@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I can review a patch for this bug but not write it, lacking knowledge in C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9709>
_______________________________________

From report at bugs.python.org  Sat Nov  6 07:54:40 2010
From: report at bugs.python.org (Alex)
Date: Sat, 06 Nov 2010 06:54:40 +0000
Subject: [issue10334] Add new reST directive for links to source code
In-Reply-To: <1289024882.94.0.454472669489.issue10334@psf.upfronthosting.co.za>
Message-ID: <1289026480.68.0.152828618497.issue10334@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Seems to me it should be an inline directive (or whatever they're called).  i.e. it'd be written::

.. seealso::

    Latest version of the :sourcecode:`ast module Python source code <Lib/ast.py>`.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10334>
_______________________________________

From report at bugs.python.org  Sat Nov  6 07:58:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 06:58:03 +0000
Subject: [issue10334] Add new reST directive for links to source code
In-Reply-To: <1289024882.94.0.454472669489.issue10334@psf.upfronthosting.co.za>
Message-ID: <1289026683.05.0.567760885919.issue10334@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A directive can take options, for example to control highlighting, display of line numbers, etc.  Similar existing constructs like literalinclude are directives.

Inline reST things are called roles :)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10334>
_______________________________________

From report at bugs.python.org  Sat Nov  6 08:13:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 07:13:06 +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: <1289027586.87.0.173923373865.issue10299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 on the general idea.  I applied the patch and built the documentation to see what the output looks like: The hotlinks are here and work, that?s cool, but I think the table wastes space.  You could use five columns without damaging usability (that is, summoning the hateful horizontal scrollbar), even in 800?600 with an uncollapsed sidebar.

Alternative ideas like using a special unordered list with automatic CSS?3 flowing or replacing the manual table with a new Sphinx directive would take a lot of time, so consider I?m +1 on whatever you decide best.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Sat Nov  6 08:18:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 07:18:31 +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: <1289027911.03.0.441186851904.issue10299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 on the general idea.  I applied the patch and built the documentation to see what the output looks like: The hotlinks are here and work, that?s cool, but I think the table wastes space.  You could use five columns without damaging usability (that is, summoning the hateful horizontal scrollbar), even in 800?600 with an uncollapsed sidebar.

Alternative ideas like using a special unordered list with automatic CSS?3 flowing or replacing the manual table with a new Sphinx directive would take a lot of time, so consider I?m +1 on whatever you decide best.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Sat Nov  6 08:20:35 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Nov 2010 07:20:35 +0000
Subject: [issue10334] Add new reST directive for links to source code
In-Reply-To: <1289024882.94.0.454472669489.issue10334@psf.upfronthosting.co.za>
Message-ID: <1289028035.5.0.127528796937.issue10334@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

OK, I added a "source" role in r86256.  It can be used as Alex showed:

either like :source:`ast module Python source code <Lib/ast.py>`
(with an explicit link title)

or like :source:`Lib/ast.py`
(where the link title is the file name).

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10334>
_______________________________________

From report at bugs.python.org  Sat Nov  6 08:40:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 07:40:59 +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: <1289029259.11.0.499200164297.issue8910@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

By the way, is this file picked up by Tools/msi/msi.py?

----------
nosy: +loewis
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8910>
_______________________________________

From report at bugs.python.org  Sat Nov  6 08:44:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Nov 2010 07:44:40 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1289029480.38.0.645753177638.issue5412@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Email uses 'failobj' instead of 'default'.  I find that kind of odd, but oh well.

I'm not sure how useful a single data point is, but just last month I wrote an application that uses the DEFAULT section.  Each configfile section gives a set of parameters describing certain attributes of an input file, and the DEFAULT section gives the default values for each of those parameters.  A few years ago I had an application that made heavy use of interpolation and provided for config files that would override 'earlier' config files, and I used the 'defaults' parameter to the constructor to achieve this easily.  I'm pretty sure I also added a few defaults programatically, but the memory is a bit hazy (I no longer maintain that application and I don't think it is in use any longer).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Sat Nov  6 09:18:20 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 06 Nov 2010 08:18:20 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1289031500.61.0.530068851686.issue10273@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> people who are used to the current spelling 
> will have to notice the change, note that one 
> name is now deprecated

I haven't proposed any deprecations.
Just add the new names as aliases.
Change the docs list the new names
as primary and mention the old name for reference.

We don't have to sticking with crummy naming.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10273>
_______________________________________

From report at bugs.python.org  Sat Nov  6 09:34:05 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 06 Nov 2010 08:34:05 +0000
Subject: [issue2931] optparse: various problems with unicode and gettext
In-Reply-To: <1211297479.44.0.970954846769.issue2931@psf.upfronthosting.co.za>
Message-ID: <1289032445.34.0.276262522924.issue2931@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yep, argparse almost certainly has the same kind of problems - I basically copied the optparse gettext behavior into argparse because I don't really know how that stuff works but figured people must have wanted what was in there. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2931>
_______________________________________

From report at bugs.python.org  Sat Nov  6 10:22:20 2010
From: report at bugs.python.org (Nicolas Kaiser)
Date: Sat, 06 Nov 2010 09:22:20 +0000
Subject: [issue10324] Modules/binascii.c: simplify expressions
In-Reply-To: <1288960282.63.0.36896617849.issue10324@psf.upfronthosting.co.za>
Message-ID: <1289035340.92.0.292188887992.issue10324@psf.upfronthosting.co.za>


Nicolas Kaiser <nikai at nikai.net> added the comment:

Sorry, found it - with patched builds of Python 2.6.5 and 3.1.2:

python2.6 test_binascii.py
test_base64invalid (__main__.BinASCIITest) ... ok
test_base64valid (__main__.BinASCIITest) ... ok
test_crc32 (__main__.BinASCIITest) ... ok
test_empty_string (__main__.BinASCIITest) ... ok
test_exceptions (__main__.BinASCIITest) ... ok
test_functions (__main__.BinASCIITest) ... ok
test_hex (__main__.BinASCIITest) ... ok
test_qp (__main__.BinASCIITest) ... ok
test_uu (__main__.BinASCIITest) ... ok

----------------------------------------------------------------------
Ran 9 tests in 0.002s

OK

python3.1 test_binascii.py
test_base64invalid (__main__.BinASCIITest) ... ok
test_base64valid (__main__.BinASCIITest) ... ok
test_crc32 (__main__.BinASCIITest) ... ok
test_empty_string (__main__.BinASCIITest) ... ok
test_exceptions (__main__.BinASCIITest) ... ok
test_functions (__main__.BinASCIITest) ... ok
test_hex (__main__.BinASCIITest) ... ok
test_no_binary_strings (__main__.BinASCIITest) ... ok
test_qp (__main__.BinASCIITest) ... ok
test_uu (__main__.BinASCIITest) ... ok

----------------------------------------------------------------------
Ran 10 tests in 0.006s

OK

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10324>
_______________________________________

From report at bugs.python.org  Sat Nov  6 11:49:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 10:49:39 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>
Message-ID: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In Python3, the following pattern becomes common:

        with open(fullname, 'rb') as fp:
            coding, line = tokenize.detect_encoding(fp.readline)
        with open(fullname, 'r', encoding=coding) as fp:
            ...

It opens the file is opened twice, whereas it is unnecessary: it's possible to reuse the raw buffer to create a text file. And I don't like the detect_encoding() API: pass the readline function is not intuitive.

I propose to create tokenize.open_python() function with a very simple API: just one argument, the filename. This function calls detect_encoding() and only open the file once.

Attached python adds the function with an unit test and a patch on the documentation. It patchs also functions currently using detect_encoding().

open_python() only supports read mode. I suppose that it is enough.

----------
components: Library (Lib), Unicode
files: open_python.patch
keywords: patch
messages: 120600
nosy: haypo
priority: normal
severity: normal
status: open
title: tokenize.open_python(): open a Python file with the right encoding
versions: Python 3.2
Added file: http://bugs.python.org/file19518/open_python.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Sat Nov  6 11:51:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 10:51:04 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1289016600.21.0.75147972422.issue10329@psf.upfronthosting.co.za>
Message-ID: <201011061150.54315.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> 1. It opens the source file one more time.  This is probably acceptable
> because existing code already opens it at least four times when -m (show
> missing) option is selected.  (Twice in find_executable_linenos() and
> twice in linecache.getlines().  Fixing that would require refactoring of
> linecache code.

Create a function like linecache.getencoding() seems to be overkill.

I created issue #10335 to add a function tokenize.open_python(): open a Python 
script in read mode without opening the file twice and get the encoding with 
detect_encoding(). This issue is more generic than trying to optimize the 
trace module.

> 2. This will not work for source code not stored in a file, but provided by
> a __loader__.get_source() method.  However it looks like trace will not
> work at all in this case, so fixing that is a separate issue.

For this case, I think that we can add a try/except IOError with a fallback to 
encoding = 'utf-8'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Sat Nov  6 11:55:17 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 06 Nov 2010 10:55:17 +0000
Subject: [issue10336] test_xmlrpc fails if gzip is not supported by client
In-Reply-To: <1289040917.15.0.713563652016.issue10336@psf.upfronthosting.co.za>
Message-ID: <1289040917.15.0.713563652016.issue10336@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

In test_xmlrpc.py,

    def test_gsip_response(self):
        # (sniP)
        self.assertTrue(a>b)

last line can fail if gzip is not supported by client.
(gzip is not set in HTTP header's Accept-Encoding)

======================================================================
FAIL: test_gsip_response (__main__.GzipServerTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_xmlrpc.py", line 722, in test_gsip_resp
onse
    self.assertTrue(a>b)
AssertionError: False is not True

----------
components: Library (Lib)
messages: 120602
nosy: ocean-city
priority: normal
severity: normal
status: open
title: test_xmlrpc fails if gzip is not supported by client
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10336>
_______________________________________

From report at bugs.python.org  Sat Nov  6 11:56:07 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 06 Nov 2010 10:56:07 +0000
Subject: [issue10336] test_xmlrpc fails if gzip is not supported by client
Message-ID: <1289040967.83.0.157032272423.issue10336@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
Removed message: http://bugs.python.org/msg120602

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10336>
_______________________________________

From report at bugs.python.org  Sat Nov  6 11:57:18 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 06 Nov 2010 10:57:18 +0000
Subject: [issue10336] test_xmlrpc fails if gzip is not supported by client
In-Reply-To: <1289041038.52.0.266218953067.issue10336@psf.upfronthosting.co.za>
Message-ID: <1289041038.52.0.266218953067.issue10336@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

In test_xmlrpc.py,

    def test_gsip_response(self):
        # (sniP)
        self.assertTrue(a>b)

last line can fail if gzip is not supported by client.
(gzip is not set in HTTP header's Accept-Encoding)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10336>
_______________________________________

From report at bugs.python.org  Sat Nov  6 12:03:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 11:03:56 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

On "NetBSD 5 i386 3.x" buildbot, testTanh() of test_math fails because the sign of wrong.

configure scripts has a test to check if tanh(-0.0) keeps the sign or no, and on this buildbot the result is "no". pyconfig.h contains a TANH_PRESERVES_ZERO_SIGN define, but it is not used in Modules/mathmodule.c. Extract of configure comment:

# On FreeBSD 6.2, it appears that tanh(-0.) returns 0. instead of
# -0. on some architectures.

---

http://www.python.org/dev/buildbot/builders/NetBSD%205%20i386%203.x/builds/237/steps/configure/logs/stdio
...
checking whether tanh preserves the sign of zero... no
...

http://www.python.org/dev/buildbot/builders/NetBSD%205%20i386%203.x/builds/237/steps/test/logs/stdio
======================================================================
FAIL: testTanh (test.test_math.MathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.smith-netbsd-i386/build/Lib/test/test_math.py", line 898, in testTanh
    math.copysign(1., -0.))
AssertionError: 1.0 != -1.0

----------------------------------------------------------------------

----------
components: Library (Lib)
messages: 120604
nosy: haypo
priority: normal
severity: normal
status: open
title: testTanh() of test_math fails on "NetBSD 5 i386 3.x"
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sat Nov  6 12:04:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 11:04:21 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289041461.22.0.822861835157.issue10337@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sat Nov  6 12:05:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 11:05:15 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289041515.89.0.939360464527.issue10337@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_cmath does also fail:

http://www.python.org/dev/buildbot/builders/NetBSD%205%20i386%203.x/builds/237/steps/test/logs/stdio
======================================================================
FAIL: test_specific_values (test.test_cmath.CMathTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.x.smith-netbsd-i386/build/Lib/test/test_cmath.py", line 348, in test_specific_values
    msg=error_message)
  File "/home/buildbot/buildarea/3.x.smith-netbsd-i386/build/Lib/test/test_cmath.py", line 94, in rAssertAlmostEqual
    'got {!r}'.format(a, b))
AssertionError: tanh0002: tanh(complex(-0.0, 0.0))
Expected: complex(-0.0, 0.0)
Received: complex(0.0, 0.0)
Received value insufficiently close to expected value.

----------------------------------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sat Nov  6 12:05:35 2010
From: report at bugs.python.org (Andrew Vant)
Date: Sat, 06 Nov 2010 11:05:35 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1289041535.83.0.255043312776.issue1926@psf.upfronthosting.co.za>


Andrew Vant <ajvant at gmail.com> added the comment:

Here's a second version of the previous patch taking into account the errors Antoine noticed and some odds and ends from the other comments. Specifically: 

Comments fixed and tabs (I think...I hope...) all removed.

Added explicit skip to test_nntplib when attempting to test starttls using a server that doesn't support it. 

Exceptions raised when issuing STARTTLS for: Authorization already done, TLS already active, server not advertising STARTTLS.

Method moving: I'm not sure why the first patch seemed to think I was e.g. moving getwelcome (I wasn't, as far as I knew), but this time I put the new functions at the end of the class and it's no longer doing it. (still a bit of a mess for the code moved from __init__ to login, starttls, and readermode though) 

Selftest cli option: I threw out what I did before (as pointed out, it didn't work anyway) and added a -l flag to use SSL. It uses port 563 for the test only if the user hasn't asked for a non-default port. 


I'd like to address some of the objections other users have to the way I implemented it the first time.


NNTPS and STARTTLS separation: 

One objection noted that nntps and STARTTLS support are really separate things and should be handled as such. Actually they're probably right. I did both at once because I view them as simply two ways of performing the same function, as someone mentioned earlier in the thread.


Unnecessary Method Separation: 

One objection noted that separating out login and starttls was unnecessary and the calling program shouldn't have to worry about these steps. I disagree; I think the caller should be able to choose when and if to log in or engage encryption. (in fact I think usenetrc should be false by default for this reason, but I figure that would break backwards compatibility for programs that rely on it being true by default, and I'm not sure what the rules are regarding this) 

More significant than my own potentially newbie-ish opinion is that the RFC suggests as a valid use case the idea of a client starting up TLS or authentication in reaction to a 483 command response, rather than right off the bat. I'm pretty sure this is impossible under the current setup, where login/encryption happens only at initialization and there's no method exposed to do it later. 

If I'm going to get overruled on this, I guess the other option is to add a starttls argument to the constructors. If so, I'd suggest it have settings to forbid starttls, use it if it's advertised, or insist on it (by raising an exception if it can't be used). Perhaps false/none/true respectively. 


Existing issue for AUTHINFO and MODE READER:

One objection noted there's already an issue open for them (#10287). Which is true, but the AUTHINFO and MODE READER changes were necessary to make STARTTLS work as intended. (in my opinion, I suppose) So I did them as I went along. I'm not sure if I violated custom there, but my apologies if so.

At least having them functioned out will make most of what's mentioned in 10287 easier to fix, I suppose. 


Randomness:

BTW, I've been maintaining the readermode_afterauth thing because of the comment next to it, but it sounds from that other issue like it's not supposed to be there at all...which kind of restores my faith in the universe since it smelled bad from the start to me.

----------
Added file: http://bugs.python.org/file19519/python_nntp_ssl_patch2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Sat Nov  6 12:08:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 11:08:03 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289041683.69.0.151121503247.issue10337@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sat Nov  6 12:12:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 11:12:38 +0000
Subject: [issue10338] test_lib2to3 failure on buildbot x86 debian parallel
	3.x: node is None in find_root()
In-Reply-To: <1289041958.15.0.549624913321.issue10338@psf.upfronthosting.co.za>
Message-ID: <1289041958.15.0.549624913321.issue10338@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

http://www.python.org/dev/buildbot/builders/x86%20debian%20parallel%203.x/builds/806/steps/test/logs/stdio

test test_lib2to3 failed -- multiple errors occurred

======================================================================
ERROR: test_bom (lib2to3.tests.test_refactor.TestRefactoringTool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 239, in test_bom
    data = self.check_file_refactoring(fn)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 186, in check_file_refactoring
    rt.refactor_file(test_file)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 348, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 380, in refactor_string
    self.refactor_tree(tree, name)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 441, in refactor_tree
    find_root(node)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/fixer_util.py", line 276, in find_root
    while node.type != syms.file_input:
AttributeError: 'NoneType' object has no attribute 'type'

======================================================================
ERROR: test_crlf_newlines (lib2to3.tests.test_refactor.TestRefactoringTool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 248, in test_crlf_newlines
    self.check_file_refactoring(fn, fixes)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 186, in check_file_refactoring
    rt.refactor_file(test_file)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 348, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 380, in refactor_string
    self.refactor_tree(tree, name)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 441, in refactor_tree
    find_root(node)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/fixer_util.py", line 276, in find_root
    while node.type != syms.file_input:
AttributeError: 'NoneType' object has no attribute 'type'

======================================================================
ERROR: test_file_encoding (lib2to3.tests.test_refactor.TestRefactoringTool)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 235, in test_file_encoding
    self.check_file_refactoring(fn)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_refactor.py", line 186, in check_file_refactoring
    rt.refactor_file(test_file)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 348, in refactor_file
    tree = self.refactor_string(input, filename)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 380, in refactor_string
    self.refactor_tree(tree, name)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 441, in refactor_tree
    find_root(node)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/fixer_util.py", line 276, in find_root
    while node.type != syms.file_input:
AttributeError: 'NoneType' object has no attribute 'type'

======================================================================
ERROR: test_unencodable_diff (lib2to3.tests.test_main.TestMain)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_main.py", line 36, in test_unencodable_diff
    ret = self.run_2to3_capture(["-"], input_stream, out_enc, err)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/tests/test_main.py", line 25, in run_2to3_capture
    return main.main("lib2to3.fixes", args)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/main.py", line 168, in main
    rt.refactor_stdin()
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 393, in refactor_stdin
    tree = self.refactor_string(input, "<stdin>")
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 380, in refactor_string
    self.refactor_tree(tree, name)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/refactor.py", line 441, in refactor_tree
    find_root(node)
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/lib2to3/fixer_util.py", line 276, in find_root
    while node.type != syms.file_input:
AttributeError: 'NoneType' object has no attribute 'type'

----------------------------------------------------------------------

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 120607
nosy: benjamin.peterson, haypo
priority: normal
severity: normal
status: open
title: test_lib2to3 failure on buildbot x86 debian parallel 3.x: node is None in find_root()
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10338>
_______________________________________

From report at bugs.python.org  Sat Nov  6 12:12:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 11:12:45 +0000
Subject: [issue10338] test_lib2to3 failure on buildbot x86 debian parallel
	3.x: node is None in find_root()
In-Reply-To: <1289041958.15.0.549624913321.issue10338@psf.upfronthosting.co.za>
Message-ID: <1289041965.63.0.153428632001.issue10338@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10338>
_______________________________________

From report at bugs.python.org  Sat Nov  6 12:48:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Nov 2010 11:48:24 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1289041535.83.0.255043312776.issue1926@psf.upfronthosting.co.za>
Message-ID: <1289044096.3550.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch, Andrew. It looks mostly good.

I would rename setreadermode to _setreadermode (there's no reason to
make it public IMO). Also, I would not explicitly check "STARTTLS" in
the capabilities. It the server doesn't support it, it will issue an
error anyway. Some servers might support it without advertising it, who
knows?

I can take care of all that when committing, you don't need to submit a
new patch (you can of course, if you want).

> (in fact I think usenetrc should be false by default for this reason,
> but I figure that would break backwards compatibility for programs
> that rely on it being true by default, and I'm not sure what the rules
> are regarding this) 

In 3.2, the reworked nntplib already breaks compatibility. It is
reasonable to switch the default for usenetrc to False; but I prefer to
do it in a separate commit for clarity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Sat Nov  6 12:49:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 06 Nov 2010 11:49:33 +0000
Subject: [issue10339] test_lib2to3 leaks
In-Reply-To: <1289044173.26.0.233554890418.issue10339@psf.upfronthosting.co.za>
Message-ID: <1289044173.26.0.233554890418.issue10339@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is only on 3.1:

$ ./python -m test.regrtest -R 3:3 test_lib2to3
test_lib2to3
beginning 6 repetitions
123456
No handlers could be found for logger "RefactoringTool"
......
test_lib2to3 leaked [32, 32, 32] references, sum=96

----------
assignee: benjamin.peterson
components: 2to3 (2.x to 3.0 conversion tool), Tests
messages: 120609
nosy: benjamin.peterson, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_lib2to3 leaks
type: resource usage
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10339>
_______________________________________

From report at bugs.python.org  Sat Nov  6 12:57:01 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Sat, 06 Nov 2010 11:57:01 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1289044621.12.0.526567558675.issue1926@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

> More significant than my own potentially newbie-ish
> opinion is that the RFC suggests as a valid use case
> the idea of a client starting up TLS or authentication
> in reaction to a 483 command response, rather than right
> off the bat.

Yes.  (Currently, it would only be TLS with nntplib, because
SASL mechanisms which negotiate an encryption layer are not
implemented yet in nntplib.  But in case someone wishes to test,
I have the following capabilities on my news server,
news.trigofacile.com :
AUTHINFO USER SASL
SASL GSSAPI OTP PLAIN NTLM LOGIN DIGEST-MD5 CRAM-MD5
STARTTLS
)



> I'm pretty sure this is impossible under the current setup,
> where login/encryption happens only at initialization and
> there's no method exposed to do it later.

Absolutely.



> I've been maintaining the readermode_afterauth thing
[...]
> it smelled bad from the start to me.

Yep.  According to RFC 4643:

   Additionally, the client MUST NOT issue a MODE READER
   command after authentication, and a server MUST NOT advertise the
   MODE-READER capability.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Sat Nov  6 13:12:52 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 06 Nov 2010 12:12:52 +0000
Subject: [issue4931] distutils does not show any error msg when can't build C
	module extensions due to a missing C compiler
In-Reply-To: <1231867865.54.0.174725758904.issue4931@psf.upfronthosting.co.za>
Message-ID: <1289045572.68.0.614559072568.issue4931@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I don't have the same setup I had at the time when I submitted the first message so maybe something has changed in meantime.
Below is what I get on Windows 2000 SP-3, no VS installed, python 2.7, before and after the patch.

C:\Documents and Settings\foo\Desktop\psutil>setup.py build
running build
running build_py
copying psutil\compat.py -> build\lib.win32-2.7\psutil
copying psutil\error.py -> build\lib.win32-2.7\psutil
copying psutil\_psbsd.py -> build\lib.win32-2.7\psutil
copying psutil\_pslinux.py -> build\lib.win32-2.7\psutil
copying psutil\_psmswindows.py -> build\lib.win32-2.7\psutil
copying psutil\_psosx.py -> build\lib.win32-2.7\psutil
copying psutil\_psposix.py -> build\lib.win32-2.7\psutil
copying psutil\__init__.py -> build\lib.win32-2.7\psutil
running build_ext
building '_psutil_mswindows' extension
error: Unable to find vcvarsall.bat


Although the message is improved ("Unable to find vcvarsall.bat" vs "None") it seems the patch had no effect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4931>
_______________________________________

From report at bugs.python.org  Sat Nov  6 14:19:26 2010
From: report at bugs.python.org (Andrew Vant)
Date: Sat, 06 Nov 2010 13:19:26 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1289044096.3550.9.camel@localhost.localdomain>
Message-ID: <4CD555EA.24283.1D3AB092@ajvant.gmail.com>


Andrew Vant <ajvant at gmail.com> added the comment:

On 6 Nov 2010 at 11:48, Antoine Pitrou wrote:

> I would rename setreadermode to _setreadermode (there's no reason to
> make it public IMO). Also, I would not explicitly check "STARTTLS" in
> the capabilities. It the server doesn't support it, it will issue an
> error anyway. Some servers might support it without advertising it,
> who knows?
> 
> I can take care of all that when committing, you don't need to submit
> a new patch (you can of course, if you want).

I'd appreciate it if you took care of it, if you feel the patch is otherwise 
commit-worthy. It takes a pretty excessive amount of time to convince 
myself that it's really doing what I want it to (and only what I want it to).

I forgot to include a note for Misc/NEWS in the new patch version, 
by the way. 

> > (in fact I think usenetrc should be false by default for this
> > reason, but I figure that would break backwards compatibility for
> > programs that rely on it being true by default, and I'm not sure
> > what the rules are regarding this) 
> 
> In 3.2, the reworked nntplib already breaks compatibility. It is
> reasonable to switch the default for usenetrc to False; but I prefer
> to do it in a separate commit for clarity.

Okay. For the time being I left a note in the documentation pointing 
out that it had to be set False for starttls to be useful. 

--

Andrew

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Sat Nov  6 14:36:08 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 06 Nov 2010 13:36:08 +0000
Subject: [issue9508] python3.2 reversal of distutils reintrocud macos9 support
In-Reply-To: <1289024389.4.0.727307029603.issue9508@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=2BFSEKqd3WGfFR1BgBMCzdGRC3YPw4GaJ4kyD@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

Fine.

2010/11/6 ?ric Araujo <report at bugs.python.org>:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Fixed in r86248, thanks. ?BTW, my commit removes a bit more than yours originally did.
>
> In 2.7, the unused distutils.sysconfig._init_mac function is still left over. ?I don?t know if killing dead code is acceptable in a stable version. ?Benjamin?
>
> ----------
> assignee: tarek -> eric.araujo
> nosy: +benjamin.peterson, eric.araujo
> resolution: ?-> fixed
> stage: ?-> committed/rejected
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue9508>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9508>
_______________________________________

From report at bugs.python.org  Sat Nov  6 15:10:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 14:10:30 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1289052630.3.0.105237743521.issue10252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The tests don?t pass on a Windows buildbot (thanks Antoine): I was mistaken about subprocess.Popen, it has no close method like os.popen objects.  Attached patch should fix it, can someone kindly review and/or test it?

----------
nosy: +pitrou
Added file: http://bugs.python.org/file19520/fix-popen.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Sat Nov  6 15:10:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 14:10:51 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1289052651.33.0.599822771961.issue10252@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Sat Nov  6 15:17:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 14:17:42 +0000
Subject: [issue9508] python3.2 reversal of distutils reintrocud macos9 support
In-Reply-To: <1280927222.45.0.841645452377.issue9508@psf.upfronthosting.co.za>
Message-ID: <1289053062.57.0.696659279026.issue9508@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the reply.  r86264.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9508>
_______________________________________

From report at bugs.python.org  Sat Nov  6 15:31:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 14:31:06 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>
Message-ID: <1289053866.0.0.375896598541.issue10335@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.

In the test, do you have to remove the TESTFN file manually?  Isn?t that handled by unittest or regrtest?

I think the name of the function could be better but I don?t have a proposal.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Sat Nov  6 15:32:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 14:32:27 +0000
Subject: [issue10336] test_xmlrpc fails if gzip is not supported by client
In-Reply-To: <1289041038.52.0.266218953067.issue10336@psf.upfronthosting.co.za>
Message-ID: <1289053947.83.0.109788164794.issue10336@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do you want to make a patch?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10336>
_______________________________________

From report at bugs.python.org  Sat Nov  6 15:34:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 14:34:58 +0000
Subject: [issue8679] write a distutils to distutils2 converter
In-Reply-To: <1273527573.05.0.844239277503.issue8679@psf.upfronthosting.co.za>
Message-ID: <1289054098.15.0.586284139293.issue8679@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Rejected in http://hg.python.org/distutils2/rev/05f890cbd877: ?Removing the converter. This is not going to work out. We have better ideas about d1 -> d2 migration paths? (like mkpkg, now mkcfg, still to be given a better name :).

----------
dependencies:  -add a metadata section in setup.cfg, add a resource+files section in setup.cfg, update mkpkg to latest coding standards
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8679>
_______________________________________

From report at bugs.python.org  Sat Nov  6 15:56:32 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 06 Nov 2010 14:56:32 +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: <1289055392.69.0.485144076522.issue10340@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

http://code.google.com/p/pyftpdlib/issues/detail?id=143
This comes from a user who sent me a report via e-mail. Unfortunately I don't have an OSX box to test against.

Code which should replicate the problem is this:

import socket, struct
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER, struct.pack('ii', 1, 0))
s.connect(('localhost', 21))
s.close()

...while this is a fix I think it should work:

Index: Lib/asyncore.py
===================================================================
--- Lib/asyncore.py	(revisione 86084)
+++ Lib/asyncore.py	(copia locale)
@@ -242,7 +242,7 @@
             try:
                 self.addr = sock.getpeername()
             except socket.error, err:
-                if err.args[0] == ENOTCONN:
+                if err.args[0] in (ENOTCONN, EINVAL):
                     # To handle the case where we got an unconnected
                     # socket.
                     self.connected = False


Nosying ixokai as I know he has an OSX box to test against.
Setting "high" priority and type == "security" as asyncore-based servers are likely to crash because of this.
It might even make sense to backport the fix in Python 2.6 because of the security implications.

----------
components: Library (Lib)
keywords: patch
messages: 120620
nosy: giampaolo.rodola, ixokai
priority: high
severity: normal
stage: patch review
status: open
title: asyncore doesn't properly handle EINVAL on OSX
type: security
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10340>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:08:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 15:08:12 +0000
Subject: [issue10341] Remove traces of setuptools
In-Reply-To: <1289056092.28.0.82143087387.issue10341@psf.upfronthosting.co.za>
Message-ID: <1289056092.28.0.82143087387.issue10341@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

There are some leftovers of the short-lived presence of setuptools in the CPython source tree, precisely in Tools/msi/msi.py and Makefile.pre.in.  Attached patch removes them.

----------
components: Build
files: remove-setuptools-leftovers.diff
keywords: patch
messages: 120621
nosy: eric.araujo, loewis
priority: normal
severity: normal
stage: patch review
status: open
title: Remove traces of setuptools
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19521/remove-setuptools-leftovers.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10341>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:13:05 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 06 Nov 2010 15:13:05 +0000
Subject: [issue10334] Add new reST directive for links to source code
In-Reply-To: <1289024882.94.0.454472669489.issue10334@psf.upfronthosting.co.za>
Message-ID: <1289056385.26.0.395904390867.issue10334@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10334>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:14:38 2010
From: report at bugs.python.org (th3flyboy)
Date: Sat, 06 Nov 2010 15:14:38 +0000
Subject: [issue8680] Add a sandbox in Distutils2
In-Reply-To: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>
Message-ID: <1289056478.54.0.677778785661.issue8680@psf.upfronthosting.co.za>


th3flyboy <th3flyboy at gmail.com> added the comment:

Hey, even if it's not perfect, it would be nice to at least see partial sand boxing in Python, rather than none at all. I'm working on an open source game project that uses Python, but recently the issue of security came up involving using python scripts with malicious intent or even just on accident that may cause security issues with user generated content. It would be great to be able to see even a built in sandbox that just covers python scripts, let alone calls to C/C++ code. Even if it's not perfect, some is better than none in my opinion.

----------
nosy: +th3flyboy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8680>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:18:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 15:18:15 +0000
Subject: [issue8680] Add a sandbox in Distutils2
In-Reply-To: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>
Message-ID: <1289056695.55.0.234478093235.issue8680@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We?re saying the same thing :)  It all depends on the promise: If you?re making a best-effort sandbox, you?re trying to do the best you can, in cooperation with your users.  For a game, I think you want an iron-clad sandbox that is totally error-proof.  See https://pypi.python.org/pypi/pysandbox/1.0.3 for such a thing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8680>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:21:40 2010
From: report at bugs.python.org (th3flyboy)
Date: Sat, 06 Nov 2010 15:21:40 +0000
Subject: [issue8680] Add a sandbox in Distutils2
In-Reply-To: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>
Message-ID: <1289056900.34.0.641692863328.issue8680@psf.upfronthosting.co.za>


th3flyboy <th3flyboy at gmail.com> added the comment:

Cool, thanks for that link, that should really help. One quick question however, do you or anyone else know if that will work under Python 3, we currently use 2, however it would be nice to be able to future proof for moving to 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8680>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:22:38 2010
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 06 Nov 2010 15:22:38 +0000
Subject: [issue10304] error in tutorial triple-string example
In-Reply-To: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>
Message-ID: <1289056958.01.0.312393467621.issue10304@psf.upfronthosting.co.za>


Malte Helmert <helmert at informatik.uni-freiburg.de> added the comment:

I see. (The tutorial really talks about the interactive interpreter though -- I don't think IDLE has been mentioned yet.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10304>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:26:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 06 Nov 2010 15:26:49 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Please run attached zip archive as a python script.  Note that the problem is not specific for using __main__.py - any module that comes from a zip archive or loaded by a custom loader would show the same bug. 

$ unzip -l test.zip 
Archive:  test.zip
  Length     Date   Time    Name
 --------    ----   ----    ----
       79  10-24-08 18:26   __main__.py
 --------                   -------
       79                   1 file
$ $ cat __main__.py
from trace import Trace

def traced(flag):
    if flag:
        return 1
    else:
        return 2

tracer = Trace()
tracer.runfunc(traced, False)
results = tracer.results()
results.write_results(coverdir='.')

$ python testtrace.zip 
 --- modulename: __main__, funcname: traced
Not printing coverage data for 'testtrace.zip/__main__.py': [Errno 20] Not a directory: 'testtrace.zip/__main__.py'
__main__.py(4): __main__.py(7): $

----------
assignee: belopolsky
components: Library (Lib)
files: testtrace.zip
messages: 120626
nosy: belopolsky, haypo
priority: normal
severity: normal
stage: unit test needed
status: open
title: trace module cannot produce coverage reports for zipped modules
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19522/testtrace.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:33:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 15:33:13 +0000
Subject: [issue8680] Add a sandbox in Distutils2
In-Reply-To: <1273529748.63.0.145688721875.issue8680@psf.upfronthosting.co.za>
Message-ID: <1289057593.65.0.24459762281.issue8680@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think there is some py3 support in pysandbox, but I?m not sure, and this discussion is off-topic for this bug tracker.  If you don?t find anything in the links on the pysandbox page, feel free to ask on the python-list mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8680>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:42:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 06 Nov 2010 15:42:22 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <1289053866.0.0.375896598541.issue10335@psf.upfronthosting.co.za>
Message-ID: <201011061642.14520.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> In the test, do you have to remove the TESTFN file manually?  Isn?t that
> handled by unittest or regrtest?

The test uses TESTFN+'.py', not TESTFN ;-)

> I think the name of the function could be better but I don?t have a
> proposal.

Do you prefer a name like tokenize.open()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:44:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 15:44:14 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>
Message-ID: <1289058254.6.0.432995091897.issue10335@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The test uses TESTFN+'.py', not TESTFN ;-)
Ah, right.  You can use addCleanup then.

> Do you prefer a name like tokenize.open()?
Hm, tokenize being ?Tokenization help for Python programs?, I think this name is rather good.  Or tokenize.open_source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:53:36 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 06 Nov 2010 15:53:36 +0000
Subject: [issue10341] Remove traces of setuptools
In-Reply-To: <1289056092.28.0.82143087387.issue10341@psf.upfronthosting.co.za>
Message-ID: <1289058816.32.0.237587574973.issue10341@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

LGTM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10341>
_______________________________________

From report at bugs.python.org  Sat Nov  6 16:59:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 15:59:55 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1289059195.61.0.592838916158.issue10252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Committed to py3k in r86274, after ?LGTM? from Brian on IRC.  Will backport if buildbots don?t scream at me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Sat Nov  6 17:00:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 06 Nov 2010 16:00:15 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>
Message-ID: <1289059215.52.0.745533650542.issue10335@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

+1 on adding the function.

Note that it is useful for opening any text file with an encoding cookie, not only python source code, so "tokenize.open()" sounds attractive.

Once we are at it, I would like to factor out and document code that extracts the cookie from a decoded string.  This functionality is useful for tools that produce annotated source code and want to preserve source encoding in their output.  See issue10329.

Also, to answer Victor's comment on issue10329, msg120601, while using this function simplifies dealing with source files in trace module, it does not solve all the issues: source file will still be opened separately in linecache.gettines() and find_executable_linenos() and  find_executable_linenos() still does not respect __loader__ interface.  See issue 10342.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Sat Nov  6 17:08:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 16:08:43 +0000
Subject: [issue10341] Remove traces of setuptools
In-Reply-To: <1289056092.28.0.82143087387.issue10341@psf.upfronthosting.co.za>
Message-ID: <1289059723.14.0.0907836648442.issue10341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, committed to py3k in r86275.  Shall I backport to the stable branches?  (On another bug, Benjamin told me it was acceptable to remove dead code in stable branches.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10341>
_______________________________________

From report at bugs.python.org  Sat Nov  6 17:12:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 06 Nov 2010 16:12:32 +0000
Subject: [issue10341] Remove traces of setuptools
In-Reply-To: <1289056092.28.0.82143087387.issue10341@psf.upfronthosting.co.za>
Message-ID: <1289059952.94.0.987082882039.issue10341@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In this case, backporting is ok (but IMO not needed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10341>
_______________________________________

From report at bugs.python.org  Sat Nov  6 17:15:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 16:15:15 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>
Message-ID: <1289060115.97.0.384816250075.issue10335@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Note that it is useful for opening any text file with an encoding
> cookie, not only python source code,
This is cool.  doctest could benefit from that, I think.

> so "tokenize.open()" sounds attractive.
Agreed, even though the docstring of tokenize does talk about Python code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Sat Nov  6 17:17:36 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Sat, 06 Nov 2010 16:17:36 +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: <1289060256.32.0.604076970886.issue10340@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

I can verify the problem exists in asyncore at release27-maint on the mac, and that the below patch fixes it.

After applying, I ran a full regrtest and nothing new broke.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10340>
_______________________________________

From report at bugs.python.org  Sat Nov  6 17:25:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 06 Nov 2010 16:25:33 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <1289060115.97.0.384816250075.issue10335@psf.upfronthosting.co.za>
Message-ID: <AANLkTinUMFiTi2kDGZsJXTtzof++04hERd+rUMU-n8v5@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Nov 6, 2010 at 12:15 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
>> so "tokenize.open()" sounds attractive.
> Agreed, even though the docstring of tokenize does talk about Python code.

I still like "tokenize.open()" more, but for the sake of completeness
of discussion, what about open(.., encoding="fromcookie")?  (I know,
tokenize.detect_encoding() also looks for an utf-8 BOM, so
"fromcookie" can be improved.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Sat Nov  6 17:32:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 16:32:04 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>
Message-ID: <1289061124.59.0.159662350593.issue10335@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t know if it would be okay to depend on tokenize in io.  Anyway, I tend to prefer tokenize.open over builtins.open(..., encoding='fromcookie').

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Sat Nov  6 17:42:08 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 06 Nov 2010 16:42:08 +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: <1289061728.86.0.156732887889.issue10340@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

While writing a test case for this I found out another problem in asyncore: handle_connect was erroneously called when the dispatcher delegates the connection to a handler resulting in ENOTCONN being raised.
Patch in attachment targeted for python 2.7 should fix both issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10340>
_______________________________________

From report at bugs.python.org  Sat Nov  6 17:42:20 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 06 Nov 2010 16:42: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: <1289061740.75.0.98483433353.issue10340@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +josiah.carlson
versions: +Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10340>
_______________________________________

From report at bugs.python.org  Sat Nov  6 17:46:36 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 06 Nov 2010 16:46:36 +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: <1289061996.3.0.417835228719.issue10340@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/file19523/asyncore.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10340>
_______________________________________

From report at bugs.python.org  Sat Nov  6 18:23:06 2010
From: report at bugs.python.org (StevenJ)
Date: Sat, 06 Nov 2010 17:23:06 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1289064186.46.0.691566209426.issue1926@psf.upfronthosting.co.za>


StevenJ <sjohnson at sakuraindustries.com> added the comment:

The only comment I have is, if the caller needs to organise when to auth and instigate tls then for completeness getcapabilities() should have an option to force a reget of the current capabilities, in line with rfc3977 5.2.2:

> An NNTP client MAY cache the results of this command, but MUST NOT 
> rely on the correctness of any cached results, whether from earlier
> in this session or from a previous session, MUST cope gracefully 
> with the cached status being out of date, and SHOULD (if caching
> results) provide a way to force the cached information to be
> refreshed.

As it stands, the nntplib can cause the cached capabilities to be refreshed at certain points automatically (as it should), but I 
think it should be possible for the caller of the method to also specify that fresh capabilities are required and not cached ones.

something like this perhaps? :

mynntp.getcapabilites(refresh=True)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Sat Nov  6 18:39:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 17:39:38 +0000
Subject: [issue10341] Remove traces of setuptools
In-Reply-To: <1289056092.28.0.82143087387.issue10341@psf.upfronthosting.co.za>
Message-ID: <1289065178.48.0.396059932679.issue10341@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Given your recent email on python-dev about backporting changes that don?t fix bugs, I will not backport this.  2.5 and 2.6 were fine with the unneeded lines, 2.7 and 3.1 will be too.

----------
assignee:  -> eric.araujo
resolution:  -> fixed
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/issue10341>
_______________________________________

From report at bugs.python.org  Sat Nov  6 18:56:22 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 06 Nov 2010 17:56:22 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1289066182.2.0.363282919055.issue10252@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


Added file: http://bugs.python.org/file19524/fix_pipe_close.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Sat Nov  6 19:01:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 06 Nov 2010 18:01:02 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>
Message-ID: <1289066462.7.0.617135521751.issue10335@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1 for the feature.  However, tokenize.open() sounds a bit unspecific.  But I don't really have better suggestions; open_cookie() is wrong too, since it doesn't open cookies :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Sat Nov  6 19:04:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 18:04:19 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1289066659.82.0.987306368854.issue10252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  r86276

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Sat Nov  6 19:22:31 2010
From: report at bugs.python.org (Andrew Vant)
Date: Sat, 06 Nov 2010 18:22:31 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1289064186.46.0.691566209426.issue1926@psf.upfronthosting.co.za>
Message-ID: <4CD59CF4.16302.1E502F87@ajvant.gmail.com>


Andrew Vant <ajvant at gmail.com> added the comment:

On 6 Nov 2010 at 17:23, StevenJ wrote:

> As it stands, the nntplib can cause the cached capabilities to be
> refreshed at certain points automatically (as it should), but I think
> it should be possible for the caller of the method to also specify
> that fresh capabilities are required and not cached ones.

I agree. I actually added a way to do this when I functioned out 
__init__, so that starttls could refresh it when required. 

It was ugly and not exposed to the caller though. 

> something like this perhaps? :
> 
> mynntp.getcapabilites(refresh=True)

My method sucked, this one doesn't. Might belong in a separate issue 
though. (I feel like a bit of a hypocrite saying that now) 

--

Andrew

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Sat Nov  6 19:43:12 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Sat, 06 Nov 2010 18:43:12 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <1288979234.76.0.50707642444.issue10325@psf.upfronthosting.co.za>
Message-ID: <hbf.20101106g37z@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Mark Dickinson writes:
> Thanks for the report; I agree that there's a potential issue here, and
> I also think that all these definitions *should* be preprocessor
> defines.

Indeed, my suggestion to castify everything for uniformity was silly: My
own PY_TIMEOUT_MAX fix illustrates why that won't promote portability.
It breaks code which #ifdefs between using LONG_MAX and PY_LLONG_MAX.

> (Idle question: does C99 require that LONG_MAX and friends are
> usable in the preprocessor?  ...)

5.2.4.2.1p1: Sizes of integer types <limits.h>.

> Can you suggest a suitable fix for the PY_ULLONG_MAX and PY_LLONG_MAX
> defines?  (...)

As far as I can tell, PC/pyconfig.h already solves it for Windows.

For pyport.h, since you do #define SIZEOF_LONG_LONG:

#define PY_LLONG_MAX \
    (1 + 2 * ((Py_LL(1) << (CHAR_BIT*SIZEOF_LONG_LONG-2)) - 1))
#define PY_ULLONG_MAX (PY_LLONG_MAX * 2ULL + 1)

You could check PY_ULLONG_MAX with a compile-time assertion if you want:

#ifndef __cplusplus /* this requires different magic in C++ */

/* Compile-time assertion -- max one per post-preprocessed line */
#define Py_static_assert(expr) Py_static_assert1_(expr, __LINE__)
#define Py_static_assert1_(expr, line) Py_static_assert2_(expr, line)
#define Py_static_assert2_(expr, line) struct Py_static_assert##line { \
	int Assert1_[(expr) ? 9 : -9]; int Assert2_: (expr) ? 9 : -9; }

Py_static_assert(PY_ULLONG_MAX == (unsigned long long)-1);

#endif /* __cplusplus */

> BTW, do you know of any modern non-Windows platforms that don't define
> LLONG_MIN and LLONG_MAX?  It may well be that the "two's complement"
> fallback hasn't been exercised in recent years.

Anyting compiled with strict ANSI pre-C99 mode, e.g. gcc -ansi, which
you do have a workaround for.  But gcc isn't the only one to be slow in
upgrading to C99.

And unfortunately, even if Python is built without a compiler's
equivalent of -ansi, a user embedding Python might be compiling with it.

Beyond that: No, I know none, but I don't know many platforms anyway.

>> Incidentally, the "two's complement" comment is wrong.
>> It also relies on unsigned long long being widest type with no
>> padding bits, and -LLONG_MAX-1 not being a trap representation.
> 
> Agreed---that comment needs to be better.  I think it's fine, though,
> for practical purposes to assume an absence of padding bits and no trap
> representation; IIRC there are places internally (e.g., in the bitwise
> operators section of the 'int' type implementation) that already assume
> two's complement + no padding bits + no trap representation.

I expect so, yes.  It's easy to find breakage with non-two's complement,
just grep the C code for '~'.  I just get peeved when people get this
wrong, then document and promote the errors:)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Sat Nov  6 19:52:07 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Sat, 06 Nov 2010 18:52:07 +0000
Subject: [issue10343] urllib.parse problems with bytes vs str
In-Reply-To: <1289069527.47.0.125931197964.issue10343@psf.upfronthosting.co.za>
Message-ID: <1289069527.47.0.125931197964.issue10343@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

urlunparse(url or params = bytes object) produces a result
with the repr of the bytes object.

urllib.parse.urlunparse(['http', 'host', '/dir', b'params', '', ''])
--> "http://host/dir;b'params'"

That's confusing since urllib/parse.py goes to a lot of trouble to
support both bytes and str.  Simplest fix is to only accept str:

Index: Lib/urllib/parse.py
@@ -219,5 +219,5 @@ def urlunparse(components):
     scheme, netloc, url, params, query, fragment = components
     if params:
-        url = "%s;%s" % (url, params)
+        url = ';'.join((url, params))
     return urlunsplit((scheme, netloc, url, query, fragment))
 
Some people at comp.lang.python tell me code shouldn't anyway do str()
just in case it is needed like urllib does, not that I can make much
sense of that discussion.  (Subject: harmful str(bytes)).

BTW, the str vs bytes code doesn't have to be quite as painful as in
urllib.parse, I enclose patch which just rearranges and factors out
some code.

----------
components: Library (Lib)
files: parse.diff
keywords: patch
messages: 120647
nosy: hfuru
priority: normal
severity: normal
status: open
title: urllib.parse problems with bytes vs str
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19525/parse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10343>
_______________________________________

From report at bugs.python.org  Sat Nov  6 20:06:26 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Sat, 06 Nov 2010 19:06:26 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <hbf.20101106g37z@bombur.uio.no>
Message-ID: <hbf.20101106giaj@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

I wrote:
> #define PY_LLONG_MAX \
>     (1 + 2 * ((Py_LL(1) << (CHAR_BIT*SIZEOF_LONG_LONG-2)) - 1))
> #define PY_ULLONG_MAX (PY_LLONG_MAX * 2ULL + 1)

Eh, Py_ULL(2).

> (...)  I just get peeved when people get this
> wrong, then document and promote the errors:)

Just to be clear, I'm peeving at the comment, not the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Sat Nov  6 21:30:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 06 Nov 2010 20:30:04 +0000
Subject: [issue10343] urllib.parse problems with bytes vs str
In-Reply-To: <1289069527.47.0.125931197964.issue10343@psf.upfronthosting.co.za>
Message-ID: <1289075404.85.0.421975373686.issue10343@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I believe this is effectively a duplicate of issue 9873.  If not, it is still probably more appropriate to add commentary there rather than have a separate bug here.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> urllib.parse: Allow bytes in some APIs that use string literals internally

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10343>
_______________________________________

From report at bugs.python.org  Sat Nov  6 22:39:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 06 Nov 2010 21:39:41 +0000
Subject: [issue935117] pkgutil doesn't understand case-senseless filesystems
Message-ID: <1289079581.92.0.576161558349.issue935117@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue935117>
_______________________________________

From report at bugs.python.org  Sat Nov  6 23:11:47 2010
From: report at bugs.python.org (Torsten Landschoff)
Date: Sat, 06 Nov 2010 22:11:47 +0000
Subject: [issue850728] Semaphore.acquire() timeout parameter
Message-ID: <1289081507.93.0.630775727801.issue850728@psf.upfronthosting.co.za>


Torsten Landschoff <t.landschoff at gmx.net> added the comment:

Thanks for applying!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue850728>
_______________________________________

From report at bugs.python.org  Sun Nov  7 00:00:18 2010
From: report at bugs.python.org (Santiago Piccinini)
Date: Sat, 06 Nov 2010 23:00:18 +0000
Subject: [issue10344] codecs.readline doesn't care buffering=0
In-Reply-To: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za>
Message-ID: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za>


New submission from Santiago Piccinini <gringotumadre at gmail.com>:

codecs.readline has an internal buffer of 72 chars so calling codecs.open with buffering=0 doesn't work as expected although buffering is passed to the underlying __builtin__.open call.

Example session:

Python 3.2a3+ (py3k, Nov  6 2010, 16:17:14) 
[GCC 4.5.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import codecs
>>> f = codecs.open("foo.txt", "w", "utf-8")
>>> word = "bar\n"
>>> content = word * 1000
>>> f.write(content)
>>> f.close()
>>> f = codecs.open("foo.txt", "rb", "utf-8", buffering=0)
>>> f.readline()
'bar\n'
>>> f.tell()
72

----------
components: Library (Lib)
messages: 120652
nosy: Santiago.Piccinini
priority: normal
severity: normal
status: open
title: codecs.readline doesn't care buffering=0
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10344>
_______________________________________

From report at bugs.python.org  Sun Nov  7 01:11:15 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 07 Nov 2010 00:11:15 +0000
Subject: [issue10344] codecs.readline doesn't care buffering=0
In-Reply-To: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za>
Message-ID: <1289088675.81.0.966361423928.issue10344@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Antoine, should codecs.open() be removed or simply aliased to open()?

----------
nosy: +amaury.forgeotdarc, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10344>
_______________________________________

From report at bugs.python.org  Sun Nov  7 01:37:33 2010
From: report at bugs.python.org (Mark Roddy)
Date: Sun, 07 Nov 2010 00:37:33 +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: <1289090253.13.0.800078564569.issue9857@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

Attaching patch which adds support for registering a skip when raised from tearDown.  Per Michael's point regarding failed tests, this is only handled if the test has been successful when SkipTest is raised from tearDown.

----------
keywords: +patch
nosy: +MarkRoddy
Added file: http://bugs.python.org/file19526/python3k.skipteardown.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9857>
_______________________________________

From report at bugs.python.org  Sun Nov  7 01:39:49 2010
From: report at bugs.python.org (Mark Roddy)
Date: Sun, 07 Nov 2010 00:39:49 +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: <1289090389.06.0.932937183873.issue9857@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

Attaching patch which does the same as the previous for the release27-maint branch.

----------
Added file: http://bugs.python.org/file19527/python27.skipteardown.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9857>
_______________________________________

From report at bugs.python.org  Sun Nov  7 02:07:53 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 07 Nov 2010 01:07:53 +0000
Subject: [issue10344] codecs.readline doesn't care buffering=0
In-Reply-To: <1289088675.81.0.966361423928.issue10344@psf.upfronthosting.co.za>
Message-ID: <4CD5FBE3.60906@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Amaury Forgeot d'Arc wrote:
> 
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
> 
> Antoine, should codecs.open() be removed or simply aliased to open()?

Both is not possible: codecs.open() provides a different API than
open(). Unlike open(), codecs.open() allow use of all available
codecs, not just ones that decode to Unicode.

Regarding the issue itself: I think this is a wrong interpretation of
what the buffering parameter does. File buffering is different
from .readline() buffering (which can be customized on a per-call
basis by specifying a size parameter).

Besides, switching buffering off in open() is only allowed for
binary files, so open() wouldn't "solve" the mentioned behavior.

The only way to implement "unbuffered" .readline() in the way
that Santiago appears to be after would be to set the size parameter
to 1 for all .readline() calls. That would result in very poor
performance, though.

I think we should close this issue as "won't fix".

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10344>
_______________________________________

From report at bugs.python.org  Sun Nov  7 02:16:45 2010
From: report at bugs.python.org (Ben Gamari)
Date: Sun, 07 Nov 2010 01:16:45 +0000
Subject: [issue10345] fcntl.ioctl always fails claiming an invalid fd
In-Reply-To: <1289092604.86.0.0417079814942.issue10345@psf.upfronthosting.co.za>
Message-ID: <1289092604.86.0.0417079814942.issue10345@psf.upfronthosting.co.za>


New submission from Ben Gamari <bgamari at gmail.com>:

Even the simple example included below fails in the following manner,

$ sudo python3.1 hi.py 
<class 'int'> 3
Traceback (most recent call last):
  File "hi.py", line 13, in <module>
    ioctl(a, EVIOCGID, buf, True)
TypeError: ioctl requires a file or file descriptor, an integer and optionally an integer or buffer argument

As the debugging output demonstrates, the fileno() is in fact a valid fd.


#!/usr/bin/python
from fcntl import ioctl
EVIOCGID = 1
f = open('/dev/input/mouse0', 'w')
buf = bytes([0]*128)
a = (f.fileno(),)
print(a.__class__, a)
ioctl(a, EVIOCGID, buf, True)
print(buf)

----------
components: Extension Modules
messages: 120657
nosy: bgamari
priority: normal
severity: normal
status: open
title: fcntl.ioctl always fails claiming an invalid fd
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10345>
_______________________________________

From report at bugs.python.org  Sun Nov  7 02:17:06 2010
From: report at bugs.python.org (Ben Gamari)
Date: Sun, 07 Nov 2010 01:17:06 +0000
Subject: [issue10345] fcntl.ioctl always fails claiming an invalid fd
In-Reply-To: <1289092604.86.0.0417079814942.issue10345@psf.upfronthosting.co.za>
Message-ID: <1289092626.52.0.302014791239.issue10345@psf.upfronthosting.co.za>


Changes by Ben Gamari <bgamari at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10345>
_______________________________________

From report at bugs.python.org  Sun Nov  7 02:41:41 2010
From: report at bugs.python.org (Santiago Piccinini)
Date: Sun, 07 Nov 2010 01:41:41 +0000
Subject: [issue10344] codecs.readline doesn't care buffering=0
In-Reply-To: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za>
Message-ID: <1289094101.97.0.0844918224105.issue10344@psf.upfronthosting.co.za>


Santiago Piccinini <gringotumadre at gmail.com> added the comment:

Marc-Andre Lemburg wrote:
>Regarding the issue itself: I think this is a wrong interpretation of
>what the buffering parameter does. File buffering is different
>from .readline() buffering (which can be customized on a per-call
>basis by specifying a size parameter).

Ok. But builtin's readline buffering works like (I) expected. So there is a difference in behavior between builtins readline an codecs.readline (and it bite me). ?Maybe it should be noted in documentation?

Python 3.2a3+ (py3k, Nov  6 2010, 16:17:14)
[GCC 4.5.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> f = open("foo.txt", "rb", buffering=0)
>>> f.readline()
b'bar\n'
>>> f.tell()
4

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10344>
_______________________________________

From report at bugs.python.org  Sun Nov  7 02:42:19 2010
From: report at bugs.python.org (Ben Gamari)
Date: Sun, 07 Nov 2010 01:42:19 +0000
Subject: [issue10345] fcntl.ioctl always fails claiming an invalid fd
In-Reply-To: <1289092604.86.0.0417079814942.issue10345@psf.upfronthosting.co.za>
Message-ID: <1289094139.12.0.0659102538442.issue10345@psf.upfronthosting.co.za>


Ben Gamari <bgamari at gmail.com> added the comment:

The problem seems to have been that I tried passing mutate_flag. Things seem to work fine when the last parameter is omitted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10345>
_______________________________________

From report at bugs.python.org  Sun Nov  7 03:36:41 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 07 Nov 2010 02:36:41 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1289097401.9.0.34586743585.issue6317@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I updated the patch. (I hope we can remove ANSI version
of Win32 API, though)

----------
Added file: http://bugs.python.org/file19528/py3k_winsound_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Nov  7 10:04:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Nov 2010 09:04:49 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <AANLkTinUMFiTi2kDGZsJXTtzof++04hERd+rUMU-n8v5@mail.gmail.com>
Message-ID: <201011070518.28941.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> what about open(.., encoding="fromcookie")?

Please don't do that. It remembers me the magical str.encode() method of 
Python2. I prefer simple API with limited features: if you want to open a 
Python script, use tokenize.open(), if you want to open an XML document use 
any XML library, etc. It remembers me also the discussion about detecting BOM 
in text files: issue #7651. There was no consensus, and so the issue is still 
open.

For this particular issue, I prefer a specific function tokenize.<choose a 
function name>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Sun Nov  7 10:24:48 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Nov 2010 09:24:48 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <1289059215.52.0.745533650542.issue10335@psf.upfronthosting.co.za>
Message-ID: <201011070536.00599.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

On Saturday 06 November 2010 17:00:15 you wrote:
> Note that it is useful for opening any text file with an encoding cookie,
> not only python source code, so "tokenize.open()" sounds attractive.

Ok, the new patch (tokenize_open-2.patch) uses tokenize.open() name and adds a 
test for BOM without coding cookie (test utf-8-sig encoding).

----------
Added file: http://bugs.python.org/file19529/tokenize_open-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________
-------------- next part --------------
Index: Doc/library/tokenize.rst
===================================================================
--- Doc/library/tokenize.rst	(r??vision 86167)
+++ Doc/library/tokenize.rst	(copie de travail)
@@ -101,16 +101,18 @@
     If no encoding is specified, then the default of ``'utf-8'`` will be
     returned.
 
-    :func:`detect_encoding` is useful for robustly reading Python source files.
-    A common pattern for this follows::
+    Use :func:`open` to open Python script: it uses :func:`detect_encoding` to
+    detect the file encoding.
 
-        def read_python_source(file_name):
-            with open(file_name, "rb") as fp:
-                encoding = tokenize.detect_encoding(fp.readline)[0]
-            with open(file_name, "r", encoding=encoding) as fp:
-                return fp.read()
 
+.. function:: open(filename)
 
+   Open a Python script in read mode using the encoding detected by
+   :func:`detect_encoding`.
+
+   .. versionadded:: 3.2
+
+
 Example of a script rewriter that transforms float literals into Decimal
 objects::
 
@@ -153,4 +155,3 @@
                 result.append((toknum, tokval))
         return untokenize(result).decode('utf-8')
 
-
Index: Lib/py_compile.py
===================================================================
--- Lib/py_compile.py	(r??vision 86167)
+++ Lib/py_compile.py	(copie de travail)
@@ -104,9 +104,7 @@
     byte-compile all installed files (or all files in selected
     directories).
     """
-    with open(file, "rb") as f:
-        encoding = tokenize.detect_encoding(f.readline)[0]
-    with open(file, encoding=encoding) as f:
+    with tokenize.open(file) as f:
         try:
             timestamp = int(os.fstat(f.fileno()).st_mtime)
         except AttributeError:
Index: Lib/tabnanny.py
===================================================================
--- Lib/tabnanny.py	(r??vision 86167)
+++ Lib/tabnanny.py	(copie de travail)
@@ -93,11 +93,8 @@
                 check(fullname)
         return
 
-    with open(file, 'rb') as f:
-        encoding, lines = tokenize.detect_encoding(f.readline)
-
     try:
-        f = open(file, encoding=encoding)
+        f = tokenize.open(file)
     except IOError as msg:
         errprint("%r: I/O Error: %s" % (file, msg))
         return
Index: Lib/tokenize.py
===================================================================
--- Lib/tokenize.py	(r??vision 86167)
+++ Lib/tokenize.py	(copie de travail)
@@ -29,6 +29,7 @@
 from token import *
 from codecs import lookup, BOM_UTF8
 import collections
+from io import TextIOWrapper
 cookie_re = re.compile("coding[:=]\s*([-\w.]+)")
 
 import token
@@ -335,6 +336,20 @@
     return default, [first, second]
 
 
+_builtin_open = open
+
+def open(filename):
+    """
+    Open a Python script in read mode with the right encoding.
+    """
+    buffer = _builtin_open(filename, 'rb')
+    encoding, line = detect_encoding(buffer.readline)
+    buffer.seek(0)
+    text = TextIOWrapper(buffer, encoding, line_buffering=True)
+    text.mode = 'r'
+    return text
+
+
 def tokenize(readline):
     """
     The tokenize() generator requires one argment, readline, which
Index: Lib/trace.py
===================================================================
--- Lib/trace.py	(r??vision 86167)
+++ Lib/trace.py	(copie de travail)
@@ -419,10 +419,9 @@
 def find_executable_linenos(filename):
     """Return dict where keys are line numbers in the line number table."""
     try:
-        with io.FileIO(filename, 'r') as file:
-            encoding, lines = tokenize.detect_encoding(file.readline)
-        with open(filename, "r", encoding=encoding) as f:
+        with tokenize.open_python(filename) as f:
             prog = f.read()
+            encoding = f.encoding
     except IOError as err:
         print(("Not printing coverage data for %r: %s"
                               % (filename, err)), file=sys.stderr)
Index: Lib/linecache.py
===================================================================
--- Lib/linecache.py	(r??vision 86167)
+++ Lib/linecache.py	(copie de travail)
@@ -123,9 +123,7 @@
         else:
             return []
     try:
-        with open(fullname, 'rb') as fp:
-            coding, line = tokenize.detect_encoding(fp.readline)
-        with open(fullname, 'r', encoding=coding) as fp:
+        with tokenize.open(fullname) as fp:
             lines = fp.readlines()
     except IOError:
         return []
Index: Lib/test/test_tokenize.py
===================================================================
--- Lib/test/test_tokenize.py	(r??vision 86167)
+++ Lib/test/test_tokenize.py	(copie de travail)
@@ -564,7 +564,8 @@
 
 from test import support
 from tokenize import (tokenize, _tokenize, untokenize, NUMBER, NAME, OP,
-                     STRING, ENDMARKER, tok_name, detect_encoding)
+                     STRING, ENDMARKER, tok_name, detect_encoding,
+                     open as tokenize_open)
 from io import BytesIO
 from unittest import TestCase
 import os, sys, glob
@@ -857,6 +858,27 @@
         readline = self.get_readline((b'# coding: bad\n',))
         self.assertRaises(SyntaxError, detect_encoding, readline)
 
+    def test_open(self):
+        filename = support.TESTFN + '.py'
+        self.addCleanup(support.unlink, filename)
+
+        #??test coding cookie
+        for encoding in ('iso-8859-15', 'utf-8'):
+            with open(filename, 'w', encoding=encoding) as fp:
+                print("# coding: %s" % encoding, file=fp)
+                print("print('euro:\u20ac')", file=fp)
+            with tokenize_open(filename) as fp:
+                assert fp.encoding == encoding
+                assert fp.mode == 'r'
+
+        #??test BOM (no coding cookie)
+        encoding = 'utf-8-sig'
+        with open(filename, 'w', encoding=encoding) as fp:
+            print("print('euro:\u20ac')", file=fp)
+        with tokenize_open(filename) as fp:
+            assert fp.encoding == encoding
+            assert fp.mode == 'r'
+
 class TestTokenize(TestCase):
 
     def test_tokenize(self):

From report at bugs.python.org  Sun Nov  7 10:27:22 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 07 Nov 2010 09:27:22 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1289122042.59.0.98075055472.issue6317@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've committed in r86283(py3k). I'll merge this into
release31-maint and release27-maint.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Nov  7 10:59:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 07 Nov 2010 09:59:47 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1289123987.44.0.209554262541.issue6317@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As for back-porting: I'm not sure this is a bug in 2.7. It just doesn't support Unicode filenames, but that's not (inherently) a bug. In 3.1, I can agree that it's a bug - but we need to preserve the bytes support for compatibility.

For 3.2, dropping the bytes support is fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Nov  7 11:40:20 2010
From: report at bugs.python.org (Alexey Radkov)
Date: Sun, 07 Nov 2010 10:40:20 +0000
Subject: [issue10346] strange arithmetic behaviour
In-Reply-To: <1289126419.86.0.576404326217.issue10346@psf.upfronthosting.co.za>
Message-ID: <1289126419.86.0.576404326217.issue10346@psf.upfronthosting.co.za>


New submission from Alexey Radkov <alexey.radkov at gmail.com>:

The following excerpt will show the issue:

$ python
Python 2.7 (r27:82500, Sep 16 2010, 18:02:00) 
[GCC 4.5.1 20100907 (Red Hat 4.5.1-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 8 * 4 / ( 2 - 7 ) * 6 / 3
-14
>>>

Why it is evaluated to -14 ?? In floating point arithmetic it should be -12.8, in integer arithmetic i believe it should be -12 (at least bc and a small dedicated C program evaluate it to -12). Perhaps i do not understand some specific python arithmetic priority or associativity rules, anyway i cannot find a specific combinations of them to yield -14 in this expression.

----------
components: None
messages: 120665
nosy: alexey.radkov
priority: normal
severity: normal
status: open
title: strange arithmetic behaviour
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10346>
_______________________________________

From report at bugs.python.org  Sun Nov  7 11:46:21 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 07 Nov 2010 10:46:21 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1289126781.02.0.82769715204.issue6317@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> As for back-porting: I'm not sure this is a bug in 2.7. It just
> doesn't support Unicode filenames, but that's not (inherently)
> a bug.

> In 3.1, I can agree that it's a bug - but we need to preserve the
> bytes support for compatibility.

I agree.

> For 3.2, dropping the bytes support is fine with me.

Is this also applied to *all* ANSI Win32 API
in other sources?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Nov  7 11:51:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 10:51:27 +0000
Subject: [issue10346] strange arithmetic behaviour
In-Reply-To: <1289126419.86.0.576404326217.issue10346@psf.upfronthosting.co.za>
Message-ID: <1289127087.3.0.59046366113.issue10346@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

It's not a bug:  you're seeing Python's rules for integer division, which do indeed differ from those of (some) other languages when either the divisor or the dividend is negative.  For integers x and y, in Python 2.x, x / y gives the floor of the exact quotient.

>>> -32 / 5
-7
>>> 32 / -5
-7

In Python 3.x, the '/' operator does 'true division', giving you (a floating-point approximation to) the true result:

>>> -32 / 5
-6.4
>>> 32 / -5
-6.4

You can also get this behaviour in Python 2.x if you start your script with 'from __future__ import division'.

See the documentation at:

http://docs.python.org/reference/expressions.html#binary-arithmetic-operations

for more.

----------
nosy: +mark.dickinson
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10346>
_______________________________________

From report at bugs.python.org  Sun Nov  7 11:55:55 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 07 Nov 2010 10:55:55 +0000
Subject: [issue10336] test_xmlrpc fails if gzip is not supported by client
In-Reply-To: <1289041038.52.0.266218953067.issue10336@psf.upfronthosting.co.za>
Message-ID: <1289127355.81.0.140597688099.issue10336@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, I cannot. I don't know HTTP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10336>
_______________________________________

From report at bugs.python.org  Sun Nov  7 12:07:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 11:07:55 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289128075.79.0.967786929289.issue10337@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm not sure what can reasonably be done about these failures.  The Python test is failing because of a deficiency in the system math library.

Adding extra code to Python to handle this (making use of TANH_PRESERVES_ZERO_SIGN) is an option, but it seems like overkill to me.

I definitely don't want to remove these tests---they're valuable.  If there's a way of marking the test as an expected failure on NetBSD 5 then that would be fine, I guess.

We should also report the problem upstream.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sun Nov  7 12:17:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 11:17:45 +0000
Subject: [issue10297] decimal module documentation is misguiding
In-Reply-To: <1288780221.67.0.597486897879.issue10297@psf.upfronthosting.co.za>
Message-ID: <1289128665.82.0.19251574573.issue10297@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10297>
_______________________________________

From report at bugs.python.org  Sun Nov  7 12:29:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 11:29:42 +0000
Subject: [issue10297] decimal module documentation is misguiding
In-Reply-To: <1288780221.67.0.597486897879.issue10297@psf.upfronthosting.co.za>
Message-ID: <1289129382.31.0.136814132171.issue10297@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r86286, r86287, r86288.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10297>
_______________________________________

From report at bugs.python.org  Sun Nov  7 12:58:13 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 07 Nov 2010 11:58:13 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1245548191.7.0.718565157283.issue6317@psf.upfronthosting.co.za>
Message-ID: <1289131093.54.0.221771417495.issue6317@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I've committed in r86291(release31-maint).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Sun Nov  7 13:01:15 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 12:01:15 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <1288965372.95.0.322439917087.issue10325@psf.upfronthosting.co.za>
Message-ID: <1289131275.13.0.371820955835.issue10325@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch (against py3k) incorporating your suggestions.  Would you be willing to review?

[Removing Python 2.6 from versions since it's no longer maintained for non-security issues.)

----------
keywords: +patch
versions:  -Python 2.6
Added file: http://bugs.python.org/file19530/issue10325.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Sun Nov  7 13:02:39 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 12:02:39 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <1288965372.95.0.322439917087.issue10325@psf.upfronthosting.co.za>
Message-ID: <1289131359.43.0.119706277347.issue10325@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Added file: http://bugs.python.org/file19531/issue10325.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Sun Nov  7 13:03:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 12:03:00 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <1288965372.95.0.322439917087.issue10325@psf.upfronthosting.co.za>
Message-ID: <1289131380.74.0.485595397598.issue10325@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file19530/issue10325.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Sun Nov  7 13:17:39 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 07 Nov 2010 12:17:39 +0000
Subject: [issue9873] urllib.parse: Allow bytes in some APIs that use string
	literals internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1289132259.65.0.620771892715.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Just a note for myself when I next update the patch: the 2-tuple returned by defrag needs to be turned into a real result type of its own, and the decode/encode methods on result objects should be tested explicitly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Sun Nov  7 13:30:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 12:30:59 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1288754888.21.0.493810987272.issue7652@psf.upfronthosting.co.za>
Message-ID: <AANLkTinwzzie6-4Fxd2tjV-3oPJCmK_fLv8aN-mxF2Az@mail.gmail.com>


Mark Dickinson <dickinsm at gmail.com> added the comment:

On Wed, Nov 3, 2010 at 3:28 AM, Case Van Horsen <report at bugs.python.org> wrote:
> Has the cdecimal branch kept up with the hash value changes in 3.2?

Not sure;  that's a question for Stefan.

> Is there a still a chance that cdecimal could be merged into 3.2?

A chance, yes;  the major need is for someone with time to do a full
review.  (I'm afraid that's not me, right now.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Sun Nov  7 13:39:10 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 07 Nov 2010 12:39:10 +0000
Subject: [issue10027] os.lstat/os.stat don't set st_nlink on Windows
In-Reply-To: <1286289327.29.0.159315245099.issue10027@psf.upfronthosting.co.za>
Message-ID: <1289133550.24.0.241636716264.issue10027@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I found Win32 FileID API. With this library, it seems
we can use GetFileInformationByHandleEx before Vista.
We can get real file name and hard link count from handle.

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1DECC547-AB00-4963-A360-E4130EC079B8&amp;displaylang=en

I don't have a patch, but maybe it is worth to implement it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Sun Nov  7 13:53:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 12:53:33 +0000
Subject: [issue10145] float.is_integer is undocumented
In-Reply-To: <1287488440.57.0.0400472595143.issue10145@psf.upfronthosting.co.za>
Message-ID: <1289134413.22.0.633299688942.issue10145@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r86293, r86394, r86295.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10145>
_______________________________________

From report at bugs.python.org  Sun Nov  7 14:08:20 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 13:08:20 +0000
Subject: [issue10052] Python/dtoa.c:158: #error "Failed to find an exact-width
	32-bit integer type" (FreeBSD 4.11 + gcc 2.95.4)
In-Reply-To: <1286609205.46.0.0704666326351.issue10052@psf.upfronthosting.co.za>
Message-ID: <1289135300.81.0.273406643095.issue10052@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the patch.  This looks fine, in principle.

A couple of comments and questions:

(1) I think the patch should provide *MIN values alongside the *MAX values (for signed types only, of course).

(2) Are we sure that these values are valid on all FreeBSD 4 platforms, or should these definitions be further restricted to Free BSD 4 / x86?

(3) Are the types of the constants definitely correct?  E.g., UINT64_MAX should have type uint64_t.  That gets a bit tricky, since we can't use casts (which would prevent these constants being used in preprocessor #ifs), so we need to determine exactly what basic types uint32_t and uint64_t match, and make sure to use the correct suffix (e.g., ULL, LL, UL, L).  For uint32_t I guess this is easy:  it'll almost certainly be the same type as unsigned int.  Is uint64_t defined as unsigned long long, or as unsigned long?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From report at bugs.python.org  Sun Nov  7 14:22:01 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 07 Nov 2010 13:22:01 +0000
Subject: [issue10226] urlparse example is wrong
In-Reply-To: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>
Message-ID: <1289136121.25.0.718608734675.issue10226@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed the wordings in r86296(py3k), r86297(release31-maint) and r86298(release27-maint).

David, for the examples you mentioned, the first one's parsing logic follows the explanation that is written. It is correct.

For the second example, the port value not being a DIGIT exhibits such a behavior.  I am unable to recollect the reason for this behavior. 
Either the URL is invalid (PORT is not a DIGIT, and parse module is simply ignoring to raise an error - it's okay, given the input is invalid) or it needs to distinguish the ':' as a port separator from path separator for some valid urls.

I think, if we find a better reason to change something for the second scenario, we shall address that.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10226>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:00:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Nov 2010 14:00:55 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289138455.82.0.460943235854.issue10337@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Here is a patch skipping math and cmath tests if TANH_PRESERVES_ZERO_SIGN is 0.

----------
keywords: +patch
Added file: http://bugs.python.org/file19532/skip_tanh_sign.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:11:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Nov 2010 14:11:19 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289139079.36.0.530417092058.issue10337@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file19533/skip_tanh_sign-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:15:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Nov 2010 14:15:42 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289139342.04.0.947617677658.issue10337@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited to Python 3.2 (r86299) after a review of Mark Dickson on IRC. Thanks Mark ;-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:17:27 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 07 Nov 2010 14:17:27 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1289139447.0.0.0127891503828.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'd actually started typing out the command to commit this before it finally clicked that the patch changes public APIs of the pydoc module in incompatible ways. Sure, they aren't documented, but the fact they aren't protected by an underscore means I'm not comfortable with the idea of removing them or radically change their functionality without going through a deprecation period first.

I've attached my version of the patch which includes some additional documentation cleanups and a tweak to test_pyclbr (since the pydoc changes broke that test through no fault of their own).

However, the public (albeit undocumented) nature of the APIs implementing the old Tk GUI means I'm not comfortable committing the patch in a form that simply drops them without going through a deprecation period first.

So, the way forward from here:
1. The good news is beta 1 has been pushed back to December 4 for other reasons, so there's still more time to work on this
2. The gui() function should still open the Tkinter GUI, and the -g option should be retained with its old functionality. Invoking this function should trigger DeprecationWarning.
3. A serve() function to start the web server component should be added back in
4. The new behaviour of opening the web client can be provided as a "browse()" function (that accepts the port number the server is listening on as an argument).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:18:34 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 14:18:34 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289139514.06.0.208145329275.issue10337@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Nice fix!  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:18:35 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 07 Nov 2010 14:18:35 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1289139515.65.0.0105303734349.issue2001@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


Added file: http://bugs.python.org/file19534/issue2001_ncoghlan_cleanup.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:20:50 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 07 Nov 2010 14:20:50 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289139650.6.0.371586862951.issue10337@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

P.S. Greg, as the owner of the buildbot, do you feel like reporting this upstream?  I get the impression that it's easier to do the reporting directly from the NetBSD machine in question...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:25:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Nov 2010 14:25:15 +0000
Subject: [issue10347] regrtest progress counter makes -f option less useful
In-Reply-To: <1289139915.05.0.729238355052.issue10347@psf.upfronthosting.co.za>
Message-ID: <1289139915.05.0.729238355052.issue10347@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The regrtest progress counter ("[  1/350]") is very nice but makes it less practical to use the "-f" option to regrtest.

----------
components: Tests
messages: 120684
nosy: georg.brandl, pitrou
priority: low
severity: normal
status: open
title: regrtest progress counter makes -f option less useful
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10347>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:29:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Nov 2010 14:29:03 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289139650.6.0.371586862951.issue10337@psf.upfronthosting.co.za>
Message-ID: <201011071528.55290.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> P.S. Greg, as the owner of the buildbot, do you feel like reporting this
> upstream?  I get the impression that it's easier to do the reporting
> directly from the NetBSD machine in question...

I already reported the bug upstream: "Thank you for your problem report. You 
should receive confirmation of your problem report and an internal 
identification number by electronic mail in less than 24 hours."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:30:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 07 Nov 2010 14:30:53 +0000
Subject: [issue10347] regrtest progress counter makes -f option less useful
In-Reply-To: <1289139915.05.0.729238355052.issue10347@psf.upfronthosting.co.za>
Message-ID: <1289140253.24.0.459931284878.issue10347@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Right. Let's make -f ignore leading [...] in the file :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10347>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:31:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 07 Nov 2010 14:31:41 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1289140301.64.0.457534109995.issue10329@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, the test failure can reproduced by the following:

$ LANG=C ./python -m test.regrtest test_imp test_trace
[1/2] test_imp
[2/2] test_trace
/home/antoine/py3k/__svn__/Lib/unittest/case.py:402: ResourceWarning: unclosed file <_io.TextIOWrapper name='@test_11986_tmp/os.cover' encoding='ANSI_X3.4-1968'>
  result.addError(self, sys.exc_info())
test test_trace failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_trace.py", line 296, in test_coverage
    self._coverage(tracer)
  File "/home/antoine/py3k/__svn__/Lib/test/test_trace.py", line 291, in _coverage
    r.write_results(show_missing=True, summary=True, coverdir=TESTFN)
  File "/home/antoine/py3k/__svn__/Lib/trace.py", line 334, in write_results
    lnotab, count)
  File "/home/antoine/py3k/__svn__/Lib/trace.py", line 384, in write_results_file
    outfile.write(line.expandtabs(8))
UnicodeEncodeError: 'ascii' codec can't encode character '\xa0' in position 5: ordinal not in range(128)

1 test OK.
1 test failed:
    test_trace


There's a strange interaction between test_imp and test_trace, it seems. Not sure why.

----------
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:38:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Nov 2010 14:38:55 +0000
Subject: [issue10337] testTanh() of test_math fails on "NetBSD 5 i386 3.x"
In-Reply-To: <1289041435.79.0.181491237155.issue10337@psf.upfronthosting.co.za>
Message-ID: <1289140735.28.0.981909022625.issue10337@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

NetBSD bug report: http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=44057

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10337>
_______________________________________

From report at bugs.python.org  Sun Nov  7 15:49:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Nov 2010 14:49:30 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1289141370.89.0.645495029601.issue9561@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue might be splitted in multiple issue: one issue per file type (eg. Makefile, RPM spec file, etc.).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Sun Nov  7 16:54:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Nov 2010 15:54:58 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1289145298.67.0.0839554047039.issue10329@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

$ LANG=C ./python -m test.regrtest test_imp test_trace
[1/2] test_imp
[2/2] test_trace
...
UnicodeEncodeError: 'ascii' codec can't encode character '\xa0' in position 5: ordinal not in range(128)

issue10329.diff fixes this failure. The failure comes from a nonbreaking space introduced by myself by error in Lib/os.py, which is the only non-ASCII character in this file. r86302 removes it.

I commited issue10329.diff to Python 3.2 as r86303: thanks Alex ;-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Sun Nov  7 16:56:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 07 Nov 2010 15:56:12 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1289145372.69.0.511925195489.issue10342@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited Alexander's fix for #10329: r86303. The trace module now uses the input Python script encoding, instead of the locale encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Sun Nov  7 17:07:01 2010
From: report at bugs.python.org (=?utf-8?q?Ren=C3=A9_Liebscher?=)
Date: Sun, 07 Nov 2010 16:07:01 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1289146021.87.0.0920503645176.issue2001@psf.upfronthosting.co.za>


Ren? Liebscher <R.Liebscher at gmx.de> added the comment:

What about http://bugs.python.org/issue2001#msg114326 ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Sun Nov  7 23:46:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 07 Nov 2010 22:46:43 +0000
Subject: [issue6317] winsound.PlaySound doesn't accept non-unicode string
In-Reply-To: <1289126781.02.0.82769715204.issue6317@psf.upfronthosting.co.za>
Message-ID: <4CD71418.8080803@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Is this also applied to *all* ANSI Win32 API
> in other sources?

No. I think there are backwards compatibility concerns in some of the
APIs, so this must be discussed on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6317>
_______________________________________

From report at bugs.python.org  Mon Nov  8 00:56:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 07 Nov 2010 23:56:03 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1289174163.42.0.090002162835.issue10329@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Reopening as a reminder to add a unit test for this case.

----------
stage: needs patch -> unit test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Mon Nov  8 01:00:24 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Mon, 08 Nov 2010 00:00:24 +0000
Subject: [issue775964] fix test_grp failing when NIS entries present
Message-ID: <1289174424.96.0.705883355268.issue775964@psf.upfronthosting.co.za>


Bobby Impollonia <bobbyi at gmail.com> added the comment:

Martin, are you able to check in this fix? If not, what should I do and whom should I talk to so this can be checked in?

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775964>
_______________________________________

From report at bugs.python.org  Mon Nov  8 01:02:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 08 Nov 2010 00:02:24 +0000
Subject: [issue775964] fix test_grp failing when NIS entries present
Message-ID: <1289174544.51.0.900521245796.issue775964@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm able to, but I may not find time. Ask on python-dev; if you feel you need to push this, offer to review issues in return.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775964>
_______________________________________

From report at bugs.python.org  Mon Nov  8 01:04:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Nov 2010 00:04:41 +0000
Subject: [issue10347] regrtest progress counter makes -f option less useful
In-Reply-To: <1289139915.05.0.729238355052.issue10347@psf.upfronthosting.co.za>
Message-ID: <1289174681.73.0.935089209022.issue10347@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r86307.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10347>
_______________________________________

From report at bugs.python.org  Mon Nov  8 01:19:11 2010
From: report at bugs.python.org (Jessica McKellar)
Date: Mon, 08 Nov 2010 00:19:11 +0000
Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1289175551.35.0.616916278933.issue5066@psf.upfronthosting.co.za>


Jessica McKellar <jesstess at mit.edu> added the comment:

Attached is a patch updating the IDLE web documentation as well as the help file displayed when you click the Help -> Idle Help menu item in IDLE. It looks like the IDLE web documentation was lifted directly from the help file at some point and they have gotten out of sync.

The section of the document describing starting IDLE was updated in March of 2009, so I've left that alone. I've updated the Menu option descriptions in both files, including: adding missing items, making the help file and web document descriptions the same, and using a consistent format.

The patch is against release27-maint.

----------
keywords: +patch
nosy: +jesstess
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0
Added file: http://bugs.python.org/file19535/issue5066.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5066>
_______________________________________

From report at bugs.python.org  Mon Nov  8 02:12:56 2010
From: report at bugs.python.org (Kent Johnson)
Date: Mon, 08 Nov 2010 01:12:56 +0000
Subject: [issue10303] small inconsistency in tutorial
In-Reply-To: <1288830081.73.0.485204964128.issue10303@psf.upfronthosting.co.za>
Message-ID: <1289178776.5.0.580896427331.issue10303@psf.upfronthosting.co.za>


Kent Johnson <kent at kentsjohnson.com> added the comment:

Attached patch deletes the referenced sentence.

----------
keywords: +patch
nosy: +kjohnson
Added file: http://bugs.python.org/file19536/issue10303.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10303>
_______________________________________

From report at bugs.python.org  Mon Nov  8 02:26:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Nov 2010 01:26:32 +0000
Subject: [issue1602] windows console doesn't print utf8 (Py30a2)
In-Reply-To: <1197453390.87.0.813702844893.issue1602@psf.upfronthosting.co.za>
Message-ID: <1289179592.47.0.0520616207903.issue1602@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't understand exactly the goal of this issue. Different people described various bugs of the Windows console, but I don't see any problem with Python here. It looks like it's just not possible to display correctly unicode with the Windows console (the whole unicode charset, not the current code page subset).

- 65001 code page: it's not the same encoding than utf-8 and so it cannot be set as an alias to utf-8 (see #6058) => nothing to do, or maybe document that PYTHONIOENCODING=utf-8 workaround... But if you do that, you may get strange errors when writing to stdout or stderr like "IOError: [Errno 13] Permission denied" or "IOError: [Errno 2] No such file or directory" ...
- chcp command sets the console encoding, which is stupid because the console still expects text encoded to the previous code page => Windows (chcp command) bug, chcp command should not be used (it doesn't solve any problem, it just makes the situation worse)
- use the console API instead of read()/write() to fix this issue: it doesn't work, the console is completly buggy (msg120414) => Windows (console) bug
- use "Lucida Console" font avoids some issue => I don't think that the Python interpreter should configure the console (using SetCurrentConsoleFontEx?), it's not the role of Python

To me, there is nothing to do, and so I close the bug.

If you would like to fix a particular Python bug, open a new specific issue. If you consider that I'm wrong, Python should fix this issue and you know how, please reopen it.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1602>
_______________________________________

From report at bugs.python.org  Mon Nov  8 02:32:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 08 Nov 2010 01:32:29 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1289179949.97.0.506698613746.issue10342@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a "proof of concept" patch.  The trace code is in a dire need of restructuring to eliminate repeated reading of source files.

----------
keywords: +needs review, patch
nosy: +eli.bendersky, terry.reedy
stage: unit test needed -> patch review
Added file: http://bugs.python.org/file19537/issue10342.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Mon Nov  8 02:37:36 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 08 Nov 2010 01:37:36 +0000
Subject: [issue10316] tkFileDialog.askopenfilenames scrambling multiple file
	selection
In-Reply-To: <1288904171.11.0.911089821654.issue10316@psf.upfronthosting.co.za>
Message-ID: <1289180256.21.0.268915313979.issue10316@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Postscript: I've subsequently noticed Issue5712 in which somewhat similar symptoms are reported but, so far, only on Windows systems.  If your problem is not yet resolved, you might want to chime in there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10316>
_______________________________________

From report at bugs.python.org  Mon Nov  8 02:41:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 08 Nov 2010 01:41:38 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1289180498.43.0.572854479495.issue10342@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Mon Nov  8 02:47:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Nov 2010 01:47:16 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1289180836.84.0.156023568366.issue10342@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

+            try:
+                with open(filename, 'rb') as fp:
+                    encoding, _ = tokenize.detect_encoding(fp.readline)
+            except IOError:
+                encoding = None

You should use 'utf-8' instead of None (which will fall back to the locale encoding) here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Mon Nov  8 02:57:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 08 Nov 2010 01:57:28 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289180836.84.0.156023568366.issue10342@psf.upfronthosting.co.za>
Message-ID: <AANLkTikc-kZ+j1gssBVT1=rbuh7pNtikz+w9oXaZZW=+@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 7, 2010 at 8:47 PM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
> + ? ? ? ? ? ?try:
> + ? ? ? ? ? ? ? ?with open(filename, 'rb') as fp:
> + ? ? ? ? ? ? ? ? ? ?encoding, _ = tokenize.detect_encoding(fp.readline)
> + ? ? ? ? ? ?except IOError:
> + ? ? ? ? ? ? ? ?encoding = None
>
> You should use 'utf-8' instead of None (which will fall back to the locale encoding) here.
>

I know.  I was too lazy to look up the correct spelling for the proof
of concept.  I am really posting this patch to show how this bug can
be fixed in theory and discuss how much of refactoring is acceptable.
For example, do we need to preserve trace.find_strings() function?
What is the best way to pass around source code? - file-like objects,
line iterators, readline-like function?  Also compile(prog, filename,
"exec") to find module's bytecode is a hack.  There must be a standard
way to achieve that which would use a .pyc file if available.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Mon Nov  8 02:57:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Nov 2010 01:57:39 +0000
Subject: [issue10348] multiprocessing: use SYSV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Support POSIX semaphore on FreeBSD is recent, optional (eg. disabled by default in FreeBSD 7) and limited (30 semaphores). SYSV should be used instead because they are less limited or more adjustable (at runtime: POSIX semaphore requires to recompile the kernel!).

This issue should fix test_concurrent_futures on FreeBSD 7.2 and 8.0: many tests use more than 30 semaphores. The maximum is test_all_completed_some_already_completed: 52 semaphores.

----------
components: Library (Lib)
keywords: buildbot
messages: 120705
nosy: db3l, haypo
priority: normal
severity: normal
status: open
title: multiprocessing: use SYSV semaphores on FreeBSD
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10348>
_______________________________________

From report at bugs.python.org  Mon Nov  8 02:57:53 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 08 Nov 2010 01:57:53 +0000
Subject: [issue10303] small inconsistency in tutorial
In-Reply-To: <1288830081.73.0.485204964128.issue10303@psf.upfronthosting.co.za>
Message-ID: <1289181473.5.0.859372344423.issue10303@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r86310. print was used in some examples following its mention, so a simple introduction to it was okay. It is introduced properly further down in the tutorial.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10303>
_______________________________________

From report at bugs.python.org  Mon Nov  8 02:59:25 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 08 Nov 2010 01:59:25 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1289181565.06.0.986097998457.issue10342@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The handling of __loader__ looks fine to me, although I don't quite see the point of the get_source call as it isn't returned or used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Mon Nov  8 03:03:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 08 Nov 2010 02:03:33 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289181565.06.0.986097998457.issue10342@psf.upfronthosting.co.za>
Message-ID: <AANLkTik9_hufNnKwwvEC2+gs+ZjbqtNTEjKLf27XK8R7@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 7, 2010 at 8:59 PM, Brett Cannon <report at bugs.python.org> wrote:

> .. I don't quite see the point of the get_source call as it isn't returned or used.

It is passed to find_docstrings() to produce the "strs" dictionary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Mon Nov  8 03:35:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Nov 2010 02:35:43 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1289183743.78.0.837530403139.issue10348@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

It looks like SysV semaphores are also preferred on Darwin. So I suppose that Mac OS X would also benefit of this issue. Maybe also other OSes (Solaris?).

See also issue #7272.

----------
nosy: +jnoller
title: multiprocessing: use SYSV semaphores on FreeBSD -> multiprocessing: use SysV semaphores on FreeBSD

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10348>
_______________________________________

From report at bugs.python.org  Mon Nov  8 03:37:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Nov 2010 02:37:28 +0000
Subject: [issue10226] urlparse example is wrong
In-Reply-To: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>
Message-ID: <1289183848.54.0.770619572048.issue10226@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Senthil, no it isn't.  There is no way to know a priori that ':80' represents a port number rather than a path, absent the // introducer for the netloc.

This bug is fixed; I ought to open a new one for the path thing but perhaps I will wait for a user report instead :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10226>
_______________________________________

From report at bugs.python.org  Mon Nov  8 04:53:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Nov 2010 03:53:03 +0000
Subject: [issue10308] Modules/getpath.c bugs
In-Reply-To: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za>
Message-ID: <1289188383.35.0.82373707.issue10308@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

3.2a3 chunk#2 cannot fail because PyUnicode_AsWideChar() only returns -1 if the first argument is NULL, whereas we just checked that decoded is not NULL. But it would be better to fix the variable type to avoid future bugs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10308>
_______________________________________

From report at bugs.python.org  Mon Nov  8 05:11:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Nov 2010 04:11:52 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1289189512.32.0.346021503816.issue6058@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Different tests proved that cp65001 can *not* be set as an alias to utf-8, and that's why I'm closing this issue.

Anyway, I don't think that cp65001 is configured by default on any Windows setup. It is only set by the user, using the chcp command, to try to display unicode characters in the Windows console: but it is not possible to display any unicode character in this console (see issue #1602). And chcp command should not be used in the Windows console because it does not only change the ANSI code page: it changes also the console code page, which is wrong (the console still expect text encoded to the previous code page).

It is possible to implement a codec for cp65001 using utf-8 existing codec in surrogatepass mode, or by using MultiByteToWideChar() / WideCharToMultiByte() with codepage=CP_UTF8. But I don't think that we need cp65001 at all.

If you need cp65001 for a good reason and you would like to implement a cp65001 Python codec, open a new issue.

If you consider that we should use _O_U8TEXT or  _O_U16TEXT, open another new issue.

_O_U8TEXT or  _O_U16TEXT might improve unicode support if Python output is redirected to a pipe, but I don't think that it would help to display unicode character in the Windows console. I also fear that it breaks existing code and any function not aware of this special mode.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Mon Nov  8 06:10:26 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 08 Nov 2010 05:10:26 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1289193026.4.0.572429510623.issue2986@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Adding a documentation patch for 3.1 which is similar to the 2.6 documentation patch that's been committed by Georg into 2.6

----------
Added file: http://bugs.python.org/file19538/issue2986.docs31.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Mon Nov  8 07:21:07 2010
From: report at bugs.python.org (Jeong-Min Lee)
Date: Mon, 08 Nov 2010 06:21:07 +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: <1289197267.96.0.632845964813.issue1195@psf.upfronthosting.co.za>


Changes by Jeong-Min Lee <falsetru at gmail.com>:


----------
nosy: +falsetru

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Mon Nov  8 07:52:23 2010
From: report at bugs.python.org (Prabhu Gurumurthy)
Date: Mon, 08 Nov 2010 06:52:23 +0000
Subject: [issue10349] Error in Module/python.c when building on OpenBSD 4.8
In-Reply-To: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>
Message-ID: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>


New submission from Prabhu Gurumurthy <pgurumu at gmail.com>:

When manually building on OpenBSD 4.8 using gcc 4.2.1, I got the following error:

g++ -pthread -c -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I/usr/home/pgurumur/temp/Python-3.1.2/Include -DTHREAD_STACK_SIZE=0x20000 -fPIC -I/usr/include  -DPy_BUILD_CORE -o Modules/python.o /usr/home/pgurumur/temp/Python-3.1.2/Modules/python.ccc1plus: warning: command line option "-Wstrict-prototypes" is valid for C/ObjC but not for C++/usr/home/pgurumur/temp/Python-3.1.2/Modules/python.c: In function 'wchar_t* char2wchar(char*)':/usr/home/pgurumur/temp/Python-3.1.2/Modules/python.c:60: error: invalid conversion from 'void*' to 'wchar_t*'*** Error code 1

I changed line 60 from:
res = PyMem_Malloc(argsize*sizeof(wchar_t));

to:
res = (wchar_t *)PyMem_Malloc(argsize*sizeof(wchar_t));

I was able to compile it successfully, another thing you would notice is that, -Wstrict-prototypes is not a valid option with g++, (just a warning though)

My configure options:

 /usr/home/pgurumur/temp/Python-3.1.2/configure --with-fpectl --with-threads --srcdir=/usr/home/pgurumur/temp/Python-3.1.2 --enable-ipv6 --enable-shared --with-cxx_main --with-signal-module --prefix=/opt/local

----------
components: Build
messages: 120714
nosy: pgurumur
priority: normal
severity: normal
status: open
title: Error in Module/python.c when building on OpenBSD 4.8
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10349>
_______________________________________

From report at bugs.python.org  Mon Nov  8 08:33:40 2010
From: report at bugs.python.org (Bill Barrett)
Date: Mon, 08 Nov 2010 07:33:40 +0000
Subject: [issue10217] python-2.7.amd64.msi install fails
In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>
Message-ID: <1289201620.18.0.512662478776.issue10217@psf.upfronthosting.co.za>


Bill Barrett <stareagyl at gmail.com> added the comment:

Same problem here. I also tried command line launch and get the same warning dialog as I got by clicking Firefox Download.  My install "seems" to basically work however.  I used Task Manager to kill the Install Application to avoid unrolling the installation.

----------
nosy: +Bill.Barrett
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10217>
_______________________________________

From report at bugs.python.org  Mon Nov  8 08:59:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 08 Nov 2010 07:59:00 +0000
Subject: [issue10349] Error in Module/python.c when building on OpenBSD 4.8
In-Reply-To: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>
Message-ID: <1289203140.13.0.736671109242.issue10349@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Out of curiosity: why are you building with --with-cxx_main?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10349>
_______________________________________

From report at bugs.python.org  Mon Nov  8 09:03:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 08 Nov 2010 08:03:07 +0000
Subject: [issue10217] python-2.7.amd64.msi install fails
In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>
Message-ID: <1289203387.03.0.119820241155.issue10217@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

IIUC, Manfred's pythonInstallLog.zip is now from a successful installation, so it is unfortunately of little help. We really would need a log of a failed installation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10217>
_______________________________________

From report at bugs.python.org  Mon Nov  8 09:35:37 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 08 Nov 2010 08:35:37 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <1289131275.13.0.371820955835.issue10325@psf.upfronthosting.co.za>
Message-ID: <hbf.20101108ho75@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Mark Dickinson writes:
> Here's a patch (against py3k) incorporating your suggestions.  Would you
> be willing to review?

Looks fine to me.  (Actually the gcc branch makes the same assumptions
as the final branch, but then I expect gcc itself does too.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Mon Nov  8 09:48:18 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 08 Nov 2010 08:48:18 +0000
Subject: [issue10350] errno is read too late
In-Reply-To: <1289206098.51.0.17539694799.issue10350@psf.upfronthosting.co.za>
Message-ID: <1289206098.51.0.17539694799.issue10350@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

errno is sometimes read too late after the error:  After another call
may have modified it.  Here's a patch against py3k.  Most of it or a
variant applies to 2.7 too, but I haven't really looked at that.

I've not looked at math code, where I don't even know what sets errno.

There might also be a late errno read at Modules/_ctypes/callproc.c
line 794: "space[0] = errno;".  Does it want the errno from before
_ctypes_get_errobj()?  I'm unsure what's going on there.

Modules/_multiprocessing/semaphore.c doesn't need the patch's extra
variable, it can instead be rearranged with the commented-out patch.

----------
components: None
files: late-errno.diff
keywords: patch
messages: 120719
nosy: hfuru
priority: normal
severity: normal
status: open
title: errno is read too late
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19539/late-errno.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10350>
_______________________________________

From report at bugs.python.org  Mon Nov  8 10:11:33 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 08 Nov 2010 09:11:33 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <hbf.20101106g37z@bombur.uio.no>
Message-ID: <hbf.20101108ibg2@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

I wrote:
>> BTW, do you know of any modern non-Windows platforms that don't define
>> LLONG_MIN and LLONG_MAX?  It may well be that the "two's complement"
>> fallback hasn't been exercised in recent years.
> 
> Anyting compiled with strict ANSI pre-C99 mode, e.g. gcc -ansi, (...)

which also disables 'long long', so such examples are moot.  duh.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Mon Nov  8 10:22:40 2010
From: report at bugs.python.org (Valery Khamenya)
Date: Mon, 08 Nov 2010 09:22:40 +0000
Subject: [issue10351] to introduce autocompletion for keys in dictionaries
	(patch attached)
In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>
Message-ID: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>


New submission from Valery Khamenya <khamenya at gmail.com>:

1. The patch introduces autocompletion for keys in dictionaries (patch attached)

2. The patched rlcompleter as such works OK for unicode dictionary keys as well. All tests pass OK. HOWEVER, readline's completion mechanism seem to be confused with unicode strings -- see comments to Completer.dict_key_matches(). So, perhaps, one day some changes should be applied to readline code too.

3. rlcompleter.py has no tests in trunk -- I spawn a separate issue for it. Meanwhile I took test_rlcompleter.py from 2.7 and extended it.

4. The following usual lines in .pythonstartup:
import readline
import rlcompleter
readline.parse_and_bind('tab: complete')
readline.parse_and_bind('Control-Space: complete')

should be extended by this one:
readline.set_completer_delims(re.compile(r'[\'"\\[]').sub('', readline.get_completer_delims()))

----------
components: Library (Lib)
files: rlcompleter-dict-keys-autocompletion.tar.gz
messages: 120721
nosy: Valery.Khamenya
priority: normal
severity: normal
status: open
title: to introduce autocompletion for keys in dictionaries (patch attached)
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19540/rlcompleter-dict-keys-autocompletion.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10351>
_______________________________________

From report at bugs.python.org  Mon Nov  8 10:27:43 2010
From: report at bugs.python.org (Valery Khamenya)
Date: Mon, 08 Nov 2010 09:27:43 +0000
Subject: [issue10352] rlcompleter.py has no tests in trunk
In-Reply-To: <1289208463.71.0.79566317851.issue10352@psf.upfronthosting.co.za>
Message-ID: <1289208463.71.0.79566317851.issue10352@psf.upfronthosting.co.za>


New submission from Valery Khamenya <khamenya at gmail.com>:

rlcompleter.py has no test_rlcompleter in trunk, see http://svn.python.org/view/python/trunk/Lib/test/
There is one in 2.7 though.

Remark: the issue http://bugs.python.org/issue10351 introduces autocompletion patch and comes with new tests. So, one may want to use it as for up-to-date test_rlcompleter.py, given the issue #10351 is accepted ;-)

----------
components: Library (Lib), Tests
messages: 120722
nosy: Valery.Khamenya
priority: normal
severity: normal
status: open
title: rlcompleter.py has no tests in trunk
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10352>
_______________________________________

From report at bugs.python.org  Mon Nov  8 10:41:11 2010
From: report at bugs.python.org (Ron Adam)
Date: Mon, 08 Nov 2010 09:41:11 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1289209271.24.0.902315896878.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

> What about http://bugs.python.org/issue2001#msg114326 ?

Thanks for the reminder.


To Nick:

>However, the public (albeit undocumented) nature of the APIs >implementing the old Tk GUI means I'm not comfortable committing the >patch in a form that simply drops them without going through a >deprecation period first.

I think it would be ok sense this is a 'user' interface rather than a programming interface, but it won't hurt to ask specifically about this on python dev.  I got the impression that pydoc is considered a 'user' tool like idle, that just happens to live in lib, so the rules aren't considered to be quite as strict as it would be if it was a module meant to be used by other modules or programs.


>3. A serve() function to start the web server component should be >added back in

There is a _startserver() function.  The leading  underscore can be removed, or it can be renamed to serve.  A serve() function could also just call _startserver().


>2. The gui() function should still open the Tkinter GUI,
>and the -g option should be retained with its old functionality. >Invoking this function should trigger DeprecationWarning.
>
>4. The new behaviour of opening the web client can be provided
>as a "browse()" function (that accepts the port number the
>server is listening on as an argument).


After the patch the gui() function starts the server with a server text command window, and opens the browser to the correct page.  If you close the browser, you can use 'b' at the server prompt to reopen the browser at the address it is serving.

It sounds like you want "serve()" to just start the server. and "browse()" to just start the browser.  The gui() function does both in one step.

What would be the equivalent new way of doing both in one step, if gui() retains the old tk behavior?

Cheers, Ron

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Mon Nov  8 11:10:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Nov 2010 10:10:02 +0000
Subject: [issue10352] rlcompleter.py has no tests in trunk
In-Reply-To: <1289208463.71.0.79566317851.issue10352@psf.upfronthosting.co.za>
Message-ID: <1289211002.59.0.103112504208.issue10352@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

trunk is no longer active.  The real "trunk" is the py3k branch, which does have test_rlcompleter.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10352>
_______________________________________

From report at bugs.python.org  Mon Nov  8 11:42:18 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Mon, 08 Nov 2010 10:42:18 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1289212938.44.0.401999020635.issue10329@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

Using the original encoding of the Python source file might be the politically correct thing to do, but it complicates handling of the output of trace.py. For each file you have to do the encoding detection dance again. It would be great if I could specify which encoding trace.py use (with the files encoding being the default).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Mon Nov  8 11:48:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Nov 2010 10:48:17 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1288969298.32.0.515004183172.issue10329@psf.upfronthosting.co.za>
Message-ID: <1289213297.51.0.299688121399.issue10329@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> ... it complicates handling of the output of trace.py. 
> For each file you have to do the encoding detection dance again ...

What? You just have to call one function! tokenize.open() :-) Well, ok, it's not commited yet, but it looks like most people agree: #10335.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Mon Nov  8 11:58:43 2010
From: report at bugs.python.org (Weeble)
Date: Mon, 08 Nov 2010 10:58:43 +0000
Subject: [issue2304] subprocess under windows fails to quote properly
	when	shell=True
In-Reply-To: <1205685138.96.0.183811169845.issue2304@psf.upfronthosting.co.za>
Message-ID: <1289213923.54.0.0789267279027.issue2304@psf.upfronthosting.co.za>


Weeble <clockworksaint at gmail.com> added the comment:

Is there any way to write code that's safe with or without this fix? If I have code that currently does this:

subprocess.check_call('""c:\some path with spaces" arg1 arg2 "a quoted arg""', shell=True)

...will it break when running on a version of Python with this fix? Is there any good way to detect whether the running Python has this fix or not?

----------
nosy: +weeble

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2304>
_______________________________________

From report at bugs.python.org  Mon Nov  8 12:03:43 2010
From: report at bugs.python.org (Peter)
Date: Mon, 08 Nov 2010 11:03:43 +0000
Subject: [issue10353] 2to3 and places argument in unitests assertAlmostEqual
In-Reply-To: <1289214223.54.0.6247578407.issue10353@psf.upfronthosting.co.za>
Message-ID: <1289214223.54.0.6247578407.issue10353@psf.upfronthosting.co.za>


New submission from Peter <p.j.a.cock at googlemail.com>:

Consider the following example unit test using assertAlmostEqual which uses the places argument as a positional argument, call this places.py:

import unittest
class Tests(unittest.TestCase):
    def test_equal_to_five_decimal_places(self):
        """Check assertAlmostEqual using decimal places"""
        self.assertAlmostEqual(0.123456789, 0.123456, 5)
if __name__ == "__main__":
    runner = unittest.TextTestRunner(verbosity = 2)
    unittest.main(testRunner=runner)



This works fine with Python 2.6.6 (Linux),

$ python2.6 places.py
Check assertAlmostEqual using decimal places ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK




Trying 2to3 on it reports no changes needed:

$ 2to3 places.py
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
RefactoringTool: No changes to places.py
RefactoringTool: Files that need to be modified:
RefactoringTool: places.py


Trying the test as is under Python 3.1.2 (Linux) fails:

$ python3.1 places.py
test_equal_to_five_decimal_places (__main__.Tests)
Check assertAlmostEqual using decimal places ... ERROR

======================================================================
ERROR: test_equal_to_five_decimal_places (__main__.Tests)
Check assertAlmostEqual using decimal places
----------------------------------------------------------------------
Traceback (most recent call last):
  File "places.py", line 5, in test_equal_to_five_decimal_places
    self.assertAlmostEqual(0.123456789, 0.123456, 5)
TypeError: assertAlmostEqual() takes exactly 3 positional arguments (4 given)

----------------------------------------------------------------------
Ran 1 test in 0.001s

FAILED (errors=1)


The test can be fixed to run on Python 3.1 (any Python 2.6) by supplying the places argument by name:


import unittest
class Tests(unittest.TestCase):
    def test_equal_to_five_decimal_places(self):
        """Check assertAlmostEqual using decimal places"""
        self.assertAlmostEqual(0.123456789, 0.123456, places=5)
if __name__ == "__main__":
    runner = unittest.TextTestRunner(verbosity = 2)
    unittest.main(testRunner=runner)


Note http://docs.python.org/library/unittest.html does not explicitly discuss passing places by name vs position. On the other hand, http://docs.python.org/py3k/library/unittest.html explicitly shows the by name form only.

I think the 2to3 script needs to be extended to use the places argument by name.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 120728
nosy: maubp
priority: normal
severity: normal
status: open
title: 2to3 and places argument in unitests assertAlmostEqual
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/issue10353>
_______________________________________

From report at bugs.python.org  Mon Nov  8 12:28:15 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 11:28:15 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

>>> import tempfile
>>> tempfile.template = 'XXX'
>>> tempfile.mkdtemp()
'/tmp/tmpPf5lML'
>>>

Functions that use template use it as an argument default, so changing it afterwards has no effect.

----------
components: Library (Lib)
messages: 120729
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: tempfile.template is broken
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Mon Nov  8 12:33:25 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 11:33:25 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289216005.49.0.517041849355.issue10354@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch in attachment.

----------
keywords: +patch
Added file: http://bugs.python.org/file19541/tempfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Mon Nov  8 12:40:26 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 08 Nov 2010 11:40:26 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1289216426.75.0.456243272271.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, I'll ask for feedback on python-dev regarding the API breakage.

If we decide not to break the existing API, I'd suggest the following:

- keep both the old serve() and the old gui() (with DeprecationWarning added to both) (I'd forgotten your point in the previous python-dev thread that gui() would need changes to work with the new server, which isn't worth the hassle)

- use _startserver(port=0) and _browse(port, *, start=False) for the new components (with the -b option invoking _browse with start=True)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Mon Nov  8 12:44:37 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 08 Nov 2010 11:44:37 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289216677.4.0.23658742247.issue10354@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The patch looks good to me, but it needs a test.

----------
nosy: +eric.smith
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Mon Nov  8 12:52:56 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 08 Nov 2010 11:52:56 +0000
Subject: [issue10228] Refleak run of test_dbm fails when several dbm modules
	are available
In-Reply-To: <1288347112.92.0.717435942769.issue10228@psf.upfronthosting.co.za>
Message-ID: <1289217176.27.0.741239014086.issue10228@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/issue10228>
_______________________________________

From report at bugs.python.org  Mon Nov  8 12:53:51 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 08 Nov 2010 11:53:51 +0000
Subject: [issue10327] Abnormal SSL timeouts when using socket timeouts - once
	again
In-Reply-To: <1288967513.64.0.717673746201.issue10327@psf.upfronthosting.co.za>
Message-ID: <1289217231.25.0.21509444521.issue10327@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Allright, it actually looks more like a pathological latency behaviour of my target platforms than a ssl bug... 
I was mislead by the heavy history of socket.settimeout(), sorry. >_<

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10327>
_______________________________________

From report at bugs.python.org  Mon Nov  8 13:04:59 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 12:04:59 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289217899.27.0.314434224421.issue10354@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Patch including tests is in attachment.
I think I've just found two further bugs though:


>>> tempfile.TemporaryFile().name
'<fdopen>'
>>> tempfile.TemporaryFile(prefix='xxx').name
'<fdopen>'
>>> tempfile.SpooledTemporaryFile().name
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/giampaolo/svn/python-2.7/Lib/tempfile.py", line 574, in name
    return self._file.name
AttributeError: 'cStringIO.StringO' object has no attribute 'name'

I'm going to open two separate tickets.

----------
Added file: http://bugs.python.org/file19542/tempfile.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Mon Nov  8 13:07:09 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 12:07:09 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289218029.65.0.00170556994445.issue10354@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Adding georg.brandl to nosy list as per misc/maintainers.rst.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Mon Nov  8 13:14:02 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 12:14:02 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

>>> import tempfile
>>> tempfile.SpooledTemporaryFile().name
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/giampaolo/svn/python-2.7/Lib/tempfile.py", line 574, in name
    return self._file.name
AttributeError: 'cStringIO.StringO' object has no attribute 'name'

----------
messages: 120736
nosy: georg.brandl, giampaolo.rodola
priority: normal
severity: normal
status: open
title: SpooledTemporaryFile's name property is broken
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10355>
_______________________________________

From report at bugs.python.org  Mon Nov  8 13:23:13 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 12:23:13 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289218993.11.0.537015845078.issue10354@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Created issue 10355 for SpooledTemporaryFile bug while TemporaryFile having no name seems to be rightful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Mon Nov  8 13:34:03 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 08 Nov 2010 12:34:03 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

When the __hash__ method is called directly, the hash of -1
is -1:

>>> from decimal import *
>>> Decimal(-1).__hash__()
-1
>>> hash(Decimal(-1))
-2


I've a patch, which also sneaks in a ValueError.

----------
components: Library (Lib)
files: decimal_hash.patch
keywords: needs review, patch
messages: 120738
nosy: mark.dickinson, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: decimal.py: hash of -1
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19543/decimal_hash.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Mon Nov  8 14:16:27 2010
From: report at bugs.python.org (Fergal Daly)
Date: Mon, 08 Nov 2010 13:16:27 +0000
Subject: [issue10357] ** and "mapping" are poorly defined in python docs
In-Reply-To: <1289222187.72.0.886873143688.issue10357@psf.upfronthosting.co.za>
Message-ID: <1289222187.72.0.886873143688.issue10357@psf.upfronthosting.co.za>


New submission from Fergal Daly <fergald at gmail.com>:

According to the index, the only place that mentions ** in argument lists is

http://docs.python.org/tutorial/controlflow.html#index-1099

and gives no indication of what an object must support to allow **.

When you attempt to ** an object the real attribute exception is suppressed and you get a message

"argument after ** must be a mapping"

"mapping" is quite loosely defined. There are 3 definitions, the glossary entry seems the most complete

http://docs.python.org/library/stdtypes.html#index-625
http://docs.python.org/reference/datamodel.html#index-842
http://docs.python.org/glossary.html#term-mapping

But even the glossary entry doesn't tell you what you need for **.

Only by reading the C source code did I discover that to be usable in **, an object must implement .keys() and .__getitem__().

The docs either should add .keys() to the definition of mapping or the code should use some other term or simply allow the original exception to reach the user.

----------
assignee: docs at python
components: Documentation
messages: 120739
nosy: Fergal.Daly, docs at python
priority: normal
severity: normal
status: open
title: ** and "mapping" are poorly defined in python docs
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10357>
_______________________________________

From report at bugs.python.org  Mon Nov  8 14:22:13 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 13:22:13 +0000
Subject: [issue10357] ** and "mapping" are poorly defined in python docs
In-Reply-To: <1289222187.72.0.886873143688.issue10357@psf.upfronthosting.co.za>
Message-ID: <1289222533.94.0.694593241237.issue10357@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/issue10357>
_______________________________________

From report at bugs.python.org  Mon Nov  8 14:23:08 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 13:23:08 +0000
Subject: [issue10350] errno is read too late
In-Reply-To: <1289206098.51.0.17539694799.issue10350@psf.upfronthosting.co.za>
Message-ID: <1289222588.33.0.698198902754.issue10350@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/issue10350>
_______________________________________

From report at bugs.python.org  Mon Nov  8 14:37:22 2010
From: report at bugs.python.org (Peter Hall)
Date: Mon, 08 Nov 2010 13:37:22 +0000
Subject: [issue5712] tkinter - askopenfilenames returns string instead of
	tuple in windows 2.6.1 release
In-Reply-To: <1239039911.64.0.172824576559.issue5712@psf.upfronthosting.co.za>
Message-ID: <1289223442.42.0.66781636567.issue5712@psf.upfronthosting.co.za>


Peter Hall <Peter.F.Hall at nasa.gov> added the comment:

There seems some similarity between this issue and issue #10316 which occurs on Linux.

----------
nosy: +pfhall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5712>
_______________________________________

From report at bugs.python.org  Mon Nov  8 14:48:06 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 08 Nov 2010 13:48:06 +0000
Subject: [issue10358] Doc styles for print should only use dark colors
In-Reply-To: <1289224086.88.0.0372722217541.issue10358@psf.upfronthosting.co.za>
Message-ID: <1289224086.88.0.0372722217541.issue10358@psf.upfronthosting.co.za>


New submission from Fred L. Drake, Jr. <fdrake at acm.org>:

The HTML version of the documentation should include style settings for printing that use fairly dark colors, so that printed copies of pages are more readable.

Using a printer that reduces colors to grays causes the light colors in code examples (or inlined references to classes and the like) to nearly drop out, making the result very painful to read.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 120741
nosy: docs at python, fdrake
priority: normal
severity: normal
stage: needs patch
status: open
title: Doc styles for print should only use dark colors
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10358>
_______________________________________

From report at bugs.python.org  Mon Nov  8 15:11:33 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 08 Nov 2010 14:11:33 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Here are some ISO C conformance patches, and
a minor cleanup I encountered along the way.

Lib/distutils/tests/test_config_cmd.py // comment --> /* comment */.
Lib/distutils/tests/test_build_ext.py,
Objects/weakrefobject.c,
Modules/_pickle.c,
Modules/_testcapimodule.c,
Python/import.c  .  .  .  .  .  .  .   Remove some invalid ',' and ';'s.
Python/Python-ast.c,
Modules/arraymodule.c  .  .  .  .  .   Non-constant array initializer.
Modules/_csv.c   .  .  .  .  .  .  .   Slight cleanup.
Modules/_ctypes/libffi/src/x86/ffi.c   Empty translation unit.

TODO when bored, if anyone cares for more pedantic ISO patches:
- printf(%p, non-void* pointer): The pointer should be cast to void*.
- More // comments -> /**/, but mostly in system-specific code so I
  can't test any patches I make.

----------
components: None
files: iso-c.zip
messages: 120742
nosy: hfuru
priority: normal
severity: normal
status: open
title: ISO C cleanup
type: compile error
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19544/iso-c.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Mon Nov  8 15:12:43 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 08 Nov 2010 14:12:43 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>


New submission from Tres Seaver <tseaver at agendaless.com>:

Because application code which tests for the presence of
an object in a WeakSet may not be able to ensure that the
object is weak-referenceable, the set should just return
False for any object passed to '__contains__' which causes
'ref' to raise a TypeError.

Patch forthcoming.

----------
messages: 120743
nosy: tseaver
priority: normal
severity: normal
status: open
title: _weakrefset.WeakSet.__contains__ should not propagate TypeErrors
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 15:26:13 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 08 Nov 2010 14:26:13 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289226373.82.0.902560761758.issue10360@psf.upfronthosting.co.za>


Changes by Tres Seaver <tseaver at agendaless.com>:


----------
components: +Library (Lib)
keywords: +patch
Added file: http://bugs.python.org/file19545/issue10360.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 15:30:26 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 08 Nov 2010 14:30:26 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <hbf.20101108ho75@bombur.uio.no>
Message-ID: <hbf.20101108aq3m@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Hallvard B Furuseth writes:
> Looks fine to me.

Hold on.. #elif defined SIZEOF_LONG_LONG would be a bit safer than #else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Mon Nov  8 15:48:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Nov 2010 14:48:00 +0000
Subject: [issue10353] 2to3 and places argument in unitests assertAlmostEqual
In-Reply-To: <1289214223.54.0.6247578407.issue10353@psf.upfronthosting.co.za>
Message-ID: <1289227680.02.0.277641280662.issue10353@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/issue10353>
_______________________________________

From report at bugs.python.org  Mon Nov  8 15:51:29 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Nov 2010 14:51:29 +0000
Subject: [issue10353] 2to3 and places argument in unitests assertAlmostEqual
In-Reply-To: <1289214223.54.0.6247578407.issue10353@psf.upfronthosting.co.za>
Message-ID: <1289227889.78.0.220553307089.issue10353@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The change of places to a keyword-only argument in 3.x was reverted last week in py3k trunk.

----------
nosy: +michael.foord, r.david.murray
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6, Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10353>
_______________________________________

From report at bugs.python.org  Mon Nov  8 15:57:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Nov 2010 14:57:21 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289228241.52.0.414728297831.issue10354@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Shouldn't the global template variable just be deleted in python3?  It is no longer documented except for what is probably an overlooked mention in the introduction.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Mon Nov  8 15:58:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 14:58:11 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1289228291.12.0.0309022889786.issue10359@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If it?s not too much trouble for you, please post diffs as text files rather than binary.  You can also use ?svn diff? to produce one file with all differences.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Mon Nov  8 15:59:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 14:59:57 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1289228397.65.0.662013581372.issue10359@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

By the way, do these changes actually fix errors or are they just cleanups and pedantic (not a slight) fixes?  If the latter, I think they won?t go into stable branches.  I don?t do C though, so I won?t be the one to judge.  Thanks for the patches!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:00:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Nov 2010 15:00:57 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1289228457.89.0.615168065047.issue10359@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:04:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Nov 2010 15:04:22 +0000
Subject: [issue10348] multiprocessing: use SysV semaphores on FreeBSD
In-Reply-To: <1289181459.49.0.601327253766.issue10348@psf.upfronthosting.co.za>
Message-ID: <1289228662.22.0.282747796688.issue10348@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10348>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:07:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 15:07:18 +0000
Subject: [issue9873] urllib.parse: Allow bytes in some APIs that use string
	literals internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1289228838.04.0.265289360544.issue9873@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Related issue in msg120647.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:07:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 15:07:59 +0000
Subject: [issue10336] test_xmlrpc fails if gzip is not supported by client
In-Reply-To: <1289041038.52.0.266218953067.issue10336@psf.upfronthosting.co.za>
Message-ID: <1289228879.66.0.686647448309.issue10336@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No problem :)

I?ve had a look at the test and don?t understand the problem.  What?s the client you?re referring to?  I thought that in the tests, client-side and server-side were both under control.  Is the problem related to *python* being built without gzip support?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10336>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:08:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 15:08:05 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1289228885.43.0.772950554314.issue10355@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/issue10355>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:08:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 15:08:34 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289228914.98.0.224181028387.issue10354@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/issue10354>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:10:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 15:10:30 +0000
Subject: [issue10353] 2to3 and places argument in unitests assertAlmostEqual
In-Reply-To: <1289214223.54.0.6247578407.issue10353@psf.upfronthosting.co.za>
Message-ID: <1289229030.09.0.542352231191.issue10353@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is 3.1 incompatible with 2.7 and 3.2?  If so, is it best to have 3.2 compatible with 3.1 or to have 3.1 buggy?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10353>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:12:58 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 08 Nov 2010 15:12:58 +0000
Subject: [issue10353] 2to3 and places argument in unitests assertAlmostEqual
In-Reply-To: <1289214223.54.0.6247578407.issue10353@psf.upfronthosting.co.za>
Message-ID: <1289229178.23.0.318388686648.issue10353@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

It's fixed in release31-maint as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10353>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:15:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 15:15:01 +0000
Subject: [issue10351] Add autocompletion for keys in dictionaries
In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>
Message-ID: <1289229301.57.0.210007158521.issue10351@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the report and patch.  This is a new feature, thus targetting the py3k branch (future 3.2).  If your patch is not against this branch, can you refresh it?  Also, please attach it as text file(s), and generally follow guidelines outlined at http://www.python.org/dev/patches/  Thanks again!

----------
nosy: +eric.araujo
stage:  -> patch review
title: to introduce autocompletion for keys in dictionaries (patch attached) -> Add autocompletion for keys in dictionaries
type: behavior -> feature request
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10351>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:26:13 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 08 Nov 2010 15:26:13 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1289229973.82.0.171326884327.issue10225@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:26:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 15:26:22 +0000
Subject: [issue8919] python should read ~/.pythonrc.py by default
In-Reply-To: <1275846984.04.0.731293977336.issue8919@psf.upfronthosting.co.za>
Message-ID: <1289229982.31.0.672755360252.issue8919@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> the .pythonrc.py file is not deprecated. only the user module is deprecated.

Which amounts to the same IMO.

> the problem i have with the PYTHONSTARTUP variable is that i find it
> is an unecessary intermediate step to set up an initialization file.

Okay, I see your point, even though I?m not convinced :)  I suggest you write to the python-ideas mailing list to gather feedback about this.

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8919>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:28:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 08 Nov 2010 15:28:16 +0000
Subject: [issue10335] tokenize.open_python(): open a Python file with the
	right encoding
In-Reply-To: <201011070536.00599.victor.stinner@haypocalc.com>
Message-ID: <AANLkTin-3NEdEAkN8MbfQ+o+F4mHinuZTQHLJ233NHS6@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 7, 2010 at 4:24 AM, STINNER Victor <report at bugs.python.org> wrote:
..
> Ok, the new patch (tokenize_open-2.patch) uses tokenize.open() name and adds a
> test for BOM without coding cookie (test utf-8-sig encoding).

Here are my comments on the new patch:

1. A nit-pick: tokenize.py is already inconsistent in this respect,
but I believe it is conventional not to start a docsting with an empty
line:

+def open(filename):
+    """Open a Python script in read mode with the right encoding.

instead of

+def open(filename):
+    """
+    Open a Python script in read mode with the right encoding.

Also, I would prefer a more neutral description that will not imply
that the method is only useful for Python source code.  For example:

"""Detect encoding and open a file in read mode with the right encoding.

(optionally a more detailed explanation or a reference to detect_encoding.)
"""

2. Another nit-pick: detect_encoding() returns a list of 0-2 lines in
the second item, not a single line, so it is better to write

+    encoding, lines = detect_encoding(buffer.readline)

or even

+    encoding, _ = detect_encoding(buffer.readline)

instead of

+    encoding, line = detect_encoding(buffer.readline)

3. In test_open(self), I think you should use self.assertEqual()
instead of a plain assert.

4. Last nit-pick (feel free to ignore as prejudice to %-formatting :-):

instead of

+                print("# coding: %s" % encoding, file=fp)

you can write

+                print("# coding: " + encoding, file=fp)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:34:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 08 Nov 2010 15:34:39 +0000
Subject: [issue10335] tokenize.open(): open a Python file with the right
	encoding
In-Reply-To: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>
Message-ID: <1289230479.54.0.93412109724.issue10335@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Changing the title to make the latest choice of function name more visible.

----------
stage:  -> patch review
title: tokenize.open_python(): open a Python file with the right encoding -> tokenize.open(): open a Python file with the right encoding
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:35:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 15:35:48 +0000
Subject: [issue10335] tokenize.open(): open a file with encoding detected from
	a coding cookie
In-Reply-To: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>
Message-ID: <1289230548.12.0.253505045389.issue10335@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

1. Agreed on both.  Extraneous blank lines seem to be favored by people who need to work around bugs in their editor.

2. Yes, ?_? is recommended for a discarded object.

3. Agreed.

4. Even better: print('# coding:', encoding, file=fp).  No intermediary string!

----------
title: tokenize.open(): open a Python file with the right encoding -> tokenize.open(): open a file with encoding detected from a coding cookie

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:42:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 08 Nov 2010 15:42:26 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1289230946.06.0.764716139828.issue10356@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Are there situations where this is a problem?

I don't think that there's any requirement that the __hash__ method for a user-defined Python type not return -1.  (It's also allowed to return values outside the range of hash values;  these get automatically rehashed to values within the range.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Mon Nov  8 16:50:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Nov 2010 15:50:42 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1289231442.16.0.650182016087.issue10355@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What makes you think SpooledTemporaryFile *has* a name attribute? :)

Seriously, though, I presume this bug report is asking for either a better error message or for .name to raise an attribute error on a SpooledTemporaryFile?

----------
nosy: +r.david.murray
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10355>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:00:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Nov 2010 16:00:51 +0000
Subject: [issue10357] ** and "mapping" are poorly defined in python docs
In-Reply-To: <1289222187.72.0.886873143688.issue10357@psf.upfronthosting.co.za>
Message-ID: <1289232051.52.0.341797882835.issue10357@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think the Glossary entry needs to be updated to point to the authoritative source for 'mapping' methods:

http://docs.python.org/library/collections.html#abcs-abstract-base-classes

(and yes, I realize that info is not located in a particularly intuitive location!)

I wonder, however, if the code should be updated to use a dictionary iterator rather than 'keys'.

----------
nosy: +r.david.murray, rhettinger
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10357>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:03:46 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Nov 2010 16:03:46 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1289232226.59.0.0978918355339.issue10356@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's not about the hash value, but about consistency: help(Decimal.__hash__) says "x.__hash__() <==> hash(x)", but this is not true for x=Decimal(-1).

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:05:01 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 16:05:01 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1289232301.49.0.685272061697.issue10355@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Yes, sorry, I should have been less concise. =)

> Seriously, though, I presume this bug report is asking for either a 
> better error message or for .name to raise an attribute error on a 
> SpooledTemporaryFile?

I'm not sure what's better. I must be honest and say that I opened this report more to signal this behavior rather than provide a solution, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10355>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:12:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 16:12:30 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1289232750.1.0.268938257941.issue10355@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>From the doc of tempfile.NamedTemporaryFile: ?This function operates exactly as TemporaryFile() does, except that the file is guaranteed to have a visible name in the file system (on Unix, the directory entry is not unlinked). That name can be retrieved from the name member of the file object. Whether the name can be used to open the file a second time, while the named temporary file is still open, varies across platforms (it can be so used on Unix; it cannot on Windows NT or later).?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10355>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:12:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 08 Nov 2010 16:12:59 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1289232779.54.0.416970122574.issue10224@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As discussed on #python-dev, building  3.x documentation using python3.x will require Sphinx 1.1 which will not be released in time for 3.2.

I am adding #10225 as a dependency because I feel that fixing actual errors in ReST doctests is more important than upgrading documentation tool chain.  Hopefully this will bring more eyes to that issue.

This said, I believe it is important for python-dev to "eat their own dogfood" and make 3.2 self-hosting.  In other words, if we want to convince users that 3.x is ready, we should not require 2.x in the build process.

Fortunately, Doc/tools is not shipped with python releases, so the transition can be made at any time regardless of python release schedule.

----------
dependencies: +Fix doctest runable examples in python manual
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:16:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 16:16:37 +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: <1289232997.53.0.333406447502.issue1195@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:20:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Nov 2010 16:20:16 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1289233216.34.0.852823658728.issue10224@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree that 3.2 should eventually be independent of a 2.x Python.  Since the "port to 3.x" part of Sphinx 1.1 is basically done, I might just do an early alpha release and use that for Doc/tools before 3.2 final.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:22:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 08 Nov 2010 16:22:46 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289233366.07.0.33226667594.issue10360@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/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:25:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Nov 2010 16:25:46 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1289233546.18.0.279902000803.issue10355@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

?ric: right, but we're talking about *Spooled*Temprorary file, which doesn't say anything about a name, and in fact says that the data is kept in memory (which implies it has no name).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10355>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:26:07 2010
From: report at bugs.python.org (Chris Gerhard)
Date: Mon, 08 Nov 2010 16:26:07 +0000
Subject: [issue1236] subprocess is not thread-safe
In-Reply-To: <1191533517.74.0.548071476021.issue1236@psf.upfronthosting.co.za>
Message-ID: <1289233567.72.0.279837023379.issue1236@psf.upfronthosting.co.za>


Changes by Chris Gerhard <chris.gerhard at oracle.com>:


----------
nosy: +Chris.Gerhard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1236>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:28:31 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 08 Nov 2010 16:28:31 +0000
Subject: [issue10357] ** and "mapping" are poorly defined in python docs
In-Reply-To: <1289222187.72.0.886873143688.issue10357@psf.upfronthosting.co.za>
Message-ID: <1289233711.1.0.35081707854.issue10357@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/issue10357>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:35:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 08 Nov 2010 16:35:58 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289234158.75.0.230104841292.issue10360@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

A result from IRC is that to be consistent with normal sets, only TypeErrors coming from ref() should be caught, but not those TypeErrors from the actual membership test (i.e. the hash functioon of the value).

----------
assignee:  -> rhettinger
nosy: +georg.brandl, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:39:29 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 08 Nov 2010 16:39:29 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1289234369.34.0.936926342502.issue10356@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Good catch Stefan.  This is a regression from Py2.6.  The behavior for decimal should match that for int.

IDLE 2.6.2      
>>> hash(-1)
-2
>>> (-1).__hash__()
-2
>>> from decimal import *
>>> hash(Decimal(-1))
-2
>>> Decimal(-1).__hash__()
-2

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:46:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 16:46:15 +0000
Subject: [issue5819] Add PYTHONPREFIXES environment variable
In-Reply-To: <1240475142.53.0.423262271042.issue5819@psf.upfronthosting.co.za>
Message-ID: <1289234775.65.0.0424741882447.issue5819@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +barry, eric.araujo
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5819>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:52:43 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 08 Nov 2010 16:52:43 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289235163.69.0.663220952346.issue10360@psf.upfronthosting.co.za>


Changes by Tres Seaver <tseaver at agendaless.com>:


Removed file: http://bugs.python.org/file19545/issue10360.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:54:03 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 08 Nov 2010 16:54:03 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289235243.17.0.746198606614.issue10360@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

A new version of the patch, which only traps TypeErrors raises
by ref(item).  The test now ensures that hashing errors are
propagated, for compatibility with standard sets.

----------
Added file: http://bugs.python.org/file19546/issue10360-redux.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:57:48 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 08 Nov 2010 16:57:48 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289235468.39.0.957956251369.issue10360@psf.upfronthosting.co.za>


Changes by Tres Seaver <tseaver at agendaless.com>:


Removed file: http://bugs.python.org/file19546/issue10360-redux.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 17:58:40 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 08 Nov 2010 16:58:40 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289235520.92.0.00765687709402.issue10360@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

"One more time, with feeling."

Sorry for the noise, the last patch was not against the 2.7 trunk.

----------
Added file: http://bugs.python.org/file19547/issue10360-redux.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:06:44 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 08 Nov 2010 17:06:44 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289236004.8.0.0827307377533.issue10360@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

FTR, the patch applies cleanly to the py3k branch, too. (Michael
pointed out that the original code was copied directly from there).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:07:01 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 08 Nov 2010 17:07:01 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289236021.92.0.941631885088.issue10360@psf.upfronthosting.co.za>


Changes by Tres Seaver <tseaver at agendaless.com>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:09:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 17:09:48 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1289236188.32.0.163488241075.issue10355@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Wow, brain fail.  What I actually wanted to say:  SpooledTemporaryFile ?operates exactly as TemporaryFile() does?, which is not guaranteed to have a name.  The definition of file-like object (linked from tempfile docs) says nothing about a name either.  Therefore, I think the presence of this attribute is a bug.

Adding Collin to nosy, as the committer of SpooledTemporaryFile.

----------
nosy: +collinwinter

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10355>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:11:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 08 Nov 2010 17:11:11 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289236271.99.0.532203808939.issue10360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What is the behaviour of WeakKeyDictionary here? I don't really agree that TypeError should be silenced.

----------
nosy: +pitrou
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:15:06 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 08 Nov 2010 17:15:06 +0000
Subject: [issue10355] SpooledTemporaryFile's name property is broken
In-Reply-To: <1289218442.71.0.42635989391.issue10355@psf.upfronthosting.co.za>
Message-ID: <1289236506.16.0.0113214574837.issue10355@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Also "encoding" and "mode" properties fail in the same manner.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10355>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:17:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 17:17:17 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <90e6ba476adb7467fe04948dcbf2@google.com>
Message-ID: <90e6ba476adb7467fe04948dcbf2@google.com>


New submission from ?ric Araujo <merwok at netwok.org>:

Looks globally good to me.

http://codereview.appspot.com/2874041/diff/2001/cmd.py
File cmd.py (right):

http://codereview.appspot.com/2874041/diff/2001/cmd.py#newcode55
cmd.py:55: :param distutils.dist.Distribution dist: distribution to work
with
Please don?t include unrelated changes in your patch.

Also, Python does not use :param: in docstrings.

http://codereview.appspot.com/2874041/diff/2001/command/upload.py
File command/upload.py (right):

http://codereview.appspot.com/2874041/diff/2001/command/upload.py#newcode53
command/upload.py:53: if not self.username and
self.distribution.username:
I?d prefer a clearer comparison, please use ?is [not] None? and parens.

http://codereview.appspot.com/2874041/

----------
messages: 120776
nosy: eric.araujo, techtonik
priority: normal
severity: normal
status: open
title: Fix issue 9995 - distutils forces developers to store password in cleartext (issue2874041)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10361>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:18:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 17:18:42 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1289236722.34.0.830506791468.issue9995@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  Review on Rietveld.

What are ?other Python distributions??

----------
components: +Distutils2
versions: +3rd party, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9995>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:18:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Nov 2010 17:18:47 +0000
Subject: [issue10321] Add support for Message objects and binary data to
	smtplib.sendmail
In-Reply-To: <1288948061.88.0.822892450886.issue10321@psf.upfronthosting.co.za>
Message-ID: <1289236727.06.0.110478566517.issue10321@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r86327.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10321>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:20:21 2010
From: report at bugs.python.org (Tres Seaver)
Date: Mon, 08 Nov 2010 17:20:21 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1289236821.76.0.871274702227.issue10360@psf.upfronthosting.co.za>


Tres Seaver <tseaver at agendaless.com> added the comment:

WeakKeyDictionary's __contains__:

    def __contains__(self, key):
        try:
            wr = ref(key)
        except TypeError:
            return 0
        return wr in self.data

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:23:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 17:23:19 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <90e6ba476adb7467fe04948dcbf2@google.com>
Message-ID: <1289236999.93.0.770163882022.issue10361@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yay for obscure email interfaces.  Sorry for the noise.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10361>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:38:17 2010
From: report at bugs.python.org (ProgVal)
Date: Mon, 08 Nov 2010 17:38:17 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>


New submission from ProgVal <progval at gmail.com>:

Hello,

I had this traceback:

Traceback (most recent call last):
...
  File "/home/progval/workspace/Supybot/Supybot-plugins/Packages/plugin.py", line 123, in extractData
    file = tarfile.open(fileobj=file_)
  File "/usr/lib/python2.6/tarfile.py", line 1651, in open
    saved_pos = fileobj.tell()
AttributeError: addinfourl instance has no attribute 'tell'

The repr(file_) is : <addinfourl at 47496224 whose fp = <socket._fileobject object at 0x2c933d0>> (the file has been downloaded with urllib).

I use Python 2.6.6 (from Debian Sid repo)

Best regards,
ProgVal

----------
messages: 120781
nosy: Valentin.Lorentz
priority: normal
severity: normal
status: open
title: AttributeError: addinfourl instance has no attribute 'tell'

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10362>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:38:51 2010
From: report at bugs.python.org (Martin Dunschen)
Date: Mon, 08 Nov 2010 17:38:51 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>


New submission from Martin Dunschen <mdunschen at gmail.com>:

I found a number of 'handle leaks' in the core code to embed python into a C/C++ application on windows. 
To reproduce: 
The simplest possible embedded application only calls:

#include <Python.h>
void entry()
{
    Py_Initialize();
    Py_Finalize();
}

I found (but this does not seem important to the problem) that when the above code is compiled into a Windows DLL, and from another simple app this DLL is loaded, the entry function is called and then the DLL is unloaded, the number of handles held by the application is increasing (by 3). Calling the steps "LoadLibrary, entry, FreeLibrary" in a loop will increase the number of held handles by 3 every time.

I can propose fixes for these 3 leaks, please find attached in the zip file patches for the files I have fixed.

But there are some issues remaining:
PyEval_InitThreads
allocates 'interpreter_lock', but there is nothing in the API that allows you to free this lock again. Should there maybe a function, in the API

void PyEval_FinishThreads(void)
{
    if (!interpreter_lock)
	return;
    PyThread_free_lock(interpreter_lock);
}

That would get rid of another handle leak if a DLL embedding python would use PyEval_InitThreads.

In a specific DLL I am debugging just now I observe 2 more handle leaks (The 4 I report here, and 2 more I have not yet found).

I hope my report is comprehensive and can be reproduced. I am happy to be of assistance if there are any questions.

Martin

----------
components: Interpreter Core
messages: 120782
nosy: martind
priority: normal
severity: normal
status: open
title: Embedded python, handle (memory) leak
type: resource usage
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:47:27 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Nov 2010 17:47:27 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1289238447.87.0.332601815827.issue10362@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

With a socket file you cannot rely on autodetection of the format. I suggest to try
   tarfile.open(fileobj=file_, mode='r:')
or 
   tarfile.open(fileobj=file_, mode='r:gz')

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10362>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:57:33 2010
From: report at bugs.python.org (ProgVal)
Date: Mon, 08 Nov 2010 17:57:33 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1289239053.64.0.633477328864.issue10362@psf.upfronthosting.co.za>


ProgVal <progval at gmail.com> added the comment:

Thanks for your answer.

Sorry, no change...

----------
components: +Library (Lib)
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10362>
_______________________________________

From report at bugs.python.org  Mon Nov  8 18:58:22 2010
From: report at bugs.python.org (Typo)
Date: Mon, 08 Nov 2010 17:58:22 +0000
Subject: [issue10364] Color coding fails after running program.
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>


New submission from Typo <lol.rabbit at yahoo.com>:

Whenever I run a program in Python 3.1.2 (windows), the color coding disappears. print() is no longer purple, def is no longer orange, etc. It all turns black, and there doesn't seem to be a way to repair this. I've installed and uninstalled Python 3.1.2 several times and it's done nothing. Loading previous programs also causes this. Only if I am making a new program is the coding separated by color. Can anyone help?

----------
components: None
messages: 120785
nosy: Typo
priority: normal
severity: normal
status: open
title: Color coding fails after running program.
type: performance
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10364>
_______________________________________

From report at bugs.python.org  Mon Nov  8 19:04:06 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Nov 2010 18:04:06 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1289239446.46.0.583303965648.issue10362@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I'm sure the traceback changed then?
mode='r:' uses a different code path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10362>
_______________________________________

From report at bugs.python.org  Mon Nov  8 19:16:37 2010
From: report at bugs.python.org (ProgVal)
Date: Mon, 08 Nov 2010 18:16:37 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1289240197.27.0.463671873303.issue10362@psf.upfronthosting.co.za>


ProgVal <progval at gmail.com> added the comment:

Here is the new traceback:
Traceback (most recent call last):
...
  File "/home/progval/workspace/Supybot/Supybot-plugins/Packages/plugin.py", line 123, in extractData
    file = tarfile.open(fileobj=file_, mode='r:')
  File "/usr/lib/python2.6/tarfile.py", line 1671, in open
    return func(name, filemode, fileobj, **kwargs)
  File "/usr/lib/python2.6/tarfile.py", line 1698, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python2.6/tarfile.py", line 1563, in __init__
    self.offset = self.fileobj.tell()
AttributeError: addinfourl instance has no attribute 'tell'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10362>
_______________________________________

From report at bugs.python.org  Mon Nov  8 19:30:08 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 08 Nov 2010 18:30:08 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <90e6ba476adb7467fe04948dcbf2@google.com>
Message-ID: <20cf30549dcb03b06604948ed077@google.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

Reviewers: merwok,

Message:
I don't know when where will be time to redo the patch, but it would be
nice to get some answers in meanwhile.

http://codereview.appspot.com/2874041/diff/2001/cmd.py
File cmd.py (right):

http://codereview.appspot.com/2874041/diff/2001/cmd.py#newcode55
cmd.py:55: :param distutils.dist.Distribution dist: distribution to work
with
On 2010/11/08 17:17:11, merwok wrote:
> Please don?t include unrelated changes in your patch.

> Also, Python does not use :param: in docstrings.

Including this in another patch is too much work to ever happen. What
Python uses?

http://codereview.appspot.com/2874041/diff/2001/command/upload.py
File command/upload.py (right):

http://codereview.appspot.com/2874041/diff/2001/command/upload.py#newcode53
command/upload.py:53: if not self.username and
self.distribution.username:
On 2010/11/08 17:17:11, merwok wrote:
> I?d prefer a clearer comparison, please use ?is [not] None? and
parens.
Are you sure you want an empty username in config file to override name
set from 'register' command?

Please review this at http://codereview.appspot.com/2874041/

Affected files:
   M     cmd.py
   M     command/register.py
   M command/upload.py
   M     dist.py
   M     tests/test_register.py

Index: tests/test_register.py
===================================================================
--- tests/test_register.py	(revision 86138)
+++ tests/test_register.py	(working copy)
@@ -152,6 +152,26 @@
          # therefore used afterwards by other commands
          self.assertEquals(cmd.distribution.password, 'password')

+    def test_password_set_with_no_config(self):
+        # check credentials are saved in dist if user chooses not to save  
them
+        # in config file. they are used afterwards by other commands
+        cmd = self._get_cmd()
+
+        # patching raw_input and getpass.getpass. We are faking:
+        # use your existing login (choice 1.)
+        # Username : 'tarek'
+        # Password : 'password'
+        # Save your login (y/N)? : 'y'
+        inputs = RawInputs('1', 'tarek', 'n')
+        register_module.raw_input = inputs.__call__
+        try:
+            cmd.run()
+        finally:
+            del register_module.raw_input
+
+        self.assertEquals(cmd.distribution.username, 'tarek')
+        self.assertEquals(cmd.distribution.password, 'password')
+
      def test_registering(self):
          # this test runs choice 2
          cmd = self._get_cmd()
Index: command/register.py
===================================================================
--- command/register.py	(revision 86138)
+++ command/register.py	(working copy)
@@ -172,11 +172,11 @@

              # possibly save the login
              if code == 200:
-                if self.has_config:
-                    # sharing the password in the distribution instance
-                    # so the upload command can reuse it
-                    self.distribution.password = password
-                else:
+                # sharing credentials in the distribution instance
+                # so the upload command can reuse it
+                self.distribution.username = username
+                self.distribution.password = password
+                if not self.has_config:
                      self.announce(('I can store your PyPI login so future '
                                     'submissions will be faster.'),  
log.INFO)
                      self.announce('(the login will be stored in %s)' % \
Index: command/upload.py
===================================================================
--- command/upload.py	(revision 86138)
+++ command/upload.py	(working copy)
@@ -48,8 +48,10 @@
              self.repository = config['repository']
              self.realm = config['realm']

-        # getting the password from the distribution
+        # getting credentials from the distribution
          # if previously set by the register command
+        if not self.username and self.distribution.username:
+            self.username = self.distribution.username
          if not self.password and self.distribution.password:
              self.password = self.distribution.password

Index: dist.py
===================================================================
--- dist.py	(revision 86138)
+++ dist.py	(working copy)
@@ -206,6 +206,7 @@
          self.extra_path = None
          self.scripts = None
          self.data_files = None
+        self.username = ''
          self.password = ''

          # And now initialize bookkeeping stuff that can't be supplied by
Index: cmd.py
===================================================================
--- cmd.py	(revision 86138)
+++ cmd.py	(working copy)
@@ -51,6 +51,8 @@
          invokes the 'initialize_options()' method, which is the real
          initializer and depends on the actual command being
          instantiated.
+
+        :param distutils.dist.Distribution dist: distribution to work with
          """
          # late import because of mutual dependence between these classes
          from distutils.dist import Distribution

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10361>
_______________________________________

From report at bugs.python.org  Mon Nov  8 19:42:42 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 08 Nov 2010 18:42:42 +0000
Subject: [issue10364] Color coding fails after running program.
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1289241762.33.0.127505850145.issue10364@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is an editor rather than Python problem. Are you using the IDLE editor or something else. Which version of Windows?

Orange and purple are IDLE's default for keywords and built-in names. But running 3.1.2 under XP, I have no problem as you describe, either after running or loading.

----------
nosy: +terry.reedy
type: performance -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10364>
_______________________________________

From report at bugs.python.org  Mon Nov  8 19:44:09 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 08 Nov 2010 18:44:09 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1289241849.24.0.277328627297.issue9995@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This fix is needed for 2.6 releases also to be able to upload packages from Linux.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9995>
_______________________________________

From report at bugs.python.org  Mon Nov  8 19:47:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 18:47:43 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <90e6ba476adb7467fe04948dcbf2@google.com>
Message-ID: <20cf30549fdff9f64d04948f0e7a@google.com>


?ric Araujo <merwok at netwok.org> added the comment:

Further replies.  There?s still one comment in test_register you haven?t
addressed yet.

Tarek, I?d like to have your decision about one line in the upload
command.  (Don?t read the diff in this mail, it?s incomplete, go to
Rietveld.)  Thanks in advance.

http://codereview.appspot.com/2874041/diff/2001/cmd.py
File cmd.py (right):

http://codereview.appspot.com/2874041/diff/2001/cmd.py#newcode55
cmd.py:55: :param distutils.dist.Distribution dist: distribution to work
with
> Including this in another patch is too much work to ever happen.
We?ll have to revert it before committing then.

Something like ?*dist* is an instance of blah?.

http://codereview.appspot.com/2874041/diff/2001/command/upload.py
File command/upload.py (right):

http://codereview.appspot.com/2874041/diff/2001/command/upload.py#newcode53
command/upload.py:53: if not self.username and
self.distribution.username:
This is a crazy case.  PyPI won?t allow it to pass, so I?m okay with it.
  Tarek, what do you think?

http://codereview.appspot.com/2874041/diff/2001/tests/test_register.py
File tests/test_register.py (right):

http://codereview.appspot.com/2874041/diff/2001/tests/test_register.py#newcode165
tests/test_register.py:165: inputs = RawInputs('1', 'tarek', 'n')
It looks like you?re replying to ?username? and ?save your login? but
not ?password?.

http://codereview.appspot.com/2874041/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10361>
_______________________________________

From report at bugs.python.org  Mon Nov  8 19:58:33 2010
From: report at bugs.python.org (Typo)
Date: Mon, 08 Nov 2010 18:58:33 +0000
Subject: [issue10364] Color coding fails after running program.
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1289242713.02.0.679471293082.issue10364@psf.upfronthosting.co.za>


Typo <lol.rabbit at yahoo.com> added the comment:

I am using Windows Vista. The problem is not within Idle but within the screen where you create and save coding to use in Idle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10364>
_______________________________________

From report at bugs.python.org  Mon Nov  8 20:03:01 2010
From: report at bugs.python.org (William Barr)
Date: Mon, 08 Nov 2010 19:03:01 +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: <1289242981.94.0.545258182692.issue10365@psf.upfronthosting.co.za>


New submission from William Barr <webmaster961 at gmail.com>:

Steps for reproduction:
1.  Open IDLE (Python 3.1.2)
2.  Open a .py file
3.  With the code window (not the shell window) in focus, Ctrl + O to bring up the open file dialog.  Do not select a file or press open.  
4.  Close the code window.  
5.  Select a file and try to open it.
6.  The IDLE process will terminate.  

This test was performed on Windows 7 Professional 32-bit as well as Windows XP Professional 32-bit.  

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32

----------
components: IDLE, Windows
messages: 120793
nosy: william.barr
priority: normal
severity: normal
status: open
title: IDLE Crashes on File Open Dialog when code window closed before other file opened
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10365>
_______________________________________

From report at bugs.python.org  Mon Nov  8 20:09:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Nov 2010 19:09:10 +0000
Subject: [issue10327] Abnormal SSL timeouts when using socket timeouts - once
	again
In-Reply-To: <1288967513.64.0.717673746201.issue10327@psf.upfronthosting.co.za>
Message-ID: <1289243350.02.0.966625525392.issue10327@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10327>
_______________________________________

From report at bugs.python.org  Mon Nov  8 20:13:04 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 08 Nov 2010 19:13:04 +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: <1289243584.75.0.758706300634.issue10365@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Reproduced in a console window:
C:\>c:\python31\python.exe -m idlelib.idle
Exception in Tkinter callback
Traceback (most recent call last):
  File "c:\python31\lib\tkinter\__init__.py", line 1399, in __call__
    return self.func(*args)
  File "c:\python31\lib\idlelib\IOBinding.py", line 177, in open
    self.editwin.flist.open(filename)
AttributeError: 'NoneType' object has no attribute 'flist'

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10365>
_______________________________________

From report at bugs.python.org  Mon Nov  8 20:19:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 08 Nov 2010 19:19:12 +0000
Subject: [issue10366] Remove unneeded '(object)' from 3.x class examples
In-Reply-To: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>
Message-ID: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

In 3.x, "(object)" is now superfluous in class statements. Reference manual 7.7. Class definitions has simply
    class Foo: pass

In library manual 2. Built-in Functions, class examples for classmethod and staticmethod are the same. Class examples for dir, property, and type still have '(object)' in their class examples. Section 5.11.4. Methods example omits it. I cannot think of anywhere else there should be such examples.

I think we should be consistent and remove the remaining occurrences of '(object)' in the function examples. They can only confuse newcomers.

This part is easy.

I also think the doc for 'class' should say that the default inheritance is from the base class *object* (I presume this should be true in all implementations) and that 
    class Foo(object): pass
is the same as the above (unless the name 'object' has been rebound!).

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 120795
nosy: docs at python, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: Remove unneeded '(object)' from 3.x class examples
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10366>
_______________________________________

From report at bugs.python.org  Mon Nov  8 20:27:52 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 08 Nov 2010 19:27:52 +0000
Subject: [issue5819] Add PYTHONPREFIXES environment variable
In-Reply-To: <1240475142.53.0.423262271042.issue5819@psf.upfronthosting.co.za>
Message-ID: <1289244472.11.0.416940010982.issue5819@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'll look at this in more detail, but I can at least answer one question right now:

"The bona-fide known bug: the Debian package mantainer for Python decided to change "site-packages" to "dist-packages" in 2.6, for reasons I still don't quite understand."

This was done as an accommodation to upstream Python developers.  A from-source build of Python installs into /usr/local by default, with a site-packages situated there.  But the Debian interpretation of the FHS states that site-installed (i.e. not through the package manager) add-ons to Python should also live in /usr/local, and /usr/local/lib/pythonX.Y/site-packages was chosen as the most obvious place for that.

Unfortunately, this meant that if you installed Python from source using the defaults, it was possible to clobber either your system Python or your from-source installed Python by installing third party packages to an unintentionally shared directory.  This was a real problem.

Now, the Debian answer (probably rightly so) was that Python's from-source defaults should install into /opt not /usr/local, but this broke a decade's (at least) convention from upstream.  The compromise was to keep Debian's /usr/local interpretation of the FHS, but to choose a directory that would not conflict with a from-source installation of Python.  Thus dist-packages was chosen.  To keep the system Python consistent, Python packages installed via apt are installed to /usr/lib/pythonX.Y/dist-packages too.

I've had discussions with developers on both sides.  It's not an ideal solution to anyone, but I thought it was the best compromise available at that time, and still do.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5819>
_______________________________________

From report at bugs.python.org  Mon Nov  8 20:32:36 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 08 Nov 2010 19:32:36 +0000
Subject: [issue10364] Color coding fails after running program.
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1289244756.5.0.04727037866.issue10364@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If it is an editor window that you launch from IDLE, with a red script Tk in the upper left corner, with 'About IDLE' on the help menu, then it is an IDLE editor window and part of IDLE -- and appropriate for bug reports here ;-).

This could be something specific to Vista; I do not know how well interactive things are tested there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10364>
_______________________________________

From report at bugs.python.org  Mon Nov  8 20:51:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 19:51:38 +0000
Subject: [issue10366] Remove unneeded '(object)' from 3.x class examples
In-Reply-To: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>
Message-ID: <1289245898.06.0.770831802804.issue10366@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Other unneeded uses of object, courtesy of grep:

library/sqlite3.rst:713:   class Point(object):
library/multiprocessing.rst:1335:   class MathsClass(object):
library/functions.rst:281:      >>> class Foo(object):
library/functions.rst:897:      class C(object):
library/functions.rst:916:      class Parrot(object):
library/functions.rst:933:      class C(object):
library/functions.rst:1237:      >>> class X(object):
library/argparse.rst:1315:   >>> class C(object):
library/ctypes.rst:372:   >>> class Bottles(object):
library/itertools.rst:326:      class groupby(object):
howto/descriptor.rst:156:    class RevealAccess(object):
howto/descriptor.rst:173:    >>> class MyClass(object):
howto/descriptor.rst:205:    class C(object):
howto/descriptor.rst:214:    class Property(object):
howto/descriptor.rst:250:    class Cell(object):
howto/descriptor.rst:278:    class Function(object):
howto/descriptor.rst:286:    >>> class D(object):
howto/descriptor.rst:358:    >>> class E(object):
howto/descriptor.rst:371:    class StaticMethod(object):
howto/descriptor.rst:384:    >>> class E(object):
howto/descriptor.rst:419:    class ClassMethod(object):
howto/sorting.rst:228:        class K(object):
reference/datamodel.rst:1990:   >>> class C(object):
includes/sqlite3/adapter_point_2.py:3:class Point(object):
includes/sqlite3/converter_point.py:3:class Point(object):
includes/sqlite3/adapter_point_1.py:3:class Point(object):
includes/mp_newtype.py:15:class Foo(object):

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10366>
_______________________________________

From report at bugs.python.org  Mon Nov  8 20:52:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 08 Nov 2010 19:52:51 +0000
Subject: [issue10366] Remove unneeded '(object)' from 3.x class examples
In-Reply-To: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>
Message-ID: <1289245971.18.0.60126809886.issue10366@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/issue10366>
_______________________________________

From report at bugs.python.org  Mon Nov  8 20:55:01 2010
From: report at bugs.python.org (Prabhu Gurumurthy)
Date: Mon, 08 Nov 2010 19:55:01 +0000
Subject: [issue10349] Error in Module/python.c when building on OpenBSD 4.8
In-Reply-To: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>
Message-ID: <1289246101.36.0.962937550771.issue10349@psf.upfronthosting.co.za>


Prabhu Gurumurthy <pgurumu at gmail.com> added the comment:

I was building it just the way python2.x is being built, should I try it without cxx-main? But, does it solve the actual problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10349>
_______________________________________

From report at bugs.python.org  Mon Nov  8 20:59:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 19:59:07 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1289246347.82.0.617398579609.issue9995@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Security issues are for example buffer overflows that can be used to cause rights escalation or system corruption.  They?re typically discovered by third parties who publish notices like CVE or DSA.  What your patch is addressing is a behavior bug, not a security issue.

----------
type: security -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9995>
_______________________________________

From report at bugs.python.org  Mon Nov  8 22:02:43 2010
From: report at bugs.python.org (Philippe Devalkeneer)
Date: Mon, 08 Nov 2010 21:02:43 +0000
Subject: [issue8033] sqlite: broken long integer handling for arguments to
	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1289250162.98.0.509326643576.issue8033@psf.upfronthosting.co.za>


Philippe Devalkeneer <phil.le.bienheureux at gmail.com> added the comment:

The regression tests do not work anymore in test_sqlite with the patch, I will check more in details why... sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Mon Nov  8 22:23:06 2010
From: report at bugs.python.org (Philippe Devalkeneer)
Date: Mon, 08 Nov 2010 21:23:06 +0000
Subject: [issue8033] sqlite: broken long integer handling for arguments to
	user-defined functions
In-Reply-To: <1267408991.73.0.408537758811.issue8033@psf.upfronthosting.co.za>
Message-ID: <1289251386.03.0.842270111733.issue8033@psf.upfronthosting.co.za>


Philippe Devalkeneer <phil.le.bienheureux at gmail.com> added the comment:

No, I made a mistake in my build, test_sqlite runs actually fine before and after the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8033>
_______________________________________

From report at bugs.python.org  Mon Nov  8 22:29:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 08 Nov 2010 21:29:52 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1289251792.0.0.898508479726.issue1466065@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is an updated patch that addresses the concerns I noted.  I modified the tests: given that I've changed the code to raise binascii.Error as discussed, we don't really care from an API point of view what the error text is, just that the error is raised in the cases given.  Nor do we care (again, from an API point of view) if the first error detected is the invalid character or the invalid padding.  

I made the new test test the validate=False case, so all of the invalid character tests are now correctly padded if you ignore the invalid characters.

----------
Added file: http://bugs.python.org/file19548/binascii-validate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Mon Nov  8 22:36:52 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 08 Nov 2010 21:36:52 +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: <1289252212.79.0.124730407849.issue10367@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Uploading a new release of one of my libraries to PYPI I got this error:

"""
Submitting dist/bsddb3-5.1.1.tar.gz to http://pypi.python.org/pypi
Upload failed (400): A file named "bsddb3-5.1.1.tar.gz" already exists for  bsddb3-5.1.1. To fix problems with that file you should create a new release.
Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    import setup2
  File "/home/pybsddb/setup2.py", line 415, in <module>
    'Programming Language :: Python :: 3.2',
  File "/usr/local/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/local/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python2.7/distutils/command/upload.py", line 60, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/local/lib/python2.7/distutils/command/upload.py", line 189, in upload_file
    self.announce('-'*75, result.read(), '-'*75)
UnboundLocalError: local variable 'result' referenced before assignment
"""

Checking the code, I see this:

"""
        # send the data
        try:
            result = urlopen(request)
            status = result.getcode()
            reason = result.msg
        except socket.error, e:
            self.announce(str(e), log.ERROR)
            return
        except HTTPError, e:
            status = e.code
            reason = e.msg

        if status == 200:
            self.announce('Server response (%s): %s' % (status, reason),
                          log.INFO)
        else:
            self.announce('Upload failed (%s): %s' % (status, reason),
                          log.ERROR)
        if self.show_response:
            self.announce('-'*75, result.read(), '-'*75)
"""

Here, if we selected "show_response" *AND* some error happens, "result" will be undefined and the last line will fail.

This bug was introduced in Python 2.7. It used to work correctly under Python 2.6.

I didn't check Python 3.x.

I think this bug is trivial to reproduce: just try to upload any file with no permissions for it, using "--show_response" command line option.

----------
keywords: easy
messages: 120804
nosy: jcea
priority: high
severity: normal
stage: needs patch
status: open
title: "python setup.py sdist upload --show-response" can fail with "UnboundLocalError: local variable 'result' referenced before assignment"
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Mon Nov  8 22:41:39 2010
From: report at bugs.python.org (Typo)
Date: Mon, 08 Nov 2010 21:41:39 +0000
Subject: [issue10364] Color coding fails after running program.
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1289252499.69.0.0271157028851.issue10364@psf.upfronthosting.co.za>


Typo <lol.rabbit at yahoo.com> added the comment:

Ah I see. I didn't know that the editor window was part of Idle. Sorry for the confusion.

I am also receiving this problem in Python 2.5.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10364>
_______________________________________

From report at bugs.python.org  Mon Nov  8 22:43:58 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 08 Nov 2010 21:43:58 +0000
Subject: [issue10368] "python setup.py sdist upload --show-response" fails
In-Reply-To: <1289252638.8.0.398810501872.issue10368@psf.upfronthosting.co.za>
Message-ID: <1289252638.8.0.398810501872.issue10368@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Uploading a new module/update to PYPI, when requesting "--show_response" in the command line, will fail:

"""
Traceback (most recent call last):
  File "setup.py", line 5, in <module>
    import setup2
  File "/home/pybsddb/setup2.py", line 415, in <module>
    'Programming Language :: Python :: 3.2',
  File "/usr/local/lib/python2.7/distutils/core.py", line 152, in setup
    dist.run_commands()
  File "/usr/local/lib/python2.7/distutils/dist.py", line 953, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python2.7/distutils/dist.py", line 972, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python2.7/distutils/command/upload.py", line 60, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/local/lib/python2.7/distutils/command/upload.py", line 194, in upload_file
    self.announce('-'*75, result, '-'*75)
TypeError: announce() takes at most 3 arguments (4 given)
"""

This works correctly under Python 2.6. I haven't checked Python 3.x.

----------
keywords: easy
messages: 120806
nosy: jcea
priority: high
severity: normal
stage: needs patch
status: open
title: "python setup.py sdist upload --show-response" fails
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10368>
_______________________________________

From report at bugs.python.org  Mon Nov  8 22:52:46 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 08 Nov 2010 21:52:46 +0000
Subject: [issue10331] test_gdb failure when warnings printed out
In-Reply-To: <1288992626.81.0.692321873477.issue10331@psf.upfronthosting.co.za>
Message-ID: <1289253166.64.0.511994812297.issue10331@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Closing "won't fix", since this was misconfiguration; filtering out such warnings might mask a security issue.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10331>
_______________________________________

From report at bugs.python.org  Mon Nov  8 22:56:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 21:56:46 +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: <1289253406.51.0.866400371005.issue10299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Using cell spanning breaks ?make latex? (and thus PDF), you may want to rework the reST table markup.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Mon Nov  8 22:57:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 21:57:11 +0000
Subject: [issue10196] distutils.get_python_lib() returns
	/usr/local/python3/dist-packages on Ubuntu 10.10
In-Reply-To: <1288071198.84.0.0625228182395.issue10196@psf.upfronthosting.co.za>
Message-ID: <1289253431.08.0.991056890398.issue10196@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> 
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10196>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:00:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 22:00: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: <1289253632.75.0.750837007473.issue10367@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Can you paste your message and exact Python version on #9199?

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> distutils upload command crashes when displaying server response
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:01:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 22:01:22 +0000
Subject: [issue9199] distutils upload command crashes when displaying server
	response
In-Reply-To: <1278596334.3.0.531936724428.issue9199@psf.upfronthosting.co.za>
Message-ID: <1289253682.55.0.937964479374.issue9199@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Reopening because of #10367.

----------
nosy: +jcea
resolution: fixed -> 
stage: committed/rejected -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9199>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:02:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 08 Nov 2010 22:02:48 +0000
Subject: [issue10364] Color coding fails after running program.
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1289253768.14.0.573865301374.issue10364@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I take that as a yes, IDLE edit window. 2.5 is beyond fixing at this point, but that is useful data. I will look out for this problem when I load Python on Win7.

----------
components: +IDLE
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10364>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:05:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 08 Nov 2010 22:05:22 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <1289253922.88.0.00517722620866.issue10363@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:06:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 08 Nov 2010 22:06:56 +0000
Subject: [issue10349] Error in Module/python.c when building on OpenBSD 4.8
In-Reply-To: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>
Message-ID: <1289254016.86.0.0846290588751.issue10349@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It should certainly work around the problem you are reporting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10349>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:14:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 22:14:42 +0000
Subject: [issue10368] "python setup.py sdist upload --show-response" fails
In-Reply-To: <1289252638.8.0.398810501872.issue10368@psf.upfronthosting.co.za>
Message-ID: <1289254482.63.0.173039815827.issue10368@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> "python setup.py sdist upload --show-response" can fail with "UnboundLocalError: local variable 'result' referenced before assignment"
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10368>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:21:02 2010
From: report at bugs.python.org (Prabhu Gurumurthy)
Date: Mon, 08 Nov 2010 22:21:02 +0000
Subject: [issue10349] Error in Module/python.c when building on OpenBSD 4.8
In-Reply-To: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>
Message-ID: <1289254862.14.0.457924192967.issue10349@psf.upfronthosting.co.za>


Prabhu Gurumurthy <pgurumu at gmail.com> added the comment:

You may be correct, (since I have not tested it), but isn't the error that gcc complains about, an issue? a minor one I am sure.  I have gotten around it by just updating the file. Correct me if I am wrong here please, --with-cxx_main is not a supported option for compiling in OpenBSD? Ill test it without cxx_main option tonight.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10349>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:24:36 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 08 Nov 2010 22:24:36 +0000
Subject: [issue10196] distutils.get_python_lib() returns
	/usr/local/python3/dist-packages on Ubuntu 10.10
In-Reply-To: <1288071198.84.0.0625228182395.issue10196@psf.upfronthosting.co.za>
Message-ID: <1289255076.44.0.754670758383.issue10196@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This makes some sense (I think ;).  Include files are going to be tied specifically to the Python version but Python 3 packages are (with the addition of PEPs 3147 and 3149) sharable between Python 3 versions.  The plan IIUC is to backport those PEPs to Python 3.1 on Debian (and thus inherited by Ubuntu).

In any case, this is not a valid bug in Python because it's one area that Debian/Ubuntu makes distribution-specific changes to upstream.  See

http://wiki.debian.org/Python

and scroll down to "Deviations from upstream".  If there's an actual bug here (of which I'm not convinced ;) then it should be submitted at bugs.debian.org.

----------
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10196>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:26:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 08 Nov 2010 22:26:43 +0000
Subject: [issue10349] Error in Module/python.c when building on OpenBSD 4.8
In-Reply-To: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>
Message-ID: <1289255203.53.0.513475612147.issue10349@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I wasn't really discussing (yet) whether this is a bug. I was just trying to find out what specifically made you use this configure option. The need for it should have gone away ten years ago or so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10349>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:33:25 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Mon, 08 Nov 2010 22:33:25 +0000
Subject: [issue5131] pprint doesn't know how to print a defaultdict
In-Reply-To: <1233592442.21.0.0563262599933.issue5131@psf.upfronthosting.co.za>
Message-ID: <1289255605.02.0.445066450039.issue5131@psf.upfronthosting.co.za>


Changes by Rodrigo Bernardo Pimentel <rbp at isnomore.net>:


----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5131>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:35:32 2010
From: report at bugs.python.org (Prabhu Gurumurthy)
Date: Mon, 08 Nov 2010 22:35:32 +0000
Subject: [issue10349] Error in Module/python.c when building on OpenBSD 4.8
In-Reply-To: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>
Message-ID: <1289255732.71.0.47388196859.issue10349@psf.upfronthosting.co.za>


Prabhu Gurumurthy <pgurumu at gmail.com> added the comment:

I understand, Ill run it without cxx_main option tonight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10349>
_______________________________________

From report at bugs.python.org  Mon Nov  8 23:38:41 2010
From: report at bugs.python.org (Fergal Daly)
Date: Mon, 08 Nov 2010 22:38:41 +0000
Subject: [issue10357] ** and "mapping" are poorly defined in python docs
In-Reply-To: <1289222187.72.0.886873143688.issue10357@psf.upfronthosting.co.za>
Message-ID: <1289255921.24.0.228310493256.issue10357@psf.upfronthosting.co.za>


Fergal Daly <fergald at gmail.com> added the comment:

Even if the glossary pointed to collections.html, there are far more methods specified there than are needed to be **able.

The code just calls into the same code as dict.update(dict) (although
.update can also work on a sequence of twouples).

dict.update's doc string is explicit about what it requires from the argument:

 |  update(...)
 |      D.update(E, **F) -> None.  Update D from dict/iterable E and F.
 |      If E has a .keys() method, does:     for k in E: D[k] = E[k]
 |      If E lacks .keys() method, does:     for (k, v) in E: D[k] = v
 |      In either case, this is followed by: for k in F: D[k] = F[k]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10357>
_______________________________________

From report at bugs.python.org  Tue Nov  9 00:07:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 08 Nov 2010 23:07:25 +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: <1289257645.37.0.436853286677.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Fatal Python error: Py_Initialize: Unable to get the locale encoding
> SystemError: NULL result without error in PyObject_Call

Gotcha! r86341 fixes PyUnicode_EncodeFS(): raise an error if _Py_char2wchar_() fails.

The real problem is that PREFIX is not decoded using _Py_charw2char(), but using a C hack: >L"" PREFIX<. It should use _Py_charw2char() as I did for VPATH in r85800.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Tue Nov  9 00:13:21 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 08 Nov 2010 23:13:21 +0000
Subject: [issue10357] ** and "mapping" are poorly defined in python docs
In-Reply-To: <1289222187.72.0.886873143688.issue10357@psf.upfronthosting.co.za>
Message-ID: <1289258001.62.0.623259608123.issue10357@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> Even if the glossary pointed to collections.html, 
> there are far more methods specified there than 
> are needed to be **able.

That is an implementation detail and is subject to
change.  If someone supplies an argument satisfying
collections.Mapping, that should be sufficient across
all implementations.

> dict.update's doc string is explicit about what 
> it requires from the argument:

Duck-typing is still allowed when explicit requirements
have been exposed (we do this a lot with .readline() for
example).  For the most part though, we want to specify
"needs a Mapping" in the sense of collections.Mapping.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10357>
_______________________________________

From report at bugs.python.org  Tue Nov  9 00:21:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 23:21: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: <1289258491.57.0.658888473301.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sorry:

gcc -pthread   -Xlinker -export-dynamic -o python Modules/python.o libpython3.2dmu.a -lpthread -ldl  -lutil   -lm  
Fatal Python error: Py_Initialize: Unable to get the locale encoding
SystemError: NULL result without error in PyObject_Call
Aborted
make: *** [sharedmods] Error 134

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Tue Nov  9 00:25:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 23:25:50 +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: <1289258750.7.0.812455241867.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I should have worn my Stupid Hat today, because I?ve made stupid commits and emails.  I hadn?t updated my checkout when I made my test.  The bad news is that I still have a bug after svn up:

gcc -pthread   -Xlinker -export-dynamic -o python Modules/python.o libpython3.2dmu.a -lpthread -ldl  -lutil   -lm  
Fatal Python error: Py_Initialize: Unable to get the locale encoding
UnicodeEncodeError: 'filesystemencoding' codec can't encode character '\xe9' in position 35: Invalid or incomplete multibyte or wide character
Aborted
make: *** [sharedmods] Error 134

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Tue Nov  9 00:26:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 08 Nov 2010 23:26:07 +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: <1289258767.03.0.764162571729.issue6011@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg120820

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Tue Nov  9 00:42:07 2010
From: report at bugs.python.org (Dan Stromberg)
Date: Mon, 08 Nov 2010 23:42:07 +0000
Subject: [issue10369] tarfile requires an actual file on disc;
	a file-like object is insufficient
In-Reply-To: <1289259727.33.0.210981520326.issue10369@psf.upfronthosting.co.za>
Message-ID: <1289259727.33.0.210981520326.issue10369@psf.upfronthosting.co.za>


New submission from Dan Stromberg <strombrg at gmail.com>:

The tarfile module's gettarinfo callable insists on stat'ing the file in question, preventing one from dynamically generating file content by passing a file-like object for addfile's fileobj argument.

I believe the attached patch fixes this issue.  I generated the patch against 2.7 and tested it with 2.7, but it applies cleanly against 3.1 and "feels innocuous".  I've also included my test code at the bottom of this comment.

Why would you want to do this?  Imagine you've stored a file in three smaller files (perhaps to save the pieces on small external media, or as part of a deduplication system), with the content divided up into thirds.  To subsequently put this file as a whole into a tar archive, it'd be nice if you could just create a file-like object to emit the catenation, rather than having to create a temporary file holding that catenation.

It's occurred to me that this should be done in a more object oriented style, but that feels a bit inconsistent given that fstat is in the os module, and not provided as an attribute of a file(-like) object.  Comments?

Here's the test code:

#!/usr/local/cpython-2.7/bin/python

import os
import sys
import copy
import array
import stat_tarfile

def my_stat(filename):
        class mutable_stat:
                pass
        readonly_statobj = os.lstat(filename)
        mutable_statobj = mutable_stat()
        for attribute in dir(readonly_statobj):
                if not attribute.startswith('_'):
                        value = getattr(readonly_statobj, attribute)
                        setattr(mutable_statobj, attribute, value)
        return mutable_statobj

class generate_file_content:
        def __init__(self, number):
                self._multiplier = 100
                self._multipleno = 0
                self._number = str(number)
                self._buffer = ''

        def read(self, length):
                while self._multipleno < self._multiplier and len(self._buffer) < length:
                        self._buffer += self._number
                        self._multipleno += 1
                if self._buffer == '':
                        return ''
                else:
                        result = self._buffer[:length]
                        self._buffer = self._buffer[length:]
                        return result

def main():
        with stat_tarfile.open(fileobj = sys.stdout, mode = "w|") as tar:
                for number in xrange(100):
                        #string = str(number) * 100
                        fileobj = generate_file_content(number)
                        statobj = my_stat('/etc/passwd')
                        statobj.st_size = len(str(number)) * 100
                        filename = 'file-%d.txt' % number
                        tarinfo = tar.gettarinfo(filename, statobj = statobj)
                        tarinfo.uid = 1000
                        tarinfo.gid = 1000
                        tarinfo.uname = "dstromberg"
                        tarinfo.gname = "dstromberg"
                        tar.addfile(tarinfo, fileobj)

main()

----------
components: Library (Lib)
files: tarfile.diff
keywords: patch
messages: 120822
nosy: strombrg
priority: normal
severity: normal
status: open
title: tarfile requires an actual file on disc; a file-like object is insufficient
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19549/tarfile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10369>
_______________________________________

From report at bugs.python.org  Tue Nov  9 01:07:25 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 09 Nov 2010 00:07:25 +0000
Subject: [issue9199] distutils upload command crashes when displaying server
	response
In-Reply-To: <1278596334.3.0.531936724428.issue9199@psf.upfronthosting.co.za>
Message-ID: <1289261245.97.0.626451552912.issue9199@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

?ric, I see this in Python 2.7, standard release.

Your fix in SVN seems OK, but I am not sure that using "\n" be very platform agnostic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9199>
_______________________________________

From report at bugs.python.org  Tue Nov  9 01:10:19 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 09 Nov 2010 00:10:19 +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: <1289261419.74.0.470687827749.issue10367@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

This is not issue9199, even covering the same line code.

In this case the problem is an exception leaving a local variable undefined, crashing later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Tue Nov  9 01:11:46 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 09 Nov 2010 00:11:46 +0000
Subject: [issue9199] distutils upload command crashes when displaying server
	response
In-Reply-To: <1278596334.3.0.531936724428.issue9199@psf.upfronthosting.co.za>
Message-ID: <1289261506.34.0.726992762834.issue9199@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

This fix doesn't solve issue10367.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9199>
_______________________________________

From report at bugs.python.org  Tue Nov  9 01:25:47 2010
From: report at bugs.python.org (Tom Pinckney)
Date: Tue, 09 Nov 2010 00:25:47 +0000
Subject: [issue2927] expose html.parser.unescape
In-Reply-To: <1211262235.18.0.705526453605.issue2927@psf.upfronthosting.co.za>
Message-ID: <1289262347.49.0.474439494991.issue2927@psf.upfronthosting.co.za>


Tom Pinckney <thomaspinckney3 at gmail.com> added the comment:

New patch attached, tested against Python 3.2. This is my first Python patch so apologies if I've done something wrong here. Feedback appreciated!

Changes:

* fit everything to 80 cols
* just made changes to the HTMLParser.unescape function instead of providing a standalone unescape function
* fixed test case to fix string literals to work in python 3k
* left the cp1252 hacks in there since it looks like they work still, but if there's a problem with them let me know. In practice I have to this at work in order to make unescaping actual web pages work.

----------
Added file: http://bugs.python.org/file19550/unescape.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2927>
_______________________________________

From report at bugs.python.org  Tue Nov  9 01:30:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Nov 2010 00:30:12 +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: <1289262612.74.0.479401908632.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The real problem is that PREFIX is not decoded using _Py_charw2char() ...

Fixed by r86345.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Tue Nov  9 01:55:54 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 09 Nov 2010 00:55:54 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289264154.83.0.248073724129.issue10354@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I sort of agree with David.

The global "template" is a bad name and a bad design. And since it doesn't work I don't think anything would be lost by modifying the code to ignore it; document that it's unused and deprecated; and remove it in a future version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Tue Nov  9 01:56:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Nov 2010 00:56:04 +0000
Subject: [issue10369] tarfile requires an actual file on disc;
	a file-like object is insufficient
In-Reply-To: <1289259727.33.0.210981520326.issue10369@psf.upfronthosting.co.za>
Message-ID: <1289264164.0.0.849389000238.issue10369@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> feature request
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10369>
_______________________________________

From report at bugs.python.org  Tue Nov  9 01:59:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Nov 2010 00:59:26 +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: <1289264366.83.0.851365085265.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Now I get an error in copy_scripts() function of Lib/distutils/command/build_scripts.py: this function adjusts Python shebang of installed Python scripts. The problem is that the shebang contains a non-ASCII character whereas the script is written into the locale encoding, which is ASCII in my test.

test_httpservers has a similar issue: CGIHTTPServerTestCase fails if the Python executable full path is not encodable to utf-8. I fixed simply this issue by skipping the test:

    try:
        # The python executable path is written as the first line of the
        # CGI Python script. The encoding cookie cannot be used, and so the
        # path should be encodable to the default script encoding (utf-8)
        self.pythonexe.encode('utf-8')
    except UnicodeEncodeError:
        self.tearDown()
        raise self.skipTest(
            "Python executable path is not encodable to utf-8")

--

Attached patch, copy_script.patch, fixes this issue by reading the Python script in binary mode. It ensures that the shebang is decodable from utf-8 and the script encoding.

It checks with utf-8 because the shebang is always written before the encoding cookie, and so the parser reads the shebang with the default parser encoding, which is utf-8. Eg. with a shebang not decodable from utf-8:
---
  File "./test.py", line 1
SyntaxError: Non-UTF-8 code starting with '\xff' in file ./blo.py on line 1, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details
---

It checks with the script encoding because when the parser hits the encoding cookie, it restarts to read the whole file with the encoding, and so the parser decodes the shebang from the script encoding.

----------
Added file: http://bugs.python.org/file19551/copy_script.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Tue Nov  9 02:05:16 2010
From: report at bugs.python.org (Brian Warner)
Date: Tue, 09 Nov 2010 01:05:16 +0000
Subject: [issue10370] py3 readlines() reports wrong offset for
	UnicodeDecodeError
In-Reply-To: <1289264715.81.0.326279765732.issue10370@psf.upfronthosting.co.za>
Message-ID: <1289264715.81.0.326279765732.issue10370@psf.upfronthosting.co.za>


New submission from Brian Warner <warner at users.sourceforge.net>:

I noticed that the UnicodeDecodeError exception produced by trying to do open(fn).readlines() (i.e. using the default ASCII encoding) on a file that's actually UTF-8 reports the wrong offset for the first undecodeable character. From what I can tell, it reports (offset%4096) instead of the actual offset.

I've attached a test case. It emits "all good" when run against py2.x (well, after converting the print() expressions back into statements), but reports an error at offset 4096 (reported as "0") on py3.1.2 and py3.2a3 . I'm running on a debian (sid) x86 box.

The misreported offset does not occur with read(), just with readlines().

----------
components: IO
files: test.py
messages: 120830
nosy: warner
priority: normal
severity: normal
status: open
title: py3 readlines() reports wrong offset for UnicodeDecodeError
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19552/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10370>
_______________________________________

From report at bugs.python.org  Tue Nov  9 02:06:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Nov 2010 01:06:55 +0000
Subject: [issue10370] py3 readlines() reports wrong offset for
	UnicodeDecodeError
In-Reply-To: <1289264715.81.0.326279765732.issue10370@psf.upfronthosting.co.za>
Message-ID: <1289264815.28.0.0657478005426.issue10370@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10370>
_______________________________________

From report at bugs.python.org  Tue Nov  9 02:12:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Nov 2010 01:12:04 +0000
Subject: [issue10335] tokenize.open(): open a file with encoding detected from
	a coding cookie
In-Reply-To: <1289040579.7.0.473143443383.issue10335@psf.upfronthosting.co.za>
Message-ID: <1289265124.07.0.196480917841.issue10335@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited to Python 3.2 (r86346 + r86347). Thanks for your reviews.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10335>
_______________________________________

From report at bugs.python.org  Tue Nov  9 02:44:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Nov 2010 01:44:07 +0000
Subject: [issue10370] py3 readlines() reports wrong offset for
	UnicodeDecodeError
In-Reply-To: <1289264715.81.0.326279765732.issue10370@psf.upfronthosting.co.za>
Message-ID: <1289267047.62.0.152857515884.issue10370@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

The error occurs in .readline(): .readline() fills a buffer by reading the file chunk by chunk. Each time a chunk is read, it is decoded by the stateful decoder. The problem is that the decoder doesn't know the file offset. Even if it knew, start and end attributes of UnicodeDecodeError are indexes in the (bytes) object.

> but reports an error at offset 4096 (reported as "0")

4096 is the buffer_size attribute of BufferedReader: .readline() -> ._read_chunk() -> .buffer.read1().

> The misreported offset does not occur with read(), just with readlines().

.read() is special: it reads the whole file at once, and decode binary content at once.

--

I don't consider this issue as a bug, and so I'm closing it as invalid.

--

Use .readline() to locate an invalid byte is not the right algorithm. If you would like to do that, you should open the file in binary mode and decodes the content yourself, chunk by chunk. Or if you manipulate small files, you can use .read() as you wrote.

----------
nosy: +haypo
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10370>
_______________________________________

From report at bugs.python.org  Tue Nov  9 03:32:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 02:32:32 +0000
Subject: [issue10371] Deprecate trace module undocumented API
In-Reply-To: <1289269952.54.0.146506315747.issue10371@psf.upfronthosting.co.za>
Message-ID: <1289269952.54.0.146506315747.issue10371@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Following python-dev discussion on the issue, I would like to propose trace-deprecations.diff patch for review.

I would like to make these changes before turning to issue10342 which will require changing many of these APIs that take a source path to take a module object (or possibly a loader).

Note that CoverageResults presents an interesting case of a class that does not need to be public, but its methods, particularly write_results() need to be documented.

----------
assignee: belopolsky
components: Library (Lib)
files: trace-deprecations.diff
keywords: patch
messages: 120833
nosy: belopolsky
priority: normal
severity: normal
stage: patch review
status: open
title: Deprecate trace module undocumented API
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19553/trace-deprecations.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10371>
_______________________________________

From report at bugs.python.org  Tue Nov  9 03:33:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Nov 2010 02:33:01 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289269981.48.0.886190355126.issue10354@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It has been documented as deprecated since 2.0. I'm sure the intent was for all mention of it to have been deleted from the 3.x docs already, but that first paragraph was overlooked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Tue Nov  9 03:41:50 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Nov 2010 02:41:50 +0000
Subject: [issue10354] tempfile.template is broken
In-Reply-To: <1289215695.29.0.553789101836.issue10354@psf.upfronthosting.co.za>
Message-ID: <1289270510.07.0.0588075884321.issue10354@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 for just deleting it.   nothing is lost by deleting code that never worked in the first place ;-)

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10354>
_______________________________________

From report at bugs.python.org  Tue Nov  9 03:56:18 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 09 Nov 2010 02:56:18 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1289271378.47.0.742299344887.issue10142@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

This is far more complicated that expected, because I would like to modify "file.seek()" to be able to support these flags too. Analizing "Modules/_io/bufferedio.c:buffered_seek()", the logic is pretty convoluted and the ramifications are extensible.

Should I limit myself to "os.lseek()"/"os.read()"/"os.write()"?. This flags are obscure, but useful enough to be useful even with this limitation.

Fut I don't feel comfy with this partial support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Tue Nov  9 03:56:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 02:56:23 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1289271383.15.0.956065974254.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

>From IRC (raymondh):

in the turtle docs, can you add a quick start guide (like we have in the unittest docs)
the turtle docs have grown into a small book and is intimidating to get started with.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Nov  9 03:56:31 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 09 Nov 2010 02:56:31 +0000
Subject: [issue10205] Can't have two tags with the same QName
In-Reply-To: <1288122049.66.0.916624044666.issue10205@psf.upfronthosting.co.za>
Message-ID: <1289271391.12.0.068388962296.issue10205@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r86348 for py3k and r86349 for release27-maint.

In release31-maint, I see that there are missing features, like support for xml_declaration and default_namespace, which are however available in release27-maint. This is not a desirable scenario and I not sure why this difference exists. Additionally, the tests in release31-maint are lacking QName tests which are present in py3k and release27-maint. 

Only after these changes, can this be backported to release31-maint.

----------
assignee:  -> orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10205>
_______________________________________

From report at bugs.python.org  Tue Nov  9 04:13:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 09 Nov 2010 03:13:31 +0000
Subject: [issue3620] test_smtplib is flaky
In-Reply-To: <1219244969.03.0.636728598981.issue3620@psf.upfronthosting.co.za>
Message-ID: <1289272411.97.0.51805565329.issue3620@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looking back over the logs (via bbreport) I don't see any failures of test_smtplib that match the report in this issue.  There were three in the last while, two of which look like network issues on the same machine (and thus probably not a test problem per se) and one of which (solaris) had multiple errors but succeeded when rerun immediately.  

While there maybe a remaining flakiness issue with test_smtplib, it doesn't seem to be the error described here, and I don't think it rates critical.

----------
keywords: +buildbot
priority: critical -> normal
resolution: fixed -> 
stage: committed/rejected -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3620>
_______________________________________

From report at bugs.python.org  Tue Nov  9 04:22:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 03:22:42 +0000
Subject: [issue7061] Improve turtle module documentation
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1289272962.34.0.541980259342.issue7061@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
title: Improve 24.5. turtle doc -> Improve turtle module documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Nov  9 04:30:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 03:30:10 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1289273410.84.0.81383726684.issue10342@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +Deprecate trace module undocumented API

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Tue Nov  9 05:40:47 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 09 Nov 2010 04:40:47 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1289277647.39.0.365630113439.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As per python-dev discussion, we'll keep the old server and GUI implementations intact (but deprecated). The -g command line option will start the old implementation, -p and -b will start the new one.

The APIs to activate the new implementation will start with a leading underscore and can be whatever makes the most sense for what you're doing (the example signatures in my last message are one possibility, but don't take them as mandatory).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Tue Nov  9 06:46:40 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 09 Nov 2010 05:46:40 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1289281600.35.0.541717392784.issue10318@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/issue10318>
_______________________________________

From report at bugs.python.org  Tue Nov  9 07:06:21 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 09 Nov 2010 06:06:21 +0000
Subject: [issue10319] SocketServer.TCPServer truncates responses on close (in
	some situations)
In-Reply-To: <1288935519.72.0.951711716225.issue10319@psf.upfronthosting.co.za>
Message-ID: <1289282781.95.0.376561587453.issue10319@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

jrodman2, in the socketserver TCPServer code you will find that shutdown_request does a socket.SHUT_WR before calling close_request.
If the application or code in your description used shutdown_request, instead of close_request would you still require the kind of drain code?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10319>
_______________________________________

From report at bugs.python.org  Tue Nov  9 07:37:06 2010
From: report at bugs.python.org (jrodman2)
Date: Tue, 09 Nov 2010 06:37:06 +0000
Subject: [issue10319] SocketServer.TCPServer truncates responses on close (in
	some situations)
In-Reply-To: <1288935519.72.0.951711716225.issue10319@psf.upfronthosting.co.za>
Message-ID: <1289284626.99.0.626958095636.issue10319@psf.upfronthosting.co.za>


jrodman2 <jrodman at pythontracker.spamportal.net> added the comment:

shutdown isn't the same as close.
I'm not sure that's correct behavior in BaseHTTPServer depending upon whether it wants to keep the door open to weird pipeline behaviors.

Honestly, I'm having to read through tcp/ip illustrated because of this, so I'm not really the proper person to make the call.
Perhaps the bug is, as you imply, in BaseHTTPServer, not TCPServer.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10319>
_______________________________________

From report at bugs.python.org  Tue Nov  9 07:44:41 2010
From: report at bugs.python.org (Prabhu Gurumurthy)
Date: Tue, 09 Nov 2010 06:44:41 +0000
Subject: [issue10349] Error in Module/python.c when building on OpenBSD 4.8
In-Reply-To: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>
Message-ID: <1289285081.99.0.280656258007.issue10349@psf.upfronthosting.co.za>


Prabhu Gurumurthy <pgurumu at gmail.com> added the comment:

I ran the build "without" cxx_main, I did _not_ see the same error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10349>
_______________________________________

From report at bugs.python.org  Tue Nov  9 09:40:16 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 09 Nov 2010 08:40:16 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <hbf.20101108ho75@bombur.uio.no>
Message-ID: <hbf.20101109uc17@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

No, PY_LLONG_MAX lacks a paren.  Found by the revolutionary method of
actually testing it (made the previous branches #if 0's).
bugs.python.org is not responding, but here's what I'm using now:

Index: Include/pyport.h
===================================================================
--- Include/pyport.h	(revision 86319)
+++ Include/pyport.h	(working copy)
@@ -62,15 +62,20 @@
 #define PY_LLONG_MAX LLONG_MAX
 #define PY_ULLONG_MAX ULLONG_MAX
 #elif defined(__LONG_LONG_MAX__)
-/* Otherwise, if GCC has a builtin define, use that. */
+/* Otherwise, if GCC has a builtin define, use that.  (Definition of
+ * PY_LLONG_MIN assumes two's complement with no trap representation.) */
 #define PY_LLONG_MAX __LONG_LONG_MAX__
-#define PY_LLONG_MIN (-PY_LLONG_MAX-1)
-#define PY_ULLONG_MAX (__LONG_LONG_MAX__*2ULL + 1ULL)
-#else
-/* Otherwise, rely on two's complement. */
-#define PY_ULLONG_MAX (~0ULL)
-#define PY_LLONG_MAX  ((long long)(PY_ULLONG_MAX>>1))
-#define PY_LLONG_MIN (-PY_LLONG_MAX-1)
+#define PY_LLONG_MIN (-PY_LLONG_MAX - 1)
+#define PY_ULLONG_MAX (PY_LLONG_MAX * Py_ULL(2) + 1)
+#elif defined(SIZEOF_LONG_LONG)
+/* Otherwise compute from SIZEOF_LONG_LONG, assuming two's complement, no
+   padding bits, and no trap representation.  Note: PY_ULLONG_MAX was
+   previously #defined as (~0ULL) here; but that'll give the wrong value in a
+   preprocessor expression on systems where long long != intmax_t. */
+#define PY_LLONG_MAX                                                    \
+    (1 + 2 * ((Py_LL(1) << (CHAR_BIT * SIZEOF_LONG_LONG - 2)) - 1))
+#define PY_LLONG_MIN (-PY_LLONG_MAX - 1)
+#define PY_ULLONG_MAX (PY_LLONG_MAX * Py_ULL(2) + 1)
 #endif /* LLONG_MAX */
 #endif
 #endif /* HAVE_LONG_LONG */

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Tue Nov  9 09:42:25 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 09 Nov 2010 08:42:25 +0000
Subject: [issue10312] intcatcher() can deadlock
In-Reply-To: <1288874942.68.0.464773855859.issue10312@psf.upfronthosting.co.za>
Message-ID: <hbf.20101109u2lo@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Sorry, my patch is useless if the OS calls the handler with the signal
blocked.  It should also unblock the signal before doing anything
which can do FILE* operations.  And set the handler again?  Or just
leave the next signal to abort the process?  I dunno...

Anyway, if you don't do that, just apply the save/restore of errno.
Drop the 'if (errno != save_errno)' before restoring, that bit of
paranoia was turned down in Issue10311.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10312>
_______________________________________

From report at bugs.python.org  Tue Nov  9 09:45:33 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 09 Nov 2010 08:45:33 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289228397.65.0.662013581372.issue10359@psf.upfronthosting.co.za>
Message-ID: <hbf.20101109u85y@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

,AIric Araujo writes:
> By the way, do these changes actually fix errors or are they just
> cleanups and pedantic (not a slight) fixes?

I've used compilers where they'd be compile errors, though I found them
just with gcc -pedantic in an idle moment.

> If the latter, I think they won?t go into stable branches.

Not until someone has better time anyway...

About the .zip, it's 3 files (diff against python 3, 2, and both), I'll
upload them as an ascii file with '#####'s between when bugs.python.org
responds again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Tue Nov  9 09:51:38 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 09 Nov 2010 08:51:38 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <90e6ba476adb7467fe04948dcbf2@google.com>
Message-ID: <20cf30549ad507f12004949a88b3@google.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

Fixed docstring.

http://codereview.appspot.com/2874041/diff/2001/cmd.py
File cmd.py (right):

http://codereview.appspot.com/2874041/diff/2001/cmd.py#newcode55
cmd.py:55: :param distutils.dist.Distribution dist: distribution to work
with
On 2010/11/08 18:47:39, merwok wrote:
> > Including this in another patch is too much work to ever happen.
> We?ll have to revert it before committing then.

> > What Python uses?
> Something like ?*dist* is an instance of blah?.

I thought Python uses all Sphinx capabilities. Done.

http://codereview.appspot.com/2874041/diff/2001/command/upload.py
File command/upload.py (right):

http://codereview.appspot.com/2874041/diff/2001/command/upload.py#newcode53
command/upload.py:53: if not self.username and
self.distribution.username:
On 2010/11/08 18:47:39, merwok wrote:
> This is a crazy case.

That's why I don't want to make distinction between "None" username and
empty username. They are both the same in this context.

http://codereview.appspot.com/2874041/diff/2001/tests/test_register.py
File tests/test_register.py (right):

http://codereview.appspot.com/2874041/diff/2001/tests/test_register.py#newcode165
tests/test_register.py:165: inputs = RawInputs('1', 'tarek', 'n')
On 2010/11/08 18:47:39, merwok wrote:
> It looks like you?re replying to ?username? and ?save your login? but
not
> ?password?.

That's magically patched in setUp method.

http://codereview.appspot.com/2874041/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10361>
_______________________________________

From report at bugs.python.org  Tue Nov  9 09:54:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 09 Nov 2010 08:54:55 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1289292895.32.0.47140896285.issue10359@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Hallvard, if it going be a rather huge diff, you may make it available at http://bugs.python.org/review, so that it is easy for review.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Tue Nov  9 10:22:05 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 09 Nov 2010 09:22:05 +0000
Subject: [issue10245] Fix resource warnings in test_telnetlib
In-Reply-To: <1288441077.58.0.74967624488.issue10245@psf.upfronthosting.co.za>
Message-ID: <1289294525.31.0.859042759805.issue10245@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

conn.close() was done in the finally method in r86228 by brian.curtin.
The other change in your patch in very minor space addition after comma. We can leave it to place along with some other code change.

----------
nosy: +brian.curtin, orsenthil
resolution:  -> invalid
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10245>
_______________________________________

From report at bugs.python.org  Tue Nov  9 10:44:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Nov 2010 09:44:59 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1289295899.43.0.275178242611.issue10359@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited a part of your patches:

r86353 Remove ";" after function definition, invalid in ISO C
r86354: [array] int => Py_UNICODE (my commit is a little bit different, but it is based on your patch)
r86355: [_pickle] Remove useless comma, invalid in ISO C
r86356: [_csv] Remove useless (duplicate) initialization

I attach the uncommit part of your patches for 3.2.

--

For libffi, the project is maintained outside Python: you should also post your patch to http://sourceware.org/libffi/

Python-ast.c: why do you move req_name and req_type outside PyAST_obj2mod()?

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file19554/iso_c_32.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Tue Nov  9 10:54:44 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 09 Nov 2010 09:54:44 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289295899.43.0.275178242611.issue10359@psf.upfronthosting.co.za>
Message-ID: <hbf.20101109vowk@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

STINNER Victor writes:
> Python-ast.c: why do you move req_name and req_type outside PyAST_obj2mod()?

Because there's no need to initialize the arrays each time PyAST_obj2mod
is called.  C90-friendly code inside PyAST_obj2mod would be

PyAST_obj2mod(PyObject* ast, PyArena* arena, int mode)
{
    mod_ty res;
    static char *const req_name[] = {"Module", "Expression", "Interactive"};
    PyObject *req_type[];
    req_type[0] = (PyObject*)Module_type;
    req_type[1] = (PyObject*)Expression_type;
    req_type[2] = (PyObject*)Interactive_type;
    ...
}

which is what the current code actually executes.

(I moved req_name to keep it next to req_type in the code.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Tue Nov  9 10:56:27 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 09 Nov 2010 09:56:27 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <hbf.20101109vowk@bombur.uio.no>
Message-ID: <hbf.20101109vpz3@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Hallvard B Furuseth writes:
> (...) which is what the current code actually executes.

Er, I mean, that's what it does with req_type.
The 'static' for req_name is an optimization of the current code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Tue Nov  9 11:02:58 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 09 Nov 2010 10:02:58 +0000
Subject: [issue10324] Modules/binascii.c: simplify expressions
In-Reply-To: <1288960282.63.0.36896617849.issue10324@psf.upfronthosting.co.za>
Message-ID: <1289296978.32.0.0239137514828.issue10324@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

At first, I was worried if this simplification would cause any harm to  readability of the algorithm. Fortunately, it didn't.
Committed in r86357.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10324>
_______________________________________

From report at bugs.python.org  Tue Nov  9 11:05:50 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 09 Nov 2010 10:05:50 +0000
Subject: [issue10372] [REGRESSION] test_gc fails on Mac OSX 10.6
In-Reply-To: <1289297149.99.0.674795586662.issue10372@psf.upfronthosting.co.za>
Message-ID: <1289297149.99.0.674795586662.issue10372@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

py3k r86351,


======================================================================
FAIL: test_garbage_at_shutdown (__main__.GCTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./Lib/test/test_gc.py", line 500, in test_garbage_at_shutdown
    b"shutdown; use", stderr)
AssertionError: b'ResourceWarning: gc: 2 uncollectable objects at shutdown; use' not found in b''

----------------------------------------------------------------------
Ran 28 tests in 0.226s

FAILED (failures=1)
restoring automatic collection
Traceback (most recent call last):
  File "./Lib/test/test_gc.py", line 682, in <module>
    test_main()
  File "./Lib/test/test_gc.py", line 669, in test_main
    run_unittest(GCTests, GCTogglingTests)
  File "/Users/cartman/Sources/py3k/Lib/test/support.py", line 1141, in run_unittest
    _run_suite(suite)
  File "/Users/cartman/Sources/py3k/Lib/test/support.py", line 1124, in _run_suite
    raise TestFailed(err)
test.support.TestFailed: Traceback (most recent call last):
  File "./Lib/test/test_gc.py", line 500, in test_garbage_at_shutdown
    b"shutdown; use", stderr)
AssertionError: b'ResourceWarning: gc: 2 uncollectable objects at shutdown; use' not found in b''

----------
components: Tests
messages: 120854
nosy: cartman
priority: normal
severity: normal
status: open
title: [REGRESSION] test_gc fails on Mac OSX 10.6
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10372>
_______________________________________

From report at bugs.python.org  Tue Nov  9 11:26:07 2010
From: report at bugs.python.org (Valery Khamenya)
Date: Tue, 09 Nov 2010 10:26:07 +0000
Subject: [issue10351] Add autocompletion for keys in dictionaries
In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>
Message-ID: <1289298367.59.0.916130623053.issue10351@psf.upfronthosting.co.za>


Valery Khamenya <khamenya at gmail.com> added the comment:

Hi ?ric, thanks for guiding. 

So, attached is the concatenation of two forward unified diffs for rlcompleter.py and test_rlcompleter.py -- both as of py3k trunk. Tested against Python 3.1.2 though.

P.S. hm, py3k code appeared to be surprisingly nicer -- no unicode troubles and work-arounds at all...

regards
Valery

----------
assignee:  -> docs at python
components: +Documentation
keywords: +patch
nosy: +docs at python
Added file: http://bugs.python.org/file19555/patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10351>
_______________________________________

From report at bugs.python.org  Tue Nov  9 11:36:16 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 09 Nov 2010 10:36:16 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <1289298976.22.0.00727772450539.issue10363@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I don't see a file attached. Could you attach your patches in plain text?
It is the preferred method, since files can be easily viewed in the browser.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________

From report at bugs.python.org  Tue Nov  9 11:37:29 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 09 Nov 2010 10:37:29 +0000
Subject: [issue9873] urllib.parse: Allow bytes in some APIs that use string
	literals internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1289299049.91.0.838429042617.issue9873@psf.upfronthosting.co.za>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

urlunparse(url or params = bytes object) produces a result
with the repr of the bytes object if params is set.

urllib.parse.urlunparse(['http', 'host', '/dir', b'params', '', ''])
--> "http://host/dir;b'params'"

That's confusing since urllib/parse.py goes to a lot of trouble to
support both bytes and str.  Simplest fix is to only accept str:

Index: Lib/urllib/parse.py
@@ -219,5 +219,5 @@ def urlunparse(components):
     scheme, netloc, url, params, query, fragment = components
     if params:
-        url = "%s;%s" % (url, params)
+        url = ';'.join((url, params))
     return urlunsplit((scheme, netloc, url, query, fragment))
 
Some people at comp.lang.python tell me code shouldn't anyway do str()
just in case it is needed like urllib does, not that I can make much
sense of that discussion.  (Subject: harmful str(bytes)).

BTW, the str vs bytes code doesn't have to be quite as painful as in
urllib.parse.  Here is a patch which just rearranges and factors out
some code.
   http://bugs.python.org/file19525/parse.diff

----------
nosy: +hfuru

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Tue Nov  9 11:42:41 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 09 Nov 2010 10:42:41 +0000
Subject: [issue10369] tarfile requires an actual file on disc;
	a file-like object is insufficient
In-Reply-To: <1289259727.33.0.210981520326.issue10369@psf.upfronthosting.co.za>
Message-ID: <1289299361.4.0.0116687672033.issue10369@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Hm, why don't you just do this:

with stat_tarfile.open(fileobj = sys.stdout, mode = "w|") as tar:
    for number in xrange(100):
        fileobj = generate_file_content(number)
        tarinfo = tar.gettarinfo(fileobj=open("/etc/passwd")) 
        tarinfo.name = 'file-%d.txt' % number
        tarinfo.size = len(str(number)) * 100
        tarinfo.uid = 1000
        tarinfo.gid = 1000
        tarinfo.uname = "dstromberg"
        tarinfo.gname = "dstromberg"
        tar.addfile(tarinfo, fileobj)

Wouldn't that work, too? Or am I missing something?

----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10369>
_______________________________________

From report at bugs.python.org  Tue Nov  9 11:45:26 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Nov 2010 10:45:26 +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: <1289299526.37.0.210755657675.issue9857@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/issue9857>
_______________________________________

From report at bugs.python.org  Tue Nov  9 12:10:44 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 09 Nov 2010 11:10:44 +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: <1289301044.66.0.529952563296.issue9709@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

This is the history of the issue:

In r16757 the current version of get_export_symbols() was added to
distutils. This function adds /EXPORT initfunc to the command line.

In 27697 PyMODINIT_FUNC was defined as __declspec(dllexport) void.


I'd suggest to remove get_export_symbols(). This would only affect
extensions that do not use PyMODINIT_FUNC, but that can be easily
repaired.

----------
keywords: +patch
nosy: +loewis, mhammond
Added file: http://bugs.python.org/file19556/initfunc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9709>
_______________________________________

From report at bugs.python.org  Tue Nov  9 12:13:51 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 09 Nov 2010 11:13:51 +0000
Subject: [issue10361] Fix issue 9995 - distutils forces developers to store
	password in cleartext (issue2874041)
In-Reply-To: <90e6ba476adb7467fe04948dcbf2@google.com>
Message-ID: <1289301231.42.0.806494772051.issue10361@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Looks good to me:
the upload command will get the credentials from the session instead of using the existing config at all.

I remember that we changed the behavior to you'd had to set ONLY the user in the rc file, but allowing to pass the user is better since it make the config file optional

----------
components: +Demos and Tools
nosy: +tarek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10361>
_______________________________________

From report at bugs.python.org  Tue Nov  9 12:46:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 09 Nov 2010 11:46:23 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1289303183.03.0.302158839287.issue10359@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I've used compilers where they'd be compile errors, though I found
> them just with gcc -pedantic in an idle moment.

If Victor accepts the patches then they?re useful :)

>> If the latter, I think they won?t go into stable branches.
> Not until someone has better time anyway...

It?s not a question of time but policy: Stable branches (2.7 and 3.1) only get bug fixes, not new features or code cleanups.

> About the .zip, it's 3 files (diff against python 3, 2, and both),
> I'll upload them as an ascii file with '#####'s between

It?s actually easier: ?svn diff file1 dir/file2 dir/file3? produces one valid diff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Tue Nov  9 13:35:28 2010
From: report at bugs.python.org (Martin Dunschen)
Date: Tue, 09 Nov 2010 12:35:28 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <1289306128.52.0.542835880355.issue10363@psf.upfronthosting.co.za>


Martin Dunschen <mdunschen at gmail.com> added the comment:

Here my suggested changes in plain text (I generated these as patches from a diff to the current code):

thread.c:
353a354,359
> void PyThread_fini()
> {
> 	// should assert here that nkeys == 0
> 	PyThread_free_lock(keymutex);
> }
> 


pystate.c:
38a39
> #define HEAD_RELEASE() PyThread_free_lock(head_mutex);
48a50
> #define HEAD_RELEASE() /* Nothing */
140a143
> 	HEAD_RELEASE();
422a426,427
> void PyThread_fini(); // forward
> 
428c433,434
< 	autoInterpreterState = NULL;;
---
> 	autoInterpreterState = NULL;
> PyThread_fini(); // this frees a lock called keymutex in thread.c


import.c
473a474,475
> 
> 	PyThread_free_lock(import_lock);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________

From report at bugs.python.org  Tue Nov  9 14:09:06 2010
From: report at bugs.python.org (Kirk Clendinning)
Date: Tue, 09 Nov 2010 13:09:06 +0000
Subject: [issue10373] Setup Script example incorrect
In-Reply-To: <1289308146.55.0.869173171863.issue10373@psf.upfronthosting.co.za>
Message-ID: <1289308146.55.0.869173171863.issue10373@psf.upfronthosting.co.za>


New submission from Kirk Clendinning <kirk at heliospectra.se>:

In 2.7. Installing Additional Files the example shows:

setup(...,
      data_files=[('bitmaps', ['bm/b1.gif', 'bm/b2.gif']),
                  ('config', ['cfg/data.cfg']),
                  ('/etc/init.d', ['init-script'])]
     )

However, running easy_install with setuptools results in a error:

Setup script exited with error: SandboxViolation: open('/etc/init.d/init-script', 'wb') {}

Perhaps the documentation should be changed and more explanation added.

----------
assignee: docs at python
components: Documentation
messages: 120863
nosy: docs at python, lensart
priority: normal
severity: normal
status: open
title: Setup Script example incorrect
type: behavior
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10373>
_______________________________________

From report at bugs.python.org  Tue Nov  9 14:11:29 2010
From: report at bugs.python.org (Geoffrey Bache)
Date: Tue, 09 Nov 2010 13:11:29 +0000
Subject: [issue10374] setup.py caches outdated scripts in the build tree
In-Reply-To: <1289308289.62.0.579780588392.issue10374@psf.upfronthosting.co.za>
Message-ID: <1289308289.62.0.579780588392.issue10374@psf.upfronthosting.co.za>


New submission from Geoffrey Bache <gjb1002 at users.sourceforge.net>:

I have the following setup.py script:

#!/usr/bin/env python
from distutils.core import setup

scripts=["hello.py"]

setup(scripts=scripts)

I have two different python installations (using virtualenv) where I
wish to install this program. So I do

~/tmp/test_setup/python1/bin/python setup.py install

which creates a file at
/users/geoff/tmp/test_setup/python1/bin/hello.py, that looks like
this:

#!/users/geoff/tmp/test_setup/python1/bin/python

print "Hello"

So far so good. But then I also install it somewhere else:

~/tmp/test_setup/python2/bin/python setup.py install

which creates a file at
/users/geoff/tmp/test_setup/python2/bin/hello.py which refers to
"python1", i..e it has the same contents as the first one. Which is
clearly not what I want.

The cached script in the build tree appears not to get updated once it exists.

----------
assignee: tarek
components: Distutils
messages: 120864
nosy: eric.araujo, gjb1002, tarek
priority: normal
severity: normal
status: open
title: setup.py caches outdated scripts in the build tree
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10374>
_______________________________________

From report at bugs.python.org  Tue Nov  9 15:05:12 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 09 Nov 2010 14:05:12 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1289311512.85.0.23260550621.issue10070@psf.upfronthosting.co.za>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Hi, I'm back...  I've been reading your last message a few times
and I'm not sure what I'm to reconsider.  We've had a way of
talking past each toerh before, as far as I can remember.

I think my request still now translates to:

- keep the current behavior by default,
- add some option which does not translate certain code blocks,
- these code blocks could be the syntax we've already discussed,
  or something else.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Nov  9 15:12:22 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 09 Nov 2010 14:12:22 +0000
Subject: [issue10375] 2to3 print(single argument)
In-Reply-To: <1289311942.35.0.609245522343.issue10375@psf.upfronthosting.co.za>
Message-ID: <1289311942.35.0.609245522343.issue10375@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Could 2to3 without -p notice more cases of print(single argument),
to avoid slapping another () around them?  For example:

  print(2*3)
  print(", ".join(dir))
  print(very + long
        + single + argument)

My internal bug detector zooms in on ((foo)) when I read Python code -
I'm seeing code where something was apparently left out, maybe an inner
comma to make it a tuple.

[Copied from Issue10070.]

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 120866
nosy: hfuru
priority: normal
severity: normal
status: open
title: 2to3 print(single argument)
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10375>
_______________________________________

From report at bugs.python.org  Tue Nov  9 15:18:12 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 09 Nov 2010 14:18:12 +0000
Subject: [issue960325] "--require <feature>" option for configure/make (fail
	if building not possible)
In-Reply-To: <1288899875.17.0.241244944921.issue960325@psf.upfronthosting.co.za>
Message-ID: <hbf.20101109afmo@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Just for the record, I think you read this a bit too fast before
closing:

Terry J. Reedy writes:
> I am closing this as some combination of wrong, inapplicable,
> out-of-date, and postponed.
> 
> 1. (...) For bz2, there is "This module provides a
> comprehensive interface for the bz2 compression library." If the library
> is not there, then the module obviously cannot function.

The point of the request was to move that error from runtime to compile
time.  As a configuration option, not by default, since as you say:

> 2. I think the current default build process is right for most users.

Indeed.

> 4. This seems to have become pretty much a non-issue. The OP says he has
> no further concrete interest because "It's been a while since I had a
> computer without these libraries...". I am suspecting this is pretty
> much true for everyone who might otherwise care enough to provide a
> patch.

Half right - actually I _would_ still prefer that bit of safety, but
OTOH I probably won't be providing a patch anytime soon.  (Still, I can
always reopen the issue if I do write one.)

----------
title: "--require <feature>" option for configure/make  (fail if building not possible) -> "--require <feature>" option for configure/make (fail if building not possible)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue960325>
_______________________________________

From report at bugs.python.org  Tue Nov  9 15:53:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 14:53:23 +0000
Subject: [issue7061] Improve turtle module documentation
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1289314403.14.0.241318159497.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As a follow-up to Raymond's suggestion, I am attaching a patch that will add a sidebar to the introduction section of the turtle documentation section.  While it is not common to include screenshots in python documentation, I think it is very appropriate for a visual module such as turtle.  I considered a "Basic example" subsection similar to that in unittest module documentation, but turtle introduction already has a basic example (forward(15); left(25) embedded in the prose, so I think a sidebar like this is more appropriate. 

Since svn does not include binary files in the patch, I will have to attach the embedded image separately.  I will also post a screenshot of the rendered HTML page.

----------
Added file: http://bugs.python.org/file19557/turtle-star-sidebar.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Nov  9 15:54:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 14:54:09 +0000
Subject: [issue7061] Improve turtle module documentation
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1289314449.77.0.782139895946.issue7061@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file19558/turtle-star.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Nov  9 15:55:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 14:55:05 +0000
Subject: [issue7061] Improve turtle module documentation
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1289314505.01.0.140886537984.issue7061@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file19559/turtle-sidebar-screenshot.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Nov  9 16:26:52 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Nov 2010 15:26:52 +0000
Subject: [issue7061] Improve turtle module documentation
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1289316412.39.0.522687617612.issue7061@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I like it!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Nov  9 16:39:24 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Nov 2010 15:39:24 +0000
Subject: [issue960325] "--require <feature>" option for configure/make (fail
	if building not possible)
Message-ID: <1289317164.73.0.619259225577.issue960325@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Yes, this could be reopened with a patch. Someone else would have to judge its usefulness and acceptability. So no guarantees.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue960325>
_______________________________________

From report at bugs.python.org  Tue Nov  9 16:48:22 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Nov 2010 15:48:22 +0000
Subject: [issue8315] ./python -m unittest test.test_importlib doesn't work
In-Reply-To: <1270481793.28.0.468676978723.issue8315@psf.upfronthosting.co.za>
Message-ID: <1289317702.62.0.545697318229.issue8315@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/issue8315>
_______________________________________

From report at bugs.python.org  Tue Nov  9 16:51:55 2010
From: report at bugs.python.org (James Hutchison)
Date: Tue, 09 Nov 2010 15:51:55 +0000
Subject: [issue10376] ZipFile unzip is unbuffered
In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>
Message-ID: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>


New submission from James Hutchison <jamesghutchison at gmail.com>:

The Unzip module is always unbuffered (tested v.3.1.2 Windows XP, 32-bit). This means that if one has to do many small reads it is a lot slower than reading a chunk of data to a buffer and then reading from that buffer. It seems logical that the unzip module should default to buffered reading and/or have a buffered argument. Likewise, the documentation should clarify that there is no buffering involved when doing a read, which runs contrary to the default behavior of a normal read.

start Zipfile read
done
27432 reads done
took 0.859 seconds
start buffered Zipfile read
done
27432 reads done
took 0.072 seconds
start normal read (default buffer)
done
27432 reads done
took 0.139 seconds
start buffered normal read
done
27432
took 0.137 seconds

----------
assignee: docs at python
components: Documentation, IO, Library (Lib)
messages: 120871
nosy: Jimbofbx, docs at python
priority: normal
severity: normal
status: open
title: ZipFile unzip is unbuffered
type: performance
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10376>
_______________________________________

From report at bugs.python.org  Tue Nov  9 16:52:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 15:52:54 +0000
Subject: [issue7061] Improve turtle module documentation
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1289317974.74.0.0517596923335.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Oct 30, 2010 at 8:27 PM, Terry J. Reedy <report at bugs.python.org> wrote:
..
> Sections about 2.x changes should not be in 3.x docs.

I agree.  Neither "Changes since Python 2.6" nor "Changes since Python 2.6" belong in this section.  The first belongs to "What's new in Python 2.7" and the second to "What's new in Python 3.1".  Do we edit these files retroactively?  I don't want to simply remove these sections.  Raymond, can you advise?

On a similar note, I don't think the introduction section should refer to "the old turtle module".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Nov  9 16:55:17 2010
From: report at bugs.python.org (James Hutchison)
Date: Tue, 09 Nov 2010 15:55:17 +0000
Subject: [issue10376] ZipFile unzip is unbuffered
In-Reply-To: <1289317915.09.0.657677437465.issue10376@psf.upfronthosting.co.za>
Message-ID: <1289318117.85.0.369237202019.issue10376@psf.upfronthosting.co.za>


James Hutchison <jamesghutchison at gmail.com> added the comment:

I should clarify that this is the zipfile constructor I am using:

zipfile.ZipFile(filename, mode='r', allowZip64=True);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10376>
_______________________________________

From report at bugs.python.org  Tue Nov  9 17:08:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Nov 2010 16:08:41 +0000
Subject: [issue10372] [REGRESSION] test_gc fails in non-debug mode.
In-Reply-To: <1289297149.99.0.674795586662.issue10372@psf.upfronthosting.co.za>
Message-ID: <1289318921.42.0.728596263446.issue10372@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For some reason, this starts happening with the Lib/tokenize.py change in r86346. Resource warnings don't get enabled by -Wd:

With r86345:
$ ./python -Wd -c "open('LICENSE')"
-c:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='LICENSE' encoding='UTF-8'>

With r86346:
$ ./python -Wd -c "open('LICENSE')"

But enabling warnings programmatically still works:

$ ./python -c "import warnings; warnings.simplefilter('default'); open('LICENSE')"
-c:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='LICENSE' encoding='UTF-8'>

----------
assignee:  -> haypo
components: +Library (Lib)
nosy: +georg.brandl, haypo, pitrou
priority: normal -> high
stage:  -> needs patch
title: [REGRESSION] test_gc fails on Mac OSX 10.6 -> [REGRESSION] test_gc fails in non-debug mode.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10372>
_______________________________________

From report at bugs.python.org  Tue Nov  9 17:14:54 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Tue, 09 Nov 2010 16:14:54 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1289319294.14.0.457776996542.issue9995@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Eric, interested parties will not fill CVE or DSA requests. They will just steal the pass of PyPI uploaders and use it to inject malicious code into popular packages.

If you need a CVE or DSA to evaluate if an issue imposes a security risk, then better leave this task to somebody else.

----------
type: behavior -> security

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9995>
_______________________________________

From report at bugs.python.org  Tue Nov  9 17:17:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 09 Nov 2010 16:17:56 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1289319476.51.0.0230764045798.issue9995@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: security -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9995>
_______________________________________

From report at bugs.python.org  Tue Nov  9 17:19:08 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 09 Nov 2010 16:19:08 +0000
Subject: [issue9995] "setup.py register sdist upload" requires pass to be saved
In-Reply-To: <1285838842.84.0.5702466564.issue9995@psf.upfronthosting.co.za>
Message-ID: <1289319548.94.0.498709945691.issue9995@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Please stop changing this flag. If you want to have a more secure PyPI transaction, you should first send a feature request on Catalog-SIG so pypi.python.org forces https.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9995>
_______________________________________

From report at bugs.python.org  Tue Nov  9 17:22:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Nov 2010 16:22:43 +0000
Subject: [issue10372] [REGRESSION] test_gc fails in non-debug mode.
In-Reply-To: <1289297149.99.0.674795586662.issue10372@psf.upfronthosting.co.za>
Message-ID: <1289319763.44.0.311316741809.issue10372@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Weirdly, this patch fixes the issue, but I'm unable to say why:


diff -r cd1de1ff2657 Lib/tokenize.py
--- a/Lib/tokenize.py   Tue Nov 09 02:08:59 2010 +0100
+++ b/Lib/tokenize.py   Tue Nov 09 17:16:21 2010 +0100
@@ -24,12 +24,12 @@ __author__ = 'Ka-Ping Yee <ping at lfw.org>
 __credits__ = ('GvR, ESR, Tim Peters, Thomas Wouters, Fred Drake, '
                'Skip Montanaro, Raymond Hettinger, Trent Nelson, '
                'Michael Foord')
+import io
 import re
 import sys
 from token import *
 from codecs import lookup, BOM_UTF8
 import collections
-from io import TextIOWrapper
 cookie_re = re.compile("coding[:=]\s*([-\w.]+)")
 
 import token
@@ -336,16 +336,14 @@ def detect_encoding(readline):
     return default, [first, second]
 
 
-_builtin_open = open
-
 def open(filename):
     """Open a file in read only mode using the encoding detected by
     detect_encoding().
     """
-    buffer = _builtin_open(filename, 'rb')
+    buffer = io.open(filename, 'rb')
     encoding, lines = detect_encoding(buffer.readline)
     buffer.seek(0)
-    text = TextIOWrapper(buffer, encoding, line_buffering=True)
+    text = io.TextIOWrapper(buffer, encoding, line_buffering=True)
     text.mode = 'r'
     return text

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10372>
_______________________________________

From report at bugs.python.org  Tue Nov  9 17:25:33 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 09 Nov 2010 16:25:33 +0000
Subject: [issue10374] setup.py caches outdated scripts in the build tree
In-Reply-To: <1289308289.62.0.579780588392.issue10374@psf.upfronthosting.co.za>
Message-ID: <1289319933.95.0.569710873626.issue10374@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

As described in distutils-SIG, we need to work on a clever way to update the build tree.

For Distutils1, removing it completely (possibly via the clean command) is what people can do.

----------
components: +Distutils2 -Distutils
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10374>
_______________________________________

From report at bugs.python.org  Tue Nov  9 17:34:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Nov 2010 16:34:45 +0000
Subject: [issue10372] [REGRESSION] test_gc fails in non-debug mode.
In-Reply-To: <1289297149.99.0.674795586662.issue10372@psf.upfronthosting.co.za>
Message-ID: <1289320485.67.0.222625931628.issue10372@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

One observation is that when the -W option is used, the "warnings" module gets loaded very early and itself imports linecache which then imports tokenize. At this point, the standard IO streams have not been initialized (_io is imported later) and the builtin "open" may not exist at all. So when tokenize references "open", it is a NameError at that point (which explains why the "weird fix" above is actually correct).

As an additional annoyance, when importing Lib/warnings.py fails (for example if you sneak in a "1/0" at the beginning of the file), the exception gets silenced: the NameError above doesn't get printed.

----------
nosy: +benjamin.peterson, brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10372>
_______________________________________

From report at bugs.python.org  Tue Nov  9 17:45:36 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 09 Nov 2010 16:45:36 +0000
Subject: [issue7061] Improve turtle module documentation
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1289321136.23.0.232260553624.issue7061@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The mini change log is harmless.  I would leave it as is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Nov  9 17:46:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 16:46:32 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1289321192.07.0.380272666306.issue10318@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would like to add my +1 to Eric's msg120485 above.  What I really find puzzling is why some scripts in Tools/ have hashbangs, but don't have execute permission.

Tools/scripts/cleanfuture.py
Tools/scripts/combinerefs.py
Tools/scripts/db2pickle.py
Tools/scripts/find_recursionlimit.py
Tools/scripts/md5sum.py
Tools/scripts/pickle2db.py
Tools/scripts/pysource.py
Tools/scripts/svneol.py

I suggest a simple rule: no execute bit set in permissions - no hashbang line.

And I don't think stdlib modules should have execute bit:

-rwxr-xr-x Lib/base64.py
-rwxr-xr-x Lib/cProfile.py
-rwxr-xr-x Lib/cgi.py
-rwxr-xr-x Lib/keyword.py
-rwxr-xr-x Lib/pdb.py
-rwxr-xr-x Lib/platform.py
-rwxr-xr-x Lib/profile.py
-rwxr-xr-x Lib/pydoc.py
-rwxr-xr-x Lib/quopri.py
-rwxr-xr-x Lib/smtpd.py
-rwxr-xr-x Lib/smtplib.py
-rwxr-xr-x Lib/symbol.py
-rwxr-xr-x Lib/tabnanny.py
-rwxr-xr-x Lib/token.py
-rwxr-xr-x Lib/uu.py

-rwxr-xr-x Lib/test/pystone.py
-rwxr-xr-x Lib/test/re_tests.py
-rwxr-xr-x Lib/test/regrtest.py
-rwxr-xr-x Lib/test/test_array.py
-rwxr-xr-x Lib/test/test_binhex.py
-rwxr-xr-x Lib/test/test_dbm_gnu.py
-rwxr-xr-x Lib/test/test_dbm_ndbm.py
-rwxr-xr-x Lib/test/test_errno.py
-rwxr-xr-x Lib/test/test_userstring.py

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Tue Nov  9 18:01:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 17:01:13 +0000
Subject: [issue7061] Improve turtle module documentation
In-Reply-To: <1289321136.23.0.232260553624.issue7061@psf.upfronthosting.co.za>
Message-ID: <AANLkTimwZpjahrfGyM8Sw3KJ4Q8_Ktr1y_5FLm04N3kf@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Nov 9, 2010 at 11:45 AM, Raymond Hettinger
<report at bugs.python.org> wrote:
..
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
>
> The mini change log is harmless. ?I would leave it as is.

It is not entirely harmless.  First, it occupies valuable easy to
scroll to end-of-page real estate which is better used for the "Demo
scripts" section.  Second, "Changes since 3.0" in 3.2 documentation
without  "Changes since 3.1" give a feel of unmaintained module.
Third, "Changes since 3.0" refers to the Demo directory which no
longer exists and I don't want to add "Changes since 3.1" to fix that.
 However, I don't feel too strongly about removing them.  I would
leave this for the "What's new" editor to decide and if that's
Raymond, I guess the decision has been made.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Nov  9 18:25:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 17:25:30 +0000
Subject: [issue10371] Deprecate trace module undocumented API
In-Reply-To: <1289269952.54.0.146506315747.issue10371@psf.upfronthosting.co.za>
Message-ID: <1289323530.52.0.160179864775.issue10371@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +brett.cannon, eli.bendersky, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10371>
_______________________________________

From report at bugs.python.org  Tue Nov  9 19:04:50 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Tue, 09 Nov 2010 18:04:50 +0000
Subject: [issue10329] trace.py and unicode in Python 3
In-Reply-To: <1289213297.51.0.299688121399.issue10329@psf.upfronthosting.co.za>
Message-ID: <4CD98D13.1020908@livinglogic.de>


Walter D?rwald <walter at livinglogic.de> added the comment:

> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> ... it complicates handling of the output of trace.py. 
>> For each file you have to do the encoding detection dance again ...
> 
> What? You just have to call one function! tokenize.open() :-) Well, ok, 
> it's not commited yet, but it looks like most people agree: #10335.

The problem is that the script that downloads and builds the Python
source and generates the HTML for http://coverage.livinglogic.de/ isn't
ported to Python 3 yet (and can't be ported easily). However *running*
the test suite of course uses the current Python checkout, so an option
that lets me specify which encoding trace.py/regrtest.py should output
would be helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10329>
_______________________________________

From report at bugs.python.org  Tue Nov  9 19:07:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Nov 2010 18:07:49 +0000
Subject: [issue10372] [REGRESSION] test_gc fails in non-debug mode.
In-Reply-To: <1289297149.99.0.674795586662.issue10372@psf.upfronthosting.co.za>
Message-ID: <1289326069.9.0.226774829423.issue10372@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch. It moves warnings initialization after io initialization (the latter being arguably more critical than the former). Also adds two tests.

----------
assignee: haypo -> 
keywords: +patch
stage: needs patch -> patch review
versions: +Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19560/warnboot.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10372>
_______________________________________

From report at bugs.python.org  Tue Nov  9 19:12:15 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Nov 2010 18:12:15 +0000
Subject: [issue7061] Improve turtle module documentation
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1289326335.49.0.526130164544.issue7061@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To me, the mini change logs are both distracting noise and contrary to the general start-fresh policy for 3.x docs, stated somewhere by Georg B, which I really like.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Nov  9 19:17:49 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 09 Nov 2010 18:17:49 +0000
Subject: [issue10371] Deprecate trace module undocumented API
In-Reply-To: <1289269952.54.0.146506315747.issue10371@psf.upfronthosting.co.za>
Message-ID: <1289326669.46.0.316850126015.issue10371@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Looks good in a cursory reading. I presume trace test still passes.

If you change the signature of the renamed functions, that would break the current wrappings. Would you use new private functions with different names, or change the wrappings where possible?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10371>
_______________________________________

From report at bugs.python.org  Tue Nov  9 19:20:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 09 Nov 2010 18:20:53 +0000
Subject: [issue10372] [REGRESSION] test_gc fails in non-debug mode.
In-Reply-To: <1289297149.99.0.674795586662.issue10372@psf.upfronthosting.co.za>
Message-ID: <1289326853.94.0.140234354684.issue10372@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I also wrote a patch for the warnings error silently ignored: import_warnings_error.patch.

----------
Added file: http://bugs.python.org/file19561/import_warnings_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10372>
_______________________________________

From report at bugs.python.org  Tue Nov  9 19:46:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 09 Nov 2010 18:46:33 +0000
Subject: [issue7061] Improve turtle module documentation
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1289328393.98.0.900190004869.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed a slightly modified turtle-star-sidebar.diff in revision 86364.  Note that I've included both pdf and postscript files in case someone would want to run postscript through a better distiller than the OSX preview that I used.  The postscript was produced using postscript() method of the tkinter canvas and bbox was manually adjusted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Nov  9 19:59:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Nov 2010 18:59:49 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1201200095.82.0.748607504278.issue1926@psf.upfronthosting.co.za>
Message-ID: <1289329189.71.0.807362825459.issue1926@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I have committed the patch in r86365, and I've made usenetrc False by default in r86366. Thanks for contributing!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Tue Nov  9 20:15:57 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Tue, 09 Nov 2010 19:15:57 +0000
Subject: [issue10377] cProfile incorrectly labels its output
In-Reply-To: <1289330157.64.0.804847448743.issue10377@psf.upfronthosting.co.za>
Message-ID: <1289330157.64.0.804847448743.issue10377@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

Consider this transcript:

>>> cProfile.run("import time; time.sleep(1)")
         4 function calls in 1.012 CPU seconds

   Ordered by: standard name

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
        1    0.011    0.011    1.012    1.012 <string>:1(<module>)
        1    0.000    0.000    1.012    1.012 {built-in method exec}
        1    1.001    1.001    1.001    1.001 {built-in method sleep}
        1    0.000    0.000    0.000    0.000 {method 'disable' of '_lsprof.Profiler' objects}


>>> 

It is not the case that the profiled code uses >1 CPU seconds.  It spends the entire time sleeping.  The default timer for cProfile is a wallclock timer.  The output should reflect this.

----------
messages: 120890
nosy: exarkun
priority: normal
severity: normal
status: open
title: cProfile incorrectly labels its output
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10377>
_______________________________________

From report at bugs.python.org  Tue Nov  9 20:31:44 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Tue, 09 Nov 2010 19:31:44 +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: <1289331104.86.0.332942102504.issue10367@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

To better show what the problem is, here's a change that would fix the problem (albeit in an ugly way):

--- upload.py   2010-07-07 20:16:33.000000000 -0400
+++ /home/pje/upload.new        2010-11-09 14:30:21.000000000 -0500
@@ -167,6 +167,9 @@
 
         request = Request(self.repository, data=body,
                           headers=headers)
+
+        result = None
+
         # send the data
         try:
             result = urlopen(request)
@@ -186,4 +189,4 @@
             self.announce('Upload failed (%s): %s' % (status, reason),
                           log.ERROR)
         if self.show_response:
-            self.announce('-'*75, result.read(), '-'*75)
+            self.announce('-'*75, result.read() if result is not None else 'ERROR', '-'*75)

----------
nosy: +pje
resolution: duplicate -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Tue Nov  9 20:33:40 2010
From: report at bugs.python.org (Brian Warner)
Date: Tue, 09 Nov 2010 19:33:40 +0000
Subject: [issue10370] py3 readlines() reports wrong offset for
	UnicodeDecodeError
In-Reply-To: <1289264715.81.0.326279765732.issue10370@psf.upfronthosting.co.za>
Message-ID: <1289331220.96.0.543093969258.issue10370@psf.upfronthosting.co.za>


Brian Warner <warner at users.sourceforge.net> added the comment:

> Use .readline() to locate an invalid byte is not the right algorithm. If
> you would like to do that, you should open the file in binary mode and
> decodes the content yourself, chunk by chunk. Or if you manipulate small
> files, you can use .read() as you wrote.

Oh, I agree that readline() is inappropriate as a validation tool. My
specific complaint is that the error message is misleading. I hit a message
like this:

 UnicodeDecodeError: 'ascii' codec can't decode byte 0xe2 in position 26: ordinal not in range(128)

and wanted to know if the file was UTF-8, or latin-1, or some other encoding,
so I wanted to see that 0xe2 in context. The message said to look at offset
26, but the actual problem might be at 4122, or 8218, etc. It took me several
minutes (and hexdump and grepping for ' e2 ') to find the character and
figure out what was going on.

Perhaps, if the error message cannot report a correct offset, then it
shouldn't be reporting an offset at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10370>
_______________________________________

From report at bugs.python.org  Tue Nov  9 20:34:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 09 Nov 2010 19:34:40 +0000
Subject: [issue10370] py3 readlines() reports wrong offset for
	UnicodeDecodeError
In-Reply-To: <1289264715.81.0.326279765732.issue10370@psf.upfronthosting.co.za>
Message-ID: <1289331280.11.0.0864480857139.issue10370@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/issue10370>
_______________________________________

From report at bugs.python.org  Tue Nov  9 20:36:36 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Tue, 09 Nov 2010 19:36:36 +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: <1289331396.29.0.671588433352.issue10367@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Btw, a quick review of the 3.x trunk code for this shows that it does *not* have this problem; this is specific to 2.7 and AFAICT *only* 2.7.

(This problem was introduced in r73436, btw, as of the move to urllib2 vs. httplib.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Tue Nov  9 20:37:12 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Tue, 09 Nov 2010 19:37:12 +0000
Subject: [issue9199] distutils upload command crashes when displaying server
	response
In-Reply-To: <1278596334.3.0.531936724428.issue9199@psf.upfronthosting.co.za>
Message-ID: <1289331432.76.0.217821992154.issue9199@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Confirmed - issue10367 is not a dupe.  This bug was that a *successful* upload would crash; issue10367 occurs only in the HTTPError case, and isn't fixed by this issue's patch.  Reclosing this and reopening 10367.

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9199>
_______________________________________

From report at bugs.python.org  Tue Nov  9 20:47:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 09 Nov 2010 19:47:29 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1289332049.46.0.37828514943.issue10070@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

And I still don't understand the rationale for this request. Can you please post an example Python module that has this markup you are asking for, so I can show you how to achieve what you want without the markup?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Nov  9 21:10:42 2010
From: report at bugs.python.org (Andrew Vant)
Date: Tue, 09 Nov 2010 20:10:42 +0000
Subject: [issue1926] NNTPS support in nntplib
In-Reply-To: <1289329189.71.0.807362825459.issue1926@psf.upfronthosting.co.za>
Message-ID: <4CD9AAB9.13847.1061EAF5@ajvant.gmail.com>


Andrew Vant <ajvant at gmail.com> added the comment:

On 9 Nov 2010 at 18:59, Antoine Pitrou wrote:
> I have committed the patch in r86365, and I've made usenetrc 
> False by default in r86366. Thanks for contributing!

Woot. I thank you. 

Regarding usenetrc, the NNTP.login and NNTP.starttls documentation 
assumed it was true by default (correct when I wrote it) and 
mentioned it had to be forced false for starttls to work in some 
cases. 

I'm glad that's not the case anymore but the documentation as I wrote 
it is wrong now. :-) 

--

Andrew

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1926>
_______________________________________

From report at bugs.python.org  Tue Nov  9 21:21:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Nov 2010 20:21:39 +0000
Subject: [issue10022] Emit more information in decoded SSL certificates
In-Reply-To: <1286209935.64.0.606028166295.issue10022@psf.upfronthosting.co.za>
Message-ID: <1289334099.62.0.00545175649357.issue10022@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r86369.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10022>
_______________________________________

From report at bugs.python.org  Tue Nov  9 21:28:39 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Tue, 09 Nov 2010 20:28:39 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1289334519.29.0.191497756659.issue7978@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Any news on this? Could we possibly apply patch as is? If I'm not mistaken timeout issue is the only one left unresolved.

About timeout. The most elegant way, would be to use select's syscall timeout parameter, but man 2 select says: "On  Linux,  select()  modifies  timeout to reflect the amount of time not slept; most other implementations do not do this. (POSIX.1-2001 permits either behavior.)  This causes problems both when Linux code which reads timeout is ported to other operating systems, and when code is ported to Linux that reuses a struct timeval for  multiple select()s in a loop without reinitializing it. Consider timeout to be undefined after select() returns."

I'm ready to adapt Yaniv's patch to 2.7

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Tue Nov  9 21:40:53 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Tue, 09 Nov 2010 20:40:53 +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: <1289335253.53.0.254756506179.issue1195@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Confirming that issue is present in latest svn checkout and Ralf's fix helps.

----------
nosy: +nvetoshkin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1195>
_______________________________________

From report at bugs.python.org  Tue Nov  9 22:00:53 2010
From: report at bugs.python.org (Richard Fuhr)
Date: Tue, 09 Nov 2010 21:00:53 +0000
Subject: [issue10378] Typo in results of help(divmod)
In-Reply-To: <1289336453.31.0.743925531352.issue10378@psf.upfronthosting.co.za>
Message-ID: <1289336453.31.0.743925531352.issue10378@psf.upfronthosting.co.za>


New submission from Richard Fuhr <richard.fuhr at gmail.com>:

When running Python 2.7 if you invoke 

help(divmod)

the first line of the resulting help displays

Help on built-in function divmod in module __builtin__:

but I believe that the name of the module is __builtins__

so the line should say

Help on built-in function divmod in module __builtinsq__:

----------
assignee: docs at python
components: Documentation
messages: 120900
nosy: docs at python, rdfuhr
priority: normal
severity: normal
status: open
title: Typo in results of help(divmod)
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10378>
_______________________________________

From report at bugs.python.org  Tue Nov  9 22:04:41 2010
From: report at bugs.python.org (Richard Fuhr)
Date: Tue, 09 Nov 2010 21:04:41 +0000
Subject: [issue10378] Typo in results of help(divmod)
In-Reply-To: <1289336453.31.0.743925531352.issue10378@psf.upfronthosting.co.za>
Message-ID: <1289336681.15.0.303453593026.issue10378@psf.upfronthosting.co.za>


Richard Fuhr <richard.fuhr at gmail.com> added the comment:

I had a typo in my own bug report that was reporting a typo; what I intended to say was the following ( the q should not have been there at the end )

When running Python 2.7 if you invoke 

help(divmod)

the first line of the resulting help displays

Help on built-in function divmod in module __builtin__:

but I believe that the name of the module is __builtins__

so the line should say

Help on built-in function divmod in module __builtins__:

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10378>
_______________________________________

From report at bugs.python.org  Wed Nov 10 00:02:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Nov 2010 23:02:50 +0000
Subject: [issue4471] IMAP4 missing support for starttls
In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za>
Message-ID: <1289343770.98.0.519288969698.issue4471@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed some of the remote tests in r86380, which also helped me fix a bug in login() in 3.x.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4471>
_______________________________________

From report at bugs.python.org  Wed Nov 10 00:17:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Nov 2010 23:17:44 +0000
Subject: [issue4471] IMAP4 missing support for starttls
In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za>
Message-ID: <1289344664.7.0.0762793874476.issue4471@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The shutdown change was committed in r86383.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4471>
_______________________________________

From report at bugs.python.org  Wed Nov 10 00:30:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 09 Nov 2010 23:30:02 +0000
Subject: [issue4471] IMAP4 missing support for starttls
In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za>
Message-ID: <1289345402.65.0.361767850556.issue4471@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated STARTTLS patch for py3k.

----------
stage:  -> patch review
type:  -> feature request
versions: +Python 3.2 -Python 2.6
Added file: http://bugs.python.org/file19562/imaptls.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4471>
_______________________________________

From report at bugs.python.org  Wed Nov 10 00:33:27 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Nov 2010 23:33:27 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

@mission[~:1001]% python2.7 -c "import locale; print locale.format('%.0f KB', 100)"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/lib/python2.7/locale.py", line 189, in format
    "format specifier, %s not valid") % repr(percent))
ValueError: format() must be given exactly one %char format specifier, '%.0f KB' not valid
@mission[~:1002]% python2.6 -c "import locale; print locale.format('%.0f KB', 100)"
100 KB

----------
messages: 120905
nosy: barry
priority: normal
severity: normal
status: open
title: locale.format() input regression
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10379>
_______________________________________

From report at bugs.python.org  Wed Nov 10 00:54:04 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Tue, 09 Nov 2010 23:54:04 +0000
Subject: [issue10378] Typo in results of help(divmod)
In-Reply-To: <1289336453.31.0.743925531352.issue10378@psf.upfronthosting.co.za>
Message-ID: <1289346844.12.0.932480546757.issue10378@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

__builtin__ is the correct name for the module (see http://docs.python.org/library/__builtin__.html, especially the note at the end which is the cause of the confusion), hence this is not a bug.

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10378>
_______________________________________

From report at bugs.python.org  Wed Nov 10 00:55:00 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Tue, 09 Nov 2010 23:55:00 +0000
Subject: [issue10351] Add autocompletion for keys in dictionaries
In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>
Message-ID: <1289346900.33.0.253759613798.issue10351@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/issue10351>
_______________________________________

From report at bugs.python.org  Wed Nov 10 00:55:58 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 09 Nov 2010 23:55:58 +0000
Subject: [issue10378] Typo in results of help(divmod)
In-Reply-To: <1289336453.31.0.743925531352.issue10378@psf.upfronthosting.co.za>
Message-ID: <1289346958.6.0.00890771514439.issue10378@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10378>
_______________________________________

From report at bugs.python.org  Wed Nov 10 00:56:07 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 09 Nov 2010 23:56:07 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289346967.65.0.862857105947.issue10379@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This was changed by issue2522 on purpose; no suffix is allowed in locale.format().

----------
nosy: +amaury.forgeotdarc, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10379>
_______________________________________

From report at bugs.python.org  Wed Nov 10 00:58:54 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 09 Nov 2010 23:58:54 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289347134.38.0.332414176414.issue10379@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Okay, so line 187 of locale.py has this test:

    if not match or len(match.group())!= len(percent):

the problematic part is the len test.  When format string is '%.0f KB' match.group() is '%.0f' but of course percent is the full string.

This seems like a bogus test, since clearly the given input is a valid format string.  I'm not sure what the intent of this test is.  The Python 2.6 test is:

    if percent[0] != '%':

which is perhaps too naive.

I guess I don't understand why this test is here.  Wouldn't it make more sense to either just let any TypeError from _format() to percolate up, or to catch that TypeError and transform it into the ValueError?  Why try to replicate the logic of str.__mod__()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10379>
_______________________________________

From report at bugs.python.org  Wed Nov 10 00:59:30 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 09 Nov 2010 23:59:30 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289347170.89.0.637982914048.issue10379@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/issue10379>
_______________________________________

From report at bugs.python.org  Wed Nov 10 01:01:57 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Nov 2010 00:01:57 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289347317.6.0.51615279945.issue10379@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hmm.  So I guess the answer is to use locale.format_string() instead.  But the documentation for locale.format() is not entirely clear about the prohibition on trailing text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10379>
_______________________________________

From report at bugs.python.org  Wed Nov 10 01:06:37 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Nov 2010 00:06:37 +0000
Subject: [issue2522] locale.format() problems with decimal separator
In-Reply-To: <1206983289.11.0.844443108334.issue2522@psf.upfronthosting.co.za>
Message-ID: <1289347597.02.0.0154113222849.issue2522@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hmm.  See bug 10379 for fallout from this change.  I'm not saying it should be reverted but see that issue for further discussion.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2522>
_______________________________________

From report at bugs.python.org  Wed Nov 10 01:06:55 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Nov 2010 00:06:55 +0000
Subject: [issue2522] locale.format() problems with decimal separator
In-Reply-To: <1206983289.11.0.844443108334.issue2522@psf.upfronthosting.co.za>
Message-ID: <1289347615.63.0.0962216232263.issue2522@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I mean issue 10379

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2522>
_______________________________________

From report at bugs.python.org  Wed Nov 10 01:08:02 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 10 Nov 2010 00:08:02 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289347682.23.0.70062365803.issue10379@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree the documentation isn't terribly clear on what a "%char specifier" or "whole format string" is.

FWIW, this is also a 3.1 and greater issue.

----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10379>
_______________________________________

From report at bugs.python.org  Wed Nov 10 01:08:19 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 10 Nov 2010 00:08:19 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289347699.5.0.278971738962.issue10379@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10379>
_______________________________________

From report at bugs.python.org  Wed Nov 10 07:29:25 2010
From: report at bugs.python.org (Peda Venkateswarlu Pola)
Date: Wed, 10 Nov 2010 06:29:25 +0000
Subject: [issue10380] AttributeError: 'module' object has no attribute
	'exc_traceback'
In-Reply-To: <1289370565.38.0.315034311665.issue10380@psf.upfronthosting.co.za>
Message-ID: <1289370565.38.0.315034311665.issue10380@psf.upfronthosting.co.za>


New submission from Peda Venkateswarlu Pola <pola.venki at gmail.com>:

As we have some new requirements in standard logging, We have written wrapper logger. This includes find caller which gives information about filename , line number , class name and method name. As i found that python logger doesn't give class name so we get the code from python logger and modified to our requirement. 

We end up with the following error intermittently from the function "currentframe()" .

"AttributeError: 'module' object has no attribute 'exc_traceback'"


def currentframe():
    """Return the frame object for the caller's stack frame."""
    try:
        raise Exception
    except:
        return sys.exc_traceback.tb_frame.f_back

Please help me out ASAP.

Great thanks in advance.

----------
components: None
files: findcaller_modi.py
messages: 120913
nosy: polavenki
priority: normal
severity: normal
status: open
title: AttributeError: 'module' object has no attribute 'exc_traceback'
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file19563/findcaller_modi.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10380>
_______________________________________

From report at bugs.python.org  Wed Nov 10 07:35:18 2010
From: report at bugs.python.org (Richard Fuhr)
Date: Wed, 10 Nov 2010 06:35:18 +0000
Subject: [issue10378] Typo in results of help(divmod)
In-Reply-To: <1289346844.12.0.932480546757.issue10378@psf.upfronthosting.co.za>
Message-ID: <584C9BFA-ED59-4B31-9AC1-FF1D2DC8494F@gmail.com>


Richard Fuhr <richard.fuhr at gmail.com> added the comment:

OK, thanks for the clarification. I am new to Python. 

Sent from my iPod

On Nov 9, 2010, at 3:54 PM, Andreas St?hrk <report at bugs.python.org> wrote:

> 
> Andreas St?hrk <andy-python at hammerhartes.de> added the comment:
> 
> __builtin__ is the correct name for the module (see http://docs.python.org/library/__builtin__.html, especially the note at the end which is the cause of the confusion), hence this is not a bug.
> 
> ----------
> nosy: +Trundle
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10378>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10378>
_______________________________________

From report at bugs.python.org  Wed Nov 10 08:24:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 10 Nov 2010 07:24:21 +0000
Subject: [issue10380] AttributeError: 'module' object has no attribute
	'exc_traceback'
In-Reply-To: <1289370565.38.0.315034311665.issue10380@psf.upfronthosting.co.za>
Message-ID: <1289373861.22.0.632327646704.issue10380@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

sys.exc_traceback is deprecated, please use sys.exc_info().  Also note that this tracker is not a place to get help; the python-list mailing list (a.k.a. comp.lang.python newsgroup) is the right place for that.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10380>
_______________________________________

From report at bugs.python.org  Wed Nov 10 08:58:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 10 Nov 2010 07:58:32 +0000
Subject: [issue10358] Doc styles for print should only use dark colors
In-Reply-To: <1289224086.88.0.0372722217541.issue10358@psf.upfronthosting.co.za>
Message-ID: <1289375912.54.0.081138180798.issue10358@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree and will add a print-media stylesheet.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10358>
_______________________________________

From report at bugs.python.org  Wed Nov 10 20:55:37 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 10 Nov 2010 19:55:37 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1289418937.29.0.496299213015.issue2986@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Thu Nov 11 09:02:39 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 11 Nov 2010 08:02:39 +0000
Subject: [issue9520] Add Patricia Trie high performance container
In-Reply-To: <1280969963.37.0.950740145402.issue9520@psf.upfronthosting.co.za>
Message-ID: <1289462559.98.0.375652901802.issue9520@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/issue9520>
_______________________________________

From report at bugs.python.org  Thu Nov 11 03:54:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 02:54:05 +0000
Subject: [issue10385] Mark up "subprocess" as module in its doc
In-Reply-To: <1289444045.02.0.247018067393.issue10385@psf.upfronthosting.co.za>
Message-ID: <1289444045.02.0.247018067393.issue10385@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I was going to commit this patch, but decided to ask for a second opinion.  I think module names in section titles should be marked up with :mod:.

----------
assignee: belopolsky
components: Documentation
files: subprocess-doc.diff
keywords: patch
messages: 120937
nosy: belopolsky
priority: normal
severity: normal
stage: commit review
status: open
title: Mark up "subprocess" as module in its doc
versions: Python 3.2
Added file: http://bugs.python.org/file19567/subprocess-doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10385>
_______________________________________

From report at bugs.python.org  Wed Nov 10 21:31:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Nov 2010 20:31:26 +0000
Subject: [issue10383] test_os leaks under Windows
In-Reply-To: <1289421086.3.0.902677944517.issue10383@psf.upfronthosting.co.za>
Message-ID: <1289421086.3.0.902677944517.issue10383@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Y:\>py3k\__svn__\PCbuild\python_d.exe -m test.regrtest -R 3:2 test_os
[1/1] test_os
[33558 refs]
beginning 5 repetitions
12345
[33558 refs]
.[33558 refs]
.[33558 refs]
.[33558 refs]
.[33558 refs]
.
test_os leaked [3, 3] references, sum=6
1 test failed:
    test_os
[117612 refs]

----------
components: Library (Lib), Windows
messages: 120931
nosy: amaury.forgeotdarc, brian.curtin, ocean-city, pitrou, rhettinger, tim.golden
priority: normal
severity: normal
status: open
title: test_os leaks under Windows
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10383>
_______________________________________

From report at bugs.python.org  Wed Nov 10 19:14:56 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 10 Nov 2010 18:14:56 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1289412896.4.0.227142458792.issue2986@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Tim told me to continue with this as he has no time.
rev86401 - apply 3.1 doc fix

----------
assignee: tim_one -> terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Thu Nov 11 01:05:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 00:05:58 +0000
Subject: [issue10382] Command line error marker misplaced on unicode entry
In-Reply-To: <1289417775.52.0.418272995538.issue10382@psf.upfronthosting.co.za>
Message-ID: <1289433958.33.0.737688451975.issue10382@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch that seems to fix the issue.  Note that I considered fixing the problem in parsetok.c where offset is originally computed, but this is part of pgen which has to be compiled without unicode support.

The test case suitable to be included in unittests is:

try:
    eval(b'\xc2\xa1'.decode('utf-8'))
except SyntaxError as err:
    assert(err.offset == 1)

----------
assignee:  -> belopolsky
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19565/issue10382.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10382>
_______________________________________

From report at bugs.python.org  Wed Nov 10 15:29:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Nov 2010 14:29:28 +0000
Subject: [issue10308] Modules/getpath.c bugs
In-Reply-To: <1288870063.75.0.834981100194.issue10308@psf.upfronthosting.co.za>
Message-ID: <1289399368.31.0.51116551548.issue10308@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r86399 fixes the code checking PyUnicode_AsWideChar() failure.

The following change is useless, it cannot overflow:

-    if (n + k > MAXPATHLEN)
+    if (k > MAXPATHLEN - n)
         k = MAXPATHLEN - n;

n and k maximum values are MAXPATHLEN (and the maximum value of MAXPATHLEN is 4096), whereas n and k type maximum values are at least 2^31.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10308>
_______________________________________

From report at bugs.python.org  Thu Nov 11 09:24:10 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 11 Nov 2010 08:24:10 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1289463850.48.0.807139206404.issue2986@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a new patch for 2.7 freshly generated vs. current 2.7 maintenance branch from SVN.

----------
Added file: http://bugs.python.org/file19569/issue2986.fix27.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Wed Nov 10 18:05:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 10 Nov 2010 17:05:07 +0000
Subject: [issue10205] Can't have two tags with the same QName
In-Reply-To: <1288122049.66.0.916624044666.issue10205@psf.upfronthosting.co.za>
Message-ID: <1289408707.73.0.571141041472.issue10205@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

3.1 was released before 2.7, so there are some features in 2.7 that aren?t in 3.1.  Tests are probably candidate for backport.

(BTW, I don?t understand the fix :)  I guess I fail at boolean logic tonight.)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10205>
_______________________________________

From report at bugs.python.org  Wed Nov 10 19:22:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 10 Nov 2010 18:22:48 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1289413368.59.0.0417033956655.issue2986@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Tim told me to continue with this as he has no time.
rev86401 - apply 3.1 doc fix

I cannot apply 2.7 patch. I has different header lines. In particular, TortoiseSVN cannot fetch nonexistent revision "Mon Aug 30 06:37:52 2010 +0300". Please regenerate against current 2.7 with method used for 2.6/3.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Wed Nov 10 17:34:04 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 10 Nov 2010 16:34:04 +0000
Subject: [issue10358] Doc styles for print should only use dark colors
In-Reply-To: <1289224086.88.0.0372722217541.issue10358@psf.upfronthosting.co.za>
Message-ID: <1289406844.44.0.538464663696.issue10358@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/issue10358>
_______________________________________

From report at bugs.python.org  Wed Nov 10 20:36:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 10 Nov 2010 19:36:15 +0000
Subject: [issue10382] Command line error marker misplaced on unicode entry
In-Reply-To: <1289417775.52.0.418272995538.issue10382@psf.upfronthosting.co.za>
Message-ID: <1289417775.52.0.418272995538.issue10382@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>>> ??????????
  File "<stdin>", line 1
    ??????????
                          ^
SyntaxError: invalid character in identifier


It looks like strlen() is used instead of number of characters in the decoded string.

----------
components: Interpreter Core
messages: 120930
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Command line error marker misplaced on unicode entry
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10382>
_______________________________________

From report at bugs.python.org  Thu Nov 11 01:17:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 00:17:27 +0000
Subject: [issue10382] Command line error marker misplaced on unicode entry
In-Reply-To: <1289417775.52.0.418272995538.issue10382@psf.upfronthosting.co.za>
Message-ID: <1289434647.49.0.579397410122.issue10382@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10382>
_______________________________________

From report at bugs.python.org  Wed Nov 10 21:14:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 10 Nov 2010 20:14:55 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1289420095.93.0.423389503838.issue7434@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/issue7434>
_______________________________________

From report at bugs.python.org  Thu Nov 11 01:23:01 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 11 Nov 2010 00:23:01 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1289434981.26.0.945870240359.issue10142@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


Removed file: http://bugs.python.org/file19356/z

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Thu Nov 11 02:37:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 01:37:09 +0000
Subject: [issue10384] SyntaxError should contain exact location of the invalid
	character in identifier
In-Reply-To: <1289439285.11.0.506002899946.issue10384@psf.upfronthosting.co.za>
Message-ID: <1289439429.76.0.854497369587.issue10384@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +Command line error marker misplaced on unicode entry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10384>
_______________________________________

From report at bugs.python.org  Wed Nov 10 14:55:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 10 Nov 2010 13:55:53 +0000
Subject: [issue10372] [REGRESSION] test_gc fails in non-debug mode.
In-Reply-To: <1289297149.99.0.674795586662.issue10372@psf.upfronthosting.co.za>
Message-ID: <1289397353.82.0.592698270679.issue10372@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Here is a patch. It moves warnings initialization after 
> io initialization (the latter being arguably more critical 
> than the former). Also adds two tests.

initstdio() and initmain() may emit warnings. Eg. issue #8766 (which now have a test in test_warnings).

It's possible to initialize warnings before initstdio() by rewriting more warnings functions in C (into _warnings). But I don't think that it would solve all issues: emit a warning may write text into stderr, and if stderr is not ready yet, it doesn't work anyway. So I'm ok to exchange initstdio() and warnings initialization: we may loose some warnings, but at least, the warnings machinery will be operational.

But Antoine, could you please add a comment to explain why warnings is initialized after initstdio()?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10372>
_______________________________________

From report at bugs.python.org  Wed Nov 10 21:57:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 10 Nov 2010 20:57:44 +0000
Subject: [issue10382] Command line error marker misplaced on unicode entry
In-Reply-To: <1289417775.52.0.418272995538.issue10382@psf.upfronthosting.co.za>
Message-ID: <1289422664.64.0.344626019117.issue10382@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/issue10382>
_______________________________________

From report at bugs.python.org  Thu Nov 11 01:30:18 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 11 Nov 2010 00:30:18 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1289435418.44.0.00157683785628.issue10142@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Please, review this. I had changed IO to support the new flags too. To do it, I must relax error control in IO, a bit.

So, the new flag are supported both in "os.lseek()" and in standard file objects.

Please, Antoine, could you review?.

I have checked the patch manually, but I can't think a way to automate it. We don't have any ZFS machine in buildbot.

I would love to commit this next week. Thanks for your time.

----------
assignee: loewis -> pitrou
keywords: +patch
Added file: http://bugs.python.org/file19566/z.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Wed Nov 10 18:10:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 10 Nov 2010 17:10:13 +0000
Subject: [issue10372] [REGRESSION] test_gc fails in non-debug mode.
In-Reply-To: <1289297149.99.0.674795586662.issue10372@psf.upfronthosting.co.za>
Message-ID: <1289409013.23.0.0917823849788.issue10372@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r86395 (3.x); I've only backported the tests to 2.7 and 3.1.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10372>
_______________________________________

From report at bugs.python.org  Thu Nov 11 09:50:36 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 11 Nov 2010 08:50:36 +0000
Subject: [issue10308] Modules/getpath.c bugs
In-Reply-To: <1289399368.31.0.51116551548.issue10308@psf.upfronthosting.co.za>
Message-ID: <hbf.20101111h223@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

STINNER Victor writes:
> The following change is useless, it cannot overflow:
> -    if (n + k > MAXPATHLEN)
> +    if (k > MAXPATHLEN - n)
>          k = MAXPATHLEN - n;
> 
> n and k maximum values are MAXPATHLEN (and the maximum value of
> MAXPATHLEN is 4096), (...)

OK.  I could only tell that for n, not for k.  But even so it would
certainly be an unlikely overflow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10308>
_______________________________________

From report at bugs.python.org  Wed Nov 10 16:16:21 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 10 Nov 2010 15:16:21 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1289402181.98.0.765765993302.issue1589@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Should we escalate this issue to CVA for Python 2.x?

----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Nov 10 19:20:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 10 Nov 2010 18:20:23 +0000
Subject: [issue7061] Improve turtle module documentation
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1289413223.13.0.236219045402.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Oct 31, 2010 at 8:00 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> ?Python? is lower-cased only when referring to the executable (as a 
> file) itself. ?When talking about the language, the implementation or
> the VM in an abstract way (not a file), It think it?s always ?Python?.

For the record, this is covered in the Python documentation style guide:

"""
Python

    The name of our favorite programming language is always capitalized.
"""

http://docs.python.org/dev/documenting/style.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Wed Nov 10 15:44:39 2010
From: report at bugs.python.org (Martin Dunschen)
Date: Wed, 10 Nov 2010 14:44:39 +0000
Subject: [issue10363] Embedded python, handle (memory) leak
In-Reply-To: <1289237931.86.0.626938349639.issue10363@psf.upfronthosting.co.za>
Message-ID: <1289400279.7.0.0359982947027.issue10363@psf.upfronthosting.co.za>


Martin Dunschen <mdunschen at gmail.com> added the comment:

I have identified 5 cases where objects of type PyThread_type_lock are allocated but never freed again:

import.c:
    import_lock

pystate.c:
    head_mutex

thread.c:
    key_mutex

ceval.c:
    interpreter_lock

zliblock.c:
    zlib_lock

This leads to a handle leak on windows (PyThread_type_lock) is mapped to PNRMUTEX, a structure that contains a HANDLE to an event, created by CreateEvent, but never released with CloseHandle. As I can see it, common to all thread implementations (in thread.c) is the PyThread_allocate_lock call for the above locks, but it is not matched by a PyThread_free_lock. I can imagine there are similar memory leaks in other thread implementations for different OS.

Additionally there is one directly created event in
timemodule.c
    hInterruptEvent

And finally in
myreadline.c:
    _PyOS_ReadmeLock

no matching PyThread_free_lock for the call to PyThread_allocate_lock.


All these memory or handle leaks could easily be fixed by using some C++ smart pointer implementations without requiring any changes to the API for embedding/extending python. On windows it requires some minor changes to allow compiling thread.c and timemodule.c as C++ code.

I am happy to post my version here, for other more knowledgeable python programmers to review them. I see my suggestions as a patch, but in an ideal world a lot of the code in pythoncore could be reimplemented using proper C++.

Martin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10363>
_______________________________________

From report at bugs.python.org  Thu Nov 11 05:08:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 04:08:44 +0000
Subject: [issue10386] token module should define __all__
In-Reply-To: <1289448524.33.0.684332419929.issue10386@psf.upfronthosting.co.za>
Message-ID: <1289448524.33.0.684332419929.issue10386@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The token module appears to be designed to be used with import *.  In fact it is used this way in the tokenize module.  However it does not define __all__ and as a result, from token import * leaks symbol "main":

>>> import tokenize
>>> tokenize.main.__module__
'token'

Attached patch adds token.__all__ and "modernizes" generation of the tok_name dictionary.

I also renamed main to _main because it is hard to imagine that any user code would ever want to use it.

----------
components: Library (Lib)
files: token-all.diff
keywords: patch
messages: 120938
nosy: belopolsky
priority: normal
severity: normal
stage: patch review
status: open
title: token module should define __all__
versions: Python 3.2
Added file: http://bugs.python.org/file19568/token-all.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10386>
_______________________________________

From report at bugs.python.org  Thu Nov 11 09:53:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 11 Nov 2010 08:53:44 +0000
Subject: [issue10382] Command line error marker misplaced on unicode entry
In-Reply-To: <1289417775.52.0.418272995538.issue10382@psf.upfronthosting.co.za>
Message-ID: <1289465624.79.0.757407544081.issue10382@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #2382: I wrote patches two years ago for this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10382>
_______________________________________

From report at bugs.python.org  Wed Nov 10 19:50:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 10 Nov 2010 18:50:57 +0000
Subject: [issue10381] Add timezone support to datetime C API
In-Reply-To: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>
Message-ID: <1289415057.12.0.111170767809.issue10381@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

With timezone class added to datetime module, C API should be extended to at the minimum support efficient creation of timezone instances and access to the singleton UTC instance.

I am not sure whether PyDateTime_TimeZone details should be exposed in datetime.h because presumably programmers should access it through the abstract tzinfo interface.

----------
assignee: belopolsky
components: Extension Modules
messages: 120928
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Add timezone support to datetime C API
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10381>
_______________________________________

From report at bugs.python.org  Thu Nov 11 01:41:05 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 11 Nov 2010 00:41:05 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1289436065.5.0.570833891551.issue10142@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

"""
>>> import os
>>> f=open("XX","w+b")
>>> f.seek(1024*1024)
1048576
>>> f.write(b"hello")
5
>>> f.seek(1024*1024*2)
2097152
>>> f.write(b"bye")
3
>>> f.seek(0,os.SEEK_HOLE)
0
>>> f.seek(0,os.SEEK_DATA)
1048576
>>> f.seek(1048576,os.SEEK_HOLE)
1179648
>>> f.seek(1179648,os.SEEK_DATA)
2097152
>>> f.seek(2097152,os.SEEK_HOLE)
2097155
>>> fd=f.fileno()
>>> os.lseek(fd,0,os.SEEK_HOLE)
0
>>> os.lseek(fd,0,os.SEEK_DATA)
1048576
>>> os.lseek(fd,1048576,os.SEEK_HOLE)
1179648
>>> os.lseek(fd,1179648,os.SEEK_DATA)
2097152
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Wed Nov 10 16:26:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 10 Nov 2010 15:26:48 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289402808.72.0.397703728938.issue10379@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yeah, obviously that language can be improved.  'exactly' was meant to imply 'nothing but', but clearly it doesn't.

If we want to restore more stringent backward compatibility and allow trailing text, it would be possible to make format an alias for format_string.  I'm not sure this is a good idea, but it is the most sensible way to restore backward compatibility while still fixing the original bug that I can think of.

Or...perhaps there is little need of both 'format' and 'format_string' as public APIs, and we could deprecate (without removing) one of them.

On the other hand, I believe the original bug affects the Ubuntu code that triggered this report...in other words, absent this fix chances are there would eventually have been a bug report against that code that would have necessitated that it change to use format_string anyway in order to get the correct locale-specific number formatting.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10379>
_______________________________________

From report at bugs.python.org  Wed Nov 10 22:18:59 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 10 Nov 2010 21:18:59 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1289423939.4.0.729298938627.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Attached is the remaining patch against py3k.  This installs the symlinks, fixes the distutils 'install_headers' location, and uses abiflags in the python3.pc path.

I think this branch is done, pending approval and commit.

----------
Added file: http://bugs.python.org/file19564/9807.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Nov 11 02:34:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 01:34:45 +0000
Subject: [issue10384] SyntaxError should contain exact location of the invalid
	character in identifier
In-Reply-To: <1289439285.11.0.506002899946.issue10384@psf.upfronthosting.co.za>
Message-ID: <1289439285.11.0.506002899946.issue10384@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Can you see the error in the following?

>>> inv?alid = 5
  File "<stdin>", line 1
    inv?alid = 5
             ^
SyntaxError: invalid character in identifier

The problem is that an invisible space character crept into the identifier:

>>> repr("inv?alid")
"'inv\\u200balid'"

With full unicode available in most OSes, the potential for errors like this (accidental or as a result of a practical joke) increases.  It would be much easier to spot the offending character if ^ marker pointed at the exact location rather than at the end of the identifier.


See also issue #10382.

----------
components: Interpreter Core
messages: 120936
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: SyntaxError should contain exact location of the invalid character in identifier
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10384>
_______________________________________

From report at bugs.python.org  Wed Nov 10 17:09:41 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 10 Nov 2010 16:09:41 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289405381.44.0.108076468519.issue10379@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Please use the deprecation process when possible. That would mean creating an alias for the function you want to remove somewhat like this (taken from configparser):

        def readfp(self, fp, filename=None):
            """Deprecated, use read_file instead."""
            warnings.warn(
                "This method will be removed in future versions.  "
                "Use 'parser.read_file()' instead.",
                PendingDeprecationWarning, stacklevel=2
            )
            self.read_file(fp, source=filename)

----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10379>
_______________________________________

From report at bugs.python.org  Wed Nov 10 19:55:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 10 Nov 2010 18:55:39 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1289415339.38.0.850585406405.issue7434@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/issue7434>
_______________________________________

From aaron.hosford at west.com  Wed Nov 10 21:51:19 2010
From: aaron.hosford at west.com (Hosford, Aaron Michael)
Date: Wed, 10 Nov 2010 14:51:19 -0600
Subject: Issue Tracker issues, and a bug in Python
Message-ID: <141880ED99B1B24FB9D83A42E485970C030B6A6435@oma00cexmbx05.corp.westworlds.com>

Hi all,

I found a bug in Python 2.7 involving dictionary comprehensions. I repeatedly tried to register on the Issue Tracker (http://bugs.python.org/) but never received a confirmation email, so I still can't log in and post it there. Maybe someone on this list can post it on my behalf:

>>> functions =  {x : lambda y: x + y for x in xrange(10)}
>>> functions[0](0)
9
>>>

The expression "functions[0](0)" should return 0, not 9. It looks like the scope for variable x is shared across the entire dictionary comprehension rather than having separate scope for each generated item.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20101110/3bd289e7/attachment.html>

From report at bugs.python.org  Wed Nov 10 20:54:59 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 10 Nov 2010 19:54:59 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1289418899.88.0.185137177646.issue2986@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
Removed message: http://bugs.python.org/msg120925

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Wed Nov 10 20:08:04 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 10 Nov 2010 19:08:04 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1289416084.06.0.292662358952.issue5412@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Committed in r86402.

Documentation changes pending, to be made after Fred's detailed review. Fred, you can review using trunk. Reassigned as a reminder.

----------
assignee: lukasz.langa -> fdrake
keywords: +needs review -patch
stage: unit test needed -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Thu Nov 11 12:13:21 2010
From: report at bugs.python.org (5houston)
Date: Thu, 11 Nov 2010 11:13:21 +0000
Subject: [issue8028] self.terminate() from a multiprocessing.Process raises
	AttributeError exception
In-Reply-To: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za>
Message-ID: <1289474001.64.0.74840836922.issue8028@psf.upfronthosting.co.za>


5houston <cadabras at gmail.com> added the comment:

If you will choose the former way, I think it would be better to write in the "multiprocessing.Process" documentation that sys.exit is the function to use to break the process execution inside itself, but maybe it would be better to wrap sys.exit with a new "multiprocessing.Process" method:
multiprocessing.Process.exit([arg]) for example.
Maybe it would be better to modify the sys.exit documentation too.
>From "Exit from Python" to "Exit from python process which it is called in".
Or, finally, you could modify "multiprocessing.Process.terminate" in this way (using pseudo-code):

self.terminate():
    if caller is self: sys.exit()
    else: -the current code-

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8028>
_______________________________________

From report at bugs.python.org  Thu Nov 11 13:06:24 2010
From: report at bugs.python.org (Felix Laurie von Massenbach)
Date: Thu, 11 Nov 2010 12:06:24 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>


New submission from Felix Laurie von Massenbach <fantasizer at gmail.com>:

If the config file has a boolean formatted as either True or False, python raises an attribute error when doing str.lower() on it. In my code I've worked around this in the following way:

class MyConfigParser(ConfigParser.RawConfigParser):
    def getboolean(self, section, option):
        result = self.get(section, option)
        try:
            trues = ["1", "yes", "true", "on"]
            falses = ["0", "no", "false", "off"]
            if result in trues:
                return True
            if result in falses:
                return False
        except AttributeError as err:
            if str(err) == "\'bool\' object has no attribute \'lower\'":
                return result
            raise err

Felix

(p.s. first bug report, sorry if it's a bit of a mess...)

----------
components: Extension Modules
messages: 120943
nosy: Felix.Laurie.von.Massenbach
priority: normal
severity: normal
status: open
title: ConfigParser's getboolean method is broken
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Thu Nov 11 13:11:58 2010
From: report at bugs.python.org (Felix Laurie von Massenbach)
Date: Thu, 11 Nov 2010 12:11:58 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289477518.97.0.775148363339.issue10387@psf.upfronthosting.co.za>


Felix Laurie von Massenbach <fantasizer at gmail.com> added the comment:

Oops, that was the broken first version. Let's try again:

class MyConfigParser(ConfigParser.RawConfigParser):
    def getboolean(self, section, option):
        result = self.get(section, option)
        try:
            trues = ["1", "yes", "true", "on"]
            falses = ["0", "no", "false", "off"]
            if result.lower() in trues:
                return True
            if result.lower() in falses:
                return False
        except AttributeError as err:
            if str(err) == "\'bool\' object has no attribute \'lower\'":
                return result
            raise err

Felix

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Thu Nov 11 13:31:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Nov 2010 12:31:31 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1289402181.98.0.765765993302.issue1589@psf.upfronthosting.co.za>
Message-ID: <1289478687.3549.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Should we escalate this issue to CVA for Python 2.x?

It's more of a missing feature than a security issue in itself, although
the missing feature has to do with security.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Thu Nov 11 13:52:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 11 Nov 2010 12:52:34 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289479954.34.0.32015526971.issue10387@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> lukasz.langa
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Thu Nov 11 13:52:40 2010
From: report at bugs.python.org (david)
Date: Thu, 11 Nov 2010 12:52:40 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1289478687.3549.1.camel@localhost.localdomain>
Message-ID: <AANLkTinhmyya_4-yNPzzwwf2Yk=R3_ytBj13EWGKi80o@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

On 11 November 2010 23:31, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> Should we escalate this issue to CVA for Python 2.x?
>
> It's more of a missing feature than a security issue in itself, although
> the missing feature has to do with security.

Still it would be nice to see in python 2.x at some point don't you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Thu Nov 11 14:10:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Nov 2010 13:10:26 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <AANLkTinhmyya_4-yNPzzwwf2Yk=R3_ytBj13EWGKi80o@mail.gmail.com>
Message-ID: <1289481021.3549.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> >
> > It's more of a missing feature than a security issue in itself, although
> > the missing feature has to do with security.
> 
> Still it would be nice to see in python 2.x at some point don't you think?

Well, lots of things would be nice to see in python 2.x, but that's not
how things work :)
That said, someone else is maintaining a backport (thank him):
http://pypi.python.org/pypi/backports.ssl_match_hostname/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Thu Nov 11 14:12:40 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 11 Nov 2010 13:12:40 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289481160.12.0.659539657626.issue10387@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Felix, thanks for your report! :)

I believe you misunderstood that all ConfigParser objects by design should hold *only strings* inside. The same problem would appear if you tried to write() configuration from a parser with booleans or numbers to a file. You should convert values to strings before putting them on the parser.

This is a design deficiency in RawConfigParser that it allows setting values to other types. If you would use SafeConfigParser you'd see that it doesn't let assigning anything other than strings as option values.

As much as we would love straightening it out (ensuring that values must be strings in RawConfigParsers), we can't do that because of backwards compatibility concerns.

As for holding strings internally, this is a design decision that may look strange at first but when you look at it from the consistency perspective, it's better:  when you load values from an INI file parser can't tell whether some specific value should be considered boolean or a string. "yes" is a valid string and a valid boolean value for the parser. Which one to hold internally? We don't know. So we store strings and let the user decide when he's using get(). The same should happen when you put values into a parser on your own.

I hope that explains it.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Thu Nov 11 14:47:32 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 11 Nov 2010 13:47:32 +0000
Subject: [issue10386] token module should define __all__
In-Reply-To: <1289448524.33.0.684332419929.issue10386@psf.upfronthosting.co.za>
Message-ID: <1289483252.53.0.265086285251.issue10386@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Normally, I'd recommend leaving the "main" name alone, but in the case of modules that use it as an tool for module maintenance (symbol, token), I don't think it matters either way.

Ok to commit.

----------
assignee:  -> belopolsky
nosy: +fdrake
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10386>
_______________________________________

From report at bugs.python.org  Thu Nov 11 15:03:12 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 11 Nov 2010 14:03:12 +0000
Subject: [issue10388] spwd returning different value depending on privileges
In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za>
Message-ID: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

As root:

>>> import spwd
>>> spwd.getspall()
[spwd.struct_spwd(sp_nam='root', sp_pwd='!', sp_lstchg=14895, sp_min=0, sp_max=99999, sp_warn=7, sp_inact=-1, sp_expire=-1, sp_flag=-1)
 ...
]

As limited user:

>>> import spwd
>>> spwd.getspall()
[]
>>> 

Wouldn't it be better for consistency to raise OSError EACCES instead?

----------
messages: 120950
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: spwd returning different value depending on privileges
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10388>
_______________________________________

From report at bugs.python.org  Thu Nov 11 15:08:25 2010
From: report at bugs.python.org (Felix Laurie von Massenbach)
Date: Thu, 11 Nov 2010 14:08:25 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289484505.2.0.961365575039.issue10387@psf.upfronthosting.co.za>


Felix Laurie von Massenbach <fantasizer at gmail.com> added the comment:

Perhaps I don't understand fully, but I am reading, for example, "option = True" from a config file. When doing this getboolean raises:

AttributeError: 'bool' object has no attribute 'lower'

Is it intended that you cannot store "True" and "False" as values in the config file?

Apologies if I'm being dense.

Felix

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Thu Nov 11 15:10:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 14:10:43 +0000
Subject: [issue10386] token module should define __all__
In-Reply-To: <1289448524.33.0.684332419929.issue10386@psf.upfronthosting.co.za>
Message-ID: <1289484643.21.0.611228236338.issue10386@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed revision 86410.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10386>
_______________________________________

From report at bugs.python.org  Thu Nov 11 15:11:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 14:11:27 +0000
Subject: [issue10386] token module should define __all__
In-Reply-To: <1289448524.33.0.684332419929.issue10386@psf.upfronthosting.co.za>
Message-ID: <1289484687.89.0.139916147182.issue10386@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10386>
_______________________________________

From report at bugs.python.org  Thu Nov 11 15:22:26 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 11 Nov 2010 14:22:26 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289485346.38.0.078755363134.issue10387@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

No problem Felix. But look:

Python 2.7 (r27:82500, Sep 24 2010, 12:26:28)
[GCC 4.3.4 20090804 (release) 1] on cygwin
Type "help", "copyright", "credits" or "license" for more information.
>>> config = """
... [section]
... does_it_work = True
... is_it_broken = False
... """
>>> from ConfigParser import RawConfigParser
>>> from StringIO import StringIO
>>> parser = RawConfigParser()
>>> sio = StringIO(config)
>>> parser.readfp(sio)
>>> parser.sections()
['section']
>>> parser.get('section', 'does_it_work')
'True'
>>> parser.get('section', 'is_it_broken')
'False'
>>> parser.getboolean('section', 'does_it_work')
True
>>> parser.getboolean('section', 'is_it_broken')
False

So, reading configuration options from files definitely works. And as you see in the first get() pair, it stores values internally as strings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Thu Nov 11 15:40:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 14:40:01 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1289486401.17.0.324217990295.issue5412@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In my experience of cfg files, it?s uncommon to have leading spaces (and also, may I add, ugly).  It?s great that configparser supports them now, but I wouldn?t have put them in the basic examples.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Thu Nov 11 15:58:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 14:58:32 +0000
Subject: [issue10388] spwd returning different value depending on privileges
In-Reply-To: <1289484192.53.0.424683719192.issue10388@psf.upfronthosting.co.za>
Message-ID: <1289487512.72.0.1717664058.issue10388@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10388>
_______________________________________

From report at bugs.python.org  Thu Nov 11 16:05:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 15:05:56 +0000
Subject: [issue10389] Document rules for use of case in section titles
In-Reply-To: <1289487956.63.0.138476981778.issue10389@psf.upfronthosting.co.za>
Message-ID: <1289487956.63.0.138476981778.issue10389@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Following a brief and consensual discussion on docs at python and #python-dev, I am proposing attached patch for the Python documentation style guide.

----------
assignee: belopolsky
components: Documentation
files: style-guide.diff
keywords: patch
messages: 120955
nosy: belopolsky
priority: normal
severity: normal
stage: patch review
status: open
title: Document rules for use of case in section titles
versions: Python 3.2
Added file: http://bugs.python.org/file19570/style-guide.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10389>
_______________________________________

From report at bugs.python.org  Thu Nov 11 16:15:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 15:15:16 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289488516.65.0.175096996472.issue10387@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/issue10387>
_______________________________________

From report at bugs.python.org  Thu Nov 11 16:15:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 15:15:29 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289488529.97.0.0606687010091.issue10387@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Library (Lib) -Extension Modules
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Thu Nov 11 16:19:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 15:19:50 +0000
Subject: [issue10385] Mark up "subprocess" as module in its doc
In-Reply-To: <1289444045.02.0.247018067393.issue10385@psf.upfronthosting.co.za>
Message-ID: <1289488790.04.0.0731248768133.issue10385@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Marking up each and every instance of a module name is not mandatory IMO.  What?s important is that each document title starts with the :mod: construct, so that the HTML titles and index (at /library) be consistently useful.  See for example ast (which also suffers from non-standard markup in its docstring, but that?s another issue).  In addition, there are hierarchy problems in the index.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10385>
_______________________________________

From report at bugs.python.org  Thu Nov 11 16:21:43 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 11 Nov 2010 15:21:43 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1289488903.39.0.164316507639.issue5412@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Yup, most config parsers don't support that so there are not so many INI type files in the wild with this kind of formatting. On the other hand, Samba, XULRunner, mke2fs and others all use this.

I mean, you're not forced to use that ugly feature but it's good to have it exposed so people don't later say they knew not that it was possible.

Of course, I'm open for suggestions on better examples :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Thu Nov 11 16:23:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 15:23:23 +0000
Subject: [issue10377] cProfile incorrectly labels its output
In-Reply-To: <1289330157.64.0.804847448743.issue10377@psf.upfronthosting.co.za>
Message-ID: <1289489003.42.0.24346351928.issue10377@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10377>
_______________________________________

From report at bugs.python.org  Thu Nov 11 16:24:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 15:24:39 +0000
Subject: [issue10375] 2to3 print(single argument)
In-Reply-To: <1289311942.35.0.609245522343.issue10375@psf.upfronthosting.co.za>
Message-ID: <1289489079.55.0.547831774096.issue10375@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +benjamin.peterson, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10375>
_______________________________________

From report at bugs.python.org  Thu Nov 11 16:32:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 15:32:10 +0000
Subject: [issue10389] Document rules for use of case in section titles
In-Reply-To: <1289487956.63.0.138476981778.issue10389@psf.upfronthosting.co.za>
Message-ID: <1289489530.43.0.686056074351.issue10389@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 about the patch, if you add an example: ?sentence case? may not be obvious for everyone.  If it?s ?modulename ? Module description?, I agree.

Also, s/white space/whitespace/.

----------
nosy: +docs at python, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10389>
_______________________________________

From report at bugs.python.org  Thu Nov 11 16:55:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 11 Nov 2010 15:55:16 +0000
Subject: [issue8804] http.client should support SSL contexts
In-Reply-To: <1274716924.32.0.357648768076.issue8804@psf.upfronthosting.co.za>
Message-ID: <1289490916.08.0.907381149513.issue8804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed as part of #9003.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> urllib.request and http.client should allow certificate checking

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8804>
_______________________________________

From report at bugs.python.org  Thu Nov 11 17:50:05 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Thu, 11 Nov 2010 16:50:05 +0000
Subject: [issue10390] json.load should handle bytes input
In-Reply-To: <1289494205.74.0.417330108965.issue10390@psf.upfronthosting.co.za>
Message-ID: <1289494205.74.0.417330108965.issue10390@psf.upfronthosting.co.za>


New submission from Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com>:

The following code produces an error:

# APIKEY defined above
r = urllib.request.urlopen('http://api.billboard.com/apisvc/chart/v1/'
                           'list/spec?api_key={}&format=JSON'
                           .format(APIKEY))
j = json.load(r)

Specifically, the urlopen() function returns a request object that can be read, the request object returns a bytes object containing JSON, and the json.load() function tries to mix str and bytes objects when using the re module.

json.load() should convert bytes to str. It is reasonable that one should be able to open a url and pass the result directly to json.load().

----------
components: Library (Lib)
messages: 120960
nosy: jfinkels
priority: normal
severity: normal
status: open
title: json.load should handle bytes input
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10390>
_______________________________________

From report at bugs.python.org  Thu Nov 11 17:53:23 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Thu, 11 Nov 2010 16:53:23 +0000
Subject: [issue10390] json.load should handle bytes input
In-Reply-To: <1289494205.74.0.417330108965.issue10390@psf.upfronthosting.co.za>
Message-ID: <1289494403.56.0.871246535814.issue10390@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

Nevermind.

----------
resolution:  -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10390>
_______________________________________

From report at bugs.python.org  Thu Nov 11 17:57:21 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 11 Nov 2010 16:57:21 +0000
Subject: [issue10383] test_os leaks under Windows
In-Reply-To: <1289421086.3.0.902677944517.issue10383@psf.upfronthosting.co.za>
Message-ID: <1289494641.12.0.0413748349165.issue10383@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This leaks one reference every time:
    os.write(123456, b"b")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10383>
_______________________________________

From report at bugs.python.org  Thu Nov 11 18:01:31 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 11 Nov 2010 17:01:31 +0000
Subject: [issue10383] test_os leaks under Windows
In-Reply-To: <1289421086.3.0.902677944517.issue10383@psf.upfronthosting.co.za>
Message-ID: <1289494891.59.0.0860882319692.issue10383@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This looks suspect (in function posix_write)::

    if (!PyArg_ParseTuple(args, "iy*:write", &fd, &pbuf))
        return NULL;
    if (!_PyVerify_fd(fd))
        return posix_error();

I'd prefer a "PyBuffer_Release(&pbuf);" before returning...
Many other occurrences of _PyVerify_fd have this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10383>
_______________________________________

From report at bugs.python.org  Thu Nov 11 18:45:20 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 11 Nov 2010 17:45:20 +0000
Subject: [issue9520] Add Patricia Trie high performance container
In-Reply-To: <1280969963.37.0.950740145402.issue9520@psf.upfronthosting.co.za>
Message-ID: <1289497520.69.0.684174599571.issue9520@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9520>
_______________________________________

From report at bugs.python.org  Thu Nov 11 19:03:22 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 11 Nov 2010 18:03:22 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1289498602.61.0.95373854824.issue10142@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

- The patch modifies the _io module but not _pyio, why?
(try   f=_pyio.open("XX","w+b")   at the beginning of the script above)

- One test was *removed*, but nothing was added to test this new feature.
This is the most likely way to lose it in future versions!
An idea for the test is to do like the MockRawIO class in test_io.py, which "implements" a file but fakes all system calls, and can be wrapped in a BufferedReader.

- The feature seems to be not applicable to text files, this should be tested.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Thu Nov 11 20:40:16 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Nov 2010 19:40:16 +0000
Subject: [issue10390] json.load should handle bytes input
In-Reply-To: <1289494205.74.0.417330108965.issue10390@psf.upfronthosting.co.za>
Message-ID: <1289504416.48.0.973989419657.issue10390@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10390>
_______________________________________

From report at bugs.python.org  Thu Nov 11 20:40:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 19:40:44 +0000
Subject: [issue10389] Document rules for use of case in section titles
In-Reply-To: <1289487956.63.0.138476981778.issue10389@psf.upfronthosting.co.za>
Message-ID: <1289504444.19.0.770961014835.issue10389@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The new patch, issue10389.diff, addresses ?ric's comments and adds an entry for "reST".

----------
Added file: http://bugs.python.org/file19571/issue10389.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10389>
_______________________________________

From report at bugs.python.org  Thu Nov 11 21:12:55 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Nov 2010 20:12:55 +0000
Subject: [issue1466065] base64 module ignores non-alphabet characters
Message-ID: <1289506375.8.0.282347490104.issue1466065@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r86414.

----------
nosy:  -BreamoreBoy
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1466065>
_______________________________________

From report at bugs.python.org  Thu Nov 11 21:53:43 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 11 Nov 2010 20:53:43 +0000
Subject: [issue10391] obj2ast's error handling can lead to python crashing
	with a C-level assertion failure
In-Reply-To: <1289508823.86.0.760663346752.issue10391@psf.upfronthosting.co.za>
Message-ID: <1289508823.86.0.760663346752.issue10391@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

In various places within the generated Python/Python-ast.c, error handling generates a repr() and raises exceptions accordingly.

Currently in py3k the generated code uses PyBytes_AS_STRING() on the repr.  My understanding is that repr() should be a PyUnicodeObject, not a PyBytesObject.  This seems to be unchanged from r63682, which was a mass-change of PyString to PyBytes from 2 years ago.

This leads to a python crashing with an assertion failure:
test_compile_ast (__main__.TestSpecifics) ... python: Python/Python-ast.c:5835: obj2ast_expr: Assertion `((((((PyObject*)(tmp))->ob_type))->tp_flags & ((1L<<27))) != 0)' failed.

when invoking compile() on certain (malformed) trees of ast objects.

----------
components: Interpreter Core
messages: 120967
nosy: dmalcolm
priority: normal
severity: normal
status: open
title: obj2ast's error handling can lead to python crashing with a C-level assertion failure
type: crash
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10391>
_______________________________________

From report at bugs.python.org  Thu Nov 11 21:56:15 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 11 Nov 2010 20:56:15 +0000
Subject: [issue10391] obj2ast's error handling can lead to python crashing
	with a C-level assertion failure
In-Reply-To: <1289508823.86.0.760663346752.issue10391@psf.upfronthosting.co.za>
Message-ID: <1289508975.06.0.131207802246.issue10391@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

The attached patch:
  - extends the ast error-handling selftest with code that triggers this crash (on unpatched code)
  - fixes Parser/asdl_c.py to generate code using _PyUnicode_AS_STRING instead
  - contains the generated changes to Python/Python-ast.c

FWIW, it's not clear to what extent _PyUnicode_AS_STRING is deprecated, Include/unicodeobject.h currently has:
   *** This API is for interpreter INTERNAL USE ONLY and will likely
   *** be removed or changed for Python 3.1.
but I hope it won't be, it's far too useful.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file19572/py3k-issue-10391-fix-ast-error-handling.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10391>
_______________________________________

From report at bugs.python.org  Thu Nov 11 21:57:28 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 11 Nov 2010 20:57:28 +0000
Subject: [issue10391] obj2ast's error handling can lead to python crashing
	with a C-level assertion failure
In-Reply-To: <1289508823.86.0.760663346752.issue10391@psf.upfronthosting.co.za>
Message-ID: <1289509048.7.0.0433785946442.issue10391@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +benjamin.peterson, brett.cannon, georg.brandl, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10391>
_______________________________________

From report at bugs.python.org  Thu Nov 11 22:00:51 2010
From: report at bugs.python.org (Alex Willmer)
Date: Thu, 11 Nov 2010 21:00:51 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1289010171.3.0.24257538874.issue2636@psf.upfronthosting.co.za>
Message-ID: <AANLkTimmNUCzvbFYjmz_NhB5FZ8Ni89+O16aGwn+AYrq@mail.gmail.com>


Alex Willmer <alex at moreati.org.uk> added the comment:

The re module throws an exception for re.compile(r'[\A\w]'). latest
regex doesn't, but I don't think the pattern is matching correctly.
Shouldn't findall(r'[\A]\w', 'a b c') return ['a'] and
findall(r'[\A\s]\w', 'a b c') return ['a', ' b', ' c'] ?

Python 2.6.6 (r266:84292, Sep 15 2010, 16:22:56)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> for s in [r'\A\w', r'[\A]\w', r'[\A\s]\w']: print re.findall(s, 'a b c')
...
['a']
[]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.6/re.py", line 177, in findall
    return _compile(pattern, flags).findall(string)
  File "/usr/lib/python2.6/re.py", line 245, in _compile
    raise error, v # invalid expression
sre_constants.error: internal: unsupported set operator
>>> import regex
>>> for s in [r'\A\w', r'[\A]\w', r'[\A\s]\w']: print regex.findall(s, 'a b c')
...
['a']
[]
[' b', ' c']

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Nov 11 22:17:46 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Thu, 11 Nov 2010 21:17:46 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289510266.56.0.641456089077.issue7900@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

This test is failing again, and IIUC, largely due to the same sort of issues: http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.1/builds/65

I was able to track down what exactly caused it to fail in this case on my box, though. Whatever "posix.getgroups()" ends up calling, appears to be tied to the current users login -- or at least, doesn't get updated when new groups are added to the user.

This failure happened because at some point after the buildbot was up and running, I added a new user to the machine (totally unconnected to the existing buildbot runner): this caused a new group to be added to the buildbot runner's user.

"id -G" starts returning that group immediately, but "posix.getgroups()" returns the same list as it had before. I was able to further reproduce it in Terminal, by having a console open, and compiling 3.1 there then adding a user, and running the test. It fails. Opening up a new terminal window, running the test-- and it succeeds. The original console continues to fail.

----------
nosy: +ixokai
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Thu Nov 11 22:22:46 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 11 Nov 2010 21:22:46 +0000
Subject: [issue10391] obj2ast's error handling can lead to python crashing
	with a C-level assertion failure
In-Reply-To: <1289508823.86.0.760663346752.issue10391@psf.upfronthosting.co.za>
Message-ID: <1289510566.54.0.389761541449.issue10391@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

IMO a better patch would be to use the %R format specification:
  PyErr_Format(
      PyExc_TypeError, "expected some sort of mod, but got %R", obj);
And no need to use PyObject_Repr and the temporary variable!

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10391>
_______________________________________

From report at bugs.python.org  Thu Nov 11 22:24:20 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Thu, 11 Nov 2010 21:24:20 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289510660.06.0.517930316112.issue7900@psf.upfronthosting.co.za>


Changes by Stephen Hansen <me+python at ixokai.io>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Thu Nov 11 22:36:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 21:36:15 +0000
Subject: [issue10389] Document rules for use of case in section titles
In-Reply-To: <1289487956.63.0.138476981778.issue10389@psf.upfronthosting.co.za>
Message-ID: <1289511375.82.0.658148166264.issue10389@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.  I wouldn?t say reST is WYSIWYG, since it?s transformed, contrary to word processors where you make text bold to get it bold.

(If you?re looking for other things to fix in that file, look at the entry for Unicode ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10389>
_______________________________________

From report at bugs.python.org  Thu Nov 11 22:39:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 21:39:15 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1289511555.67.0.398605022731.issue5412@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Well, I suggest removing the leading spaces in the examples, except maybe in one place if you think it?s needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Thu Nov 11 23:03:37 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 11 Nov 2010 22:03:37 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1289510266.56.0.641456089077.issue7900@psf.upfronthosting.co.za>
Message-ID: <6DBF6F2C-3C00-4122-93E8-DE52D2FFD71A@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This is the expected behavior on OSX. Apple has a pretty odd interpretation of the standards wrt getgroups and setgroups behavior. 

This behavior is not a bug in python

Sent from my iPhone

On 11 nov. 2010, at 22:17, Stephen Hansen <report at bugs.python.org> wrote:

> 
> Stephen Hansen <me+python at ixokai.io> added the comment:
> 
> This test is failing again, and IIUC, largely due to the same sort of issues: http://www.python.org/dev/buildbot/all/builders/AMD64%20Leopard%203.1/builds/65
> 
> I was able to track down what exactly caused it to fail in this case on my box, though. Whatever "posix.getgroups()" ends up calling, appears to be tied to the current users login -- or at least, doesn't get updated when new groups are added to the user.
> 
> This failure happened because at some point after the buildbot was up and running, I added a new user to the machine (totally unconnected to the existing buildbot runner): this caused a new group to be added to the buildbot runner's user.
> 
> "id -G" starts returning that group immediately, but "posix.getgroups()" returns the same list as it had before. I was able to further reproduce it in Terminal, by having a console open, and compiling 3.1 there then adding a user, and running the test. It fails. Opening up a new terminal window, running the test-- and it succeeds. The original console continues to fail.
> 
> ----------
> nosy: +ixokai
> versions: +Python 3.1, Python 3.2
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7900>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Thu Nov 11 23:09:10 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Thu, 11 Nov 2010 22:09:10 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289513350.7.0.390784384287.issue7900@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

Well, yes: the result of posix.getgroups is not a bug in Python, but is it a bug in the test? Should it be skipped on OSX, or some other solution?

Having buildbots fail because of something that's expected behavior is bad, isn't it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Thu Nov 11 23:20:15 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Thu, 11 Nov 2010 22:20:15 +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: <1289514015.98.0.45902801935.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Maybe I am missing something, but the result in regex seem ok to me:
\A is treated like A in a character set; when the test string is changed to "A b c" or in the case insensitive search the A is matched.

[\A\s]\w doesn't match the starting "a", as it is not followed by any word character:

>>> for s in [r'\A\w', r'[\A]\w', r'[\A\s]\w']: print regex.findall(s, 'A b c')
... 
['A']
[]
[' b', ' c']
>>> for s in [r'\A\w', r'(?i)[\A]\w', r'[\A\s]\w']: print regex.findall(s, 'a b c')
... 
['a']
[]
[' b', ' c']
>>> 

In the original re there seem to be a bug/limitation in this regard (\A and also \Z in character sets aren't supported in some combinations...

vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Nov 11 23:39:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Nov 2010 22:39:20 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289515160.63.0.195760456454.issue7900@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Right, regardless of whether or not it is a bug in python, IMO it *is* a bug in the python test suite, since we *expect* buildbots to be long running processes and therefore they are going to get hit by this failure on OSX periodically with a pretty high likelyhood.  Yes it is easily fixable (restart the builder), but it seems to me the test should be fixed somehow instead of putting that burden on the buildbot owner.

A skip on OSX would certainly be the simplest solution, and we could thereby indicate that we consider this behavior to be a bug in OSX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Thu Nov 11 23:39:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Nov 2010 22:39:36 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289515176.79.0.21154633763.issue7900@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
priority: high -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Thu Nov 11 23:42:52 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 11 Nov 2010 22:42:52 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289515372.58.0.806307086146.issue10379@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

The bug has been fixed upstream by replacing .format() with .format_string().  I'm not sure I understand why there are two different methods - .format() seems kind of pointless to me, but then I don't use the locale module enough to say what's useful.

For Python 2.7 I think the only thing we can do is to update the docs so that the distinction and restrictions are clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10379>
_______________________________________

From report at bugs.python.org  Thu Nov 11 23:44:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 22:44:19 +0000
Subject: [issue10389] Document rules for use of case in section titles
In-Reply-To: <1289487956.63.0.138476981778.issue10389@psf.upfronthosting.co.za>
Message-ID: <1289515459.77.0.58810681291.issue10389@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 86417.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10389>
_______________________________________

From report at bugs.python.org  Thu Nov 11 23:58:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 22:58:37 +0000
Subject: [issue7950] subprocess.Popen documentation should contain a good
	warning about the security implications when using shell=True
In-Reply-To: <1266401759.12.0.600282213979.issue7950@psf.upfronthosting.co.za>
Message-ID: <1289516317.34.0.280355031956.issue7950@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good to me, except the last two lines which I would reword or just remove.

I wonder how many people use shell=True merely for the convenience of passing a string instead of a list.  What do you think about adding a mention of str.split and shlex.split?

----------
nosy: +eric.araujo
type: security -> behavior
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7950>
_______________________________________

From report at bugs.python.org  Fri Nov 12 00:03:20 2010
From: report at bugs.python.org (Chris Rebert)
Date: Thu, 11 Nov 2010 23:03:20 +0000
Subject: [issue7950] subprocess.Popen documentation should contain a good
	warning about the security implications when using shell=True
In-Reply-To: <1266401759.12.0.600282213979.issue7950@psf.upfronthosting.co.za>
Message-ID: <1289516600.22.0.848265420585.issue7950@psf.upfronthosting.co.za>


Chris Rebert <pybugs at rebertia.com> added the comment:

"the above Note" mentioned in those last two lines demonstrates shlex.split() and correct tokenization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7950>
_______________________________________

From report at bugs.python.org  Fri Nov 12 00:05:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 23:05:54 +0000
Subject: [issue10382] Command line error marker misplaced on unicode entry
In-Reply-To: <1289417775.52.0.418272995538.issue10382@psf.upfronthosting.co.za>
Message-ID: <1289516754.09.0.284658362081.issue10382@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

haypo> See also #2382: I wrote patches two years ago for this issue.

Yes, this is the same issue.  I don't want to close this as a duplicate because #2382 contains a much more ambitious set of patches.  What I am trying to achieve here is similar to the adjust_offset.patch there.

I am attaching a patch that takes an alternative approach and computes the number of characters in the parser.  I strongly believe that the buffer in the tokenizer always contains UTF-8 encoded text.  If it is not so already, I would consider making it so by replacing a call to _PyUnicode_AsDefaultEncodedString() with a call to PyUnicode_AsUTF8String(). (if that matters)

The patch still needs unittests and possibly has some off-by-one issues, but I would like to get to an agreement that this is the right level at which the problem should be fixed first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10382>
_______________________________________

From report at bugs.python.org  Fri Nov 12 00:06:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 11 Nov 2010 23:06:14 +0000
Subject: [issue10382] Command line error marker misplaced on unicode entry
In-Reply-To: <1289417775.52.0.418272995538.issue10382@psf.upfronthosting.co.za>
Message-ID: <1289516774.99.0.231995894993.issue10382@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file19573/issue10382a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10382>
_______________________________________

From report at bugs.python.org  Fri Nov 12 00:11:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 11 Nov 2010 23:11:47 +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: <1289517107.57.0.438589237466.issue9286@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Having no time to read email RFCs, I?ll defer to you here.  Please reject this report or save it for later as you prefer.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9286>
_______________________________________

From report at bugs.python.org  Fri Nov 12 00:13:59 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 11 Nov 2010 23:13: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: <1289517239.69.0.525762867929.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

It looks like a similar problem to msg116252 and msg116276.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Nov 12 00:24:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 11 Nov 2010 23:24:59 +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: <1289517899.01.0.247297168348.issue9286@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In connection with another bug report I found a rather basic error in parseaddr, so I'm going to eventually dig far enough into the RFC to have a real opinion on the elided-space issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9286>
_______________________________________

From report at bugs.python.org  Fri Nov 12 00:48:58 2010
From: report at bugs.python.org (Alex Willmer)
Date: Thu, 11 Nov 2010 23:48:58 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1289514015.98.0.45902801935.issue2636@psf.upfronthosting.co.za>
Message-ID: <AANLkTikBQ=wZsbf4GFCHSU+hd+WB6XUWUg8OSk_wnGFG@mail.gmail.com>


Alex Willmer <alex at moreati.org.uk> added the comment:

On Thu, Nov 11, 2010 at 10:20 PM, Vlastimil Brom <report at bugs.python.org> wrote:
> Maybe I am missing something, but the result in regex seem ok to me:
> \A is treated like A in a character set;

I think it's me who missed something. I'd assumed that all backslash
patterns (including \A for beginning of string) maintain their meaning
in a character class. AFAICT that assumption was wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:03:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 00:03:01 +0000
Subject: [issue3931] codecs.charmap_build is untested and undocumented
In-Reply-To: <1222085190.52.0.690275455212.issue3931@psf.upfronthosting.co.za>
Message-ID: <1289520181.14.0.632408994295.issue3931@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I see charmap_build used in encodings too, so it may be useful to make it officially public for the use of third-party encodings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3931>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:11:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 00:11:06 +0000
Subject: [issue7219] Unhelpful error message when a distutils package install
	fails due to a permissions error
In-Reply-To: <1256647071.1.0.815334810123.issue7219@psf.upfronthosting.co.za>
Message-ID: <1289520666.95.0.624080725997.issue7219@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I wonder if this is IronPython-specific.  Could you temporarily make the site-packages directory of a py3k CPython read-only and try to install a distribution with that CPython?  I can try the same thing on unix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7219>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:15:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Nov 2010 00:15:26 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289345606.99.0.972407204822.issue10379@psf.upfronthosting.co.za>
Message-ID: <1289520926.49.0.88713925474.issue10379@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, the distinction is that, before the bug fix that caused your issue, the 'format_string' method would use a regex to extract the % specifiers from the input string, and call 'format' to replace that % specifier with a properly localized result string.  That is, 'format' was designed to handle a single % specifier with no extra text, basically as a helper method for format_string.  The fact that it didn't reject extra text was, according to an internal comment, a defect of the implementation.  (Passing any extra text would cause the implementation to fail to do the internationalization that was the entire reason for calling it.)

When I fixed the bug I extracted the 'replace a single % specifier' code into an internal method, and made the format method live up to what I perceived to be its documented interface by rejecting extra input characters so that it could safely call the new internal substitution routine.

Now, from the perspective of a *user* of the locale module, I fail to see the point in having both 'format' and 'format_string' exposed.  If you want to format a single % specifier, just pass it to format_string.  Thus my suggestion to make them both do the same thing (to cater to other code that may be calling format incorrectly) and then deprecate one of them (presumably format).  

To bad I didn't think of that when I fixed the original bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10379>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:15:33 2010
From: report at bugs.python.org (Felix Laurie von Massenbach)
Date: Fri, 12 Nov 2010 00:15:33 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289520933.69.0.415283878009.issue10387@psf.upfronthosting.co.za>


Felix Laurie von Massenbach <fantasizer at gmail.com> added the comment:

Ok, so I understand the issue, but why doesn't the set method simply convert to a string?

>>> from ConfigParser import RawConfigParser
>>> from StringIO import StringIO
>>> parser = RawConfigParser()
>>> config = """
[section]
test = True
"""
>>> parser.readfp(StringIO(config))
>>> parser.get("section", "test")
'True'
>>> parser.getboolean("section", "test")
True
>>> parser.set("section", "test", True)
>>> parser.get("section", "test")
True
>>> parser.getboolean("section", "test")

Traceback (most recent call last):
  File "<pyshell#33>", line 1, in <module>
    parser.getboolean("section", "test")
  File "C:\Python27\lib\ConfigParser.py", line 361, in getboolean
    if v.lower() not in self._boolean_states:
AttributeError: 'bool' object has no attribute 'lower'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:18:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 00:18:23 +0000
Subject: [issue9313] distutils error on MSVC older than 8
In-Reply-To: <1279624042.03.0.724891043691.issue9313@psf.upfronthosting.co.za>
Message-ID: <1289521103.62.0.387287900947.issue9313@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Re-opening to remind myself about the forward-port.

----------
assignee: ocean-city -> eric.araujo
components:  -Tests
status: closed -> open
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9313>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:22:44 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 00:22:44 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1289521364.99.0.0571288946678.issue2986@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

issue2986.fix27.5.patch applied, with version note added to doc, as
rev86418

Only thing left is patch for 3.2, which Eli and I will produce.

----------
stage: commit review -> needs patch
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:24:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 00:24:44 +0000
Subject: [issue8989] email.utils.make_msgid: specify domain
In-Reply-To: <1276442137.97.0.787561293748.issue8989@psf.upfronthosting.co.za>
Message-ID: <1289521484.67.0.14428798733.issue8989@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch, which looks good to me, except for the test: ?eq? will raise a NameError, since this does not exist.  Other test methods bind eq to self.assertEqual to save typing, which is not really needed in your case: Just use self.assertEqual :)

To run the tests, ./python -m email.test.test_email

----------
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8989>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:25:37 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 12 Nov 2010 00:25:37 +0000
Subject: [issue10379] locale.format() input regression
In-Reply-To: <1289520926.49.0.88713925474.issue10379@psf.upfronthosting.co.za>
Message-ID: <20101111192526.39c3ff9a@mission>


Barry A. Warsaw <barry at python.org> added the comment:

On Nov 12, 2010, at 12:15 AM, R. David Murray wrote:

>Now, from the perspective of a *user* of the locale module, I fail to see the
>point in having both 'format' and 'format_string' exposed.  If you want to
>format a single % specifier, just pass it to format_string.  Thus my
>suggestion to make them both do the same thing (to cater to other code that
>may be calling format incorrectly) and then deprecate one of them (presumably
>format).

+1

>To bad I didn't think of that when I fixed the original bug.

Dang.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10379>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:35:49 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 12 Nov 2010 00:35:49 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289522149.13.0.856042245941.issue10387@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

This is unfortunately a backwards compatibility concern. Originally it wasn't made so that set() converts to string or accepts only strings and when the developers realized this mistake, it was too late (there were programs using this misfeature). That's one of the reasons SafeConfigParser was created (hence the name).

As I said in my original answer, SafeConfigParser doesn't let you set() anything but a string and this is how it should have been from the start. But we won't break backwards compatibility now, it's far too late for that I'm afraid.

Storing non-string data was misused by some programs by using set() and get() (not getboolean() or getint() etc. but bare get()).

I'm closing this as Won't Fix. Thanks for your input, it's very much appreciated.

----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:36:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Nov 2010 00:36:45 +0000
Subject: [issue7950] subprocess.Popen documentation should contain a good
	warning about the security implications when using shell=True
In-Reply-To: <1266401759.12.0.600282213979.issue7950@psf.upfronthosting.co.za>
Message-ID: <1289522205.17.0.433931803126.issue7950@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed (as a warning) in r86419.  Thanks, Chris.

----------
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7950>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:39:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 00:39:53 +0000
Subject: [issue644744] bdist_rpm fails when installing man pages
Message-ID: <1289522393.1.0.39335010322.issue644744@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thomas, sorry if my message was short and unclear.  The freeze policy means that distutils does not get new features, only bug fixes.  The goal is to free time so that the developers (especially Tarek) can work on distutils2, the next generation.  When I said that ?changing even internal details breaks third-party tools?, I was talking about tools written in Python that use distutils as a library; they rely on implementation details, internal functions and old bugs, which means distutils can?t get the changes we need to significantly improve the state of Python packaging.  That?s why Tarek has started distutils2, where compatibility can be broken to fix design mistakes and add disruptive new features.

Like I said, we?ve removed bdist_rpm in distutils2; it now lives as an external project: https://pypi.python.org/pypi/pypi2rpm/0.3 .  When distutils2 is merged back into the standard library, bdist_rpm2 can have shorter release cycles to comply with policy changes on rpm-based systems.

In this case, the freeze does not apply: This bug should be fixed in distutils.  Can you update your patch to address Toshio?s remarks?  Thanks.

----------
assignee: tarek -> eric.araujo
nosy:  -BreamoreBoy
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue644744>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:41:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 00:41:48 +0000
Subject: [issue9006] xml-rpc Server object does not propagate the encoding to
	Unmarshaller
In-Reply-To: <1276680036.39.0.0895862907842.issue9006@psf.upfronthosting.co.za>
Message-ID: <1289522508.79.0.222262217519.issue9006@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Could you reupload your fix as a diff instead of a whole file?  See http://www.python.org/dev/patches/ for some help.

----------
nosy: +loewis
type: crash -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9006>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:46:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 00:46:31 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1289522791.61.0.921896270383.issue3243@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The patch needs to be ported to the py3k branch.

----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:51:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 00:51:11 +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: <1289523071.77.0.521620040613.issue9322@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
components: +Distutils2
stage:  -> needs patch
title: bdist_rpm ext_modules absolute source path fail -> Don?t fail silently if ext_modules use absolute paths
versions: +3rd party, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9322>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:53:24 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 12 Nov 2010 00:53:24 +0000
Subject: [issue9520] Add Patricia Trie high performance container
In-Reply-To: <1280969963.37.0.950740145402.issue9520@psf.upfronthosting.co.za>
Message-ID: <1289523204.92.0.489058547111.issue9520@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
nosy: +lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9520>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:57:37 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 12 Nov 2010 00:57:37 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1289523457.11.0.493132463395.issue5412@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Fred, while you're at it have a look at your message here: http://bugs.python.org/issue9421#msg115558 (also documentation remarks on an otherwise closed issue).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:58:47 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 12 Nov 2010 00:58:47 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289523527.37.0.651902805574.issue10387@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:58:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 00:58:50 +0000
Subject: [issue7186] Document specialness of __doc__,
	and possibly other "special" attributes
In-Reply-To: <1256240855.61.0.550470965616.issue7186@psf.upfronthosting.co.za>
Message-ID: <1289523530.96.0.438072553683.issue7186@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is this obsoleted by #9451?

----------
nosy: +eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7186>
_______________________________________

From report at bugs.python.org  Fri Nov 12 01:59:13 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Fri, 12 Nov 2010 00:59:13 +0000
Subject: [issue9421] configparser.ConfigParser's getint,
	getboolean and getfloat don't accept `vars`
In-Reply-To: <1280428369.21.0.84678458473.issue9421@psf.upfronthosting.co.za>
Message-ID: <1289523553.59.0.0602572291325.issue9421@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9421>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:11:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:11:10 +0000
Subject: [issue6226] Inconsistent 'file' vs 'stream' kwarg in pprint,
	other stdlibs
In-Reply-To: <1244325728.64.0.945262534879.issue6226@psf.upfronthosting.co.za>
Message-ID: <1289524270.84.0.865111721752.issue6226@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m afraid backward compatibility binds us here.  For new code however, it would be nice to use one name consistently.  My preference goes to ?file?, because I really like the print function, but I suspect this could turn into bikeshedding quickly :)  I think this is too little an issue to warrant a line in the style guide.  Maybe just watch python-checkins and comment when someone adds a function using ?stream?, ?fp? or ?fileobj?.  I suggest closing this report as wontfix.

You may want to open a new report about the matter of pprint and print having incompatible signatures.  How about proposing a new function, say pprint.print, which could be a drop-in replacement for builtins.print?

----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6226>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:12:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:12:31 +0000
Subject: [issue1109602] Need some setup.py sanity
Message-ID: <1289524351.67.0.774798120597.issue1109602@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1109602>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:13:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:13:22 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1289524402.4.0.405200746406.issue9523@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
title: Improve dbm module -> Improve dbm modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:14:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:14:52 +0000
Subject: [issue8634] get method for dbm interface
In-Reply-To: <1273133367.38.0.142877532423.issue8634@psf.upfronthosting.co.za>
Message-ID: <1289524492.95.0.334140746155.issue8634@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The other bug report adds the get method as part of MutableMapping compliance, so I?m closing this as a obsoleted.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Improve dbm modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8634>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:15:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:15:08 +0000
Subject: [issue9523] Improve dbm modules
In-Reply-To: <1281021837.96.0.764638089257.issue9523@psf.upfronthosting.co.za>
Message-ID: <1289524508.87.0.204518197596.issue9523@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +Kain94, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9523>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:23:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:23:17 +0000
Subject: [issue962772] when both maintainer and author provided,
	author discarded
Message-ID: <1289524997.62.0.958691917031.issue962772@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>From PEP 345: ?Note that this field is intended for use when a project is being maintained by someone other than the original author: it should be omitted if it is identical to Author.?

It?s therefore logical that maintainer wins over author: The metadata file wants a contact point, so if the original author is not active anymore and there is another person acting as maintainer, the maintainer is the contact.

This is IMO a documentation bug, which I?m assigning to distutils2 (distutils docs only get quick fixes for things that don?t work at all).

----------
components: +Distutils2, Documentation -Distutils
versions: +3rd party -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue962772>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:26:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:26:48 +0000
Subject: [issue4972] context managerment support in imaplib, smtplib, ftplib
In-Reply-To: <1232213338.37.0.108210239108.issue4972@psf.upfronthosting.co.za>
Message-ID: <1289525208.87.0.00827366234753.issue4972@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> needs patch
title: let's equip ftplib.FTP with __enter__ and __exit__ -> context managerment support in imaplib, smtplib, ftplib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4972>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:27:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:27:15 +0000
Subject: [issue6320] Standard string encodings should include GSM0.38
In-Reply-To: <1245612481.83.0.685402230855.issue6320@psf.upfronthosting.co.za>
Message-ID: <1289525235.39.0.759860936103.issue6320@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6320>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:35:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:35:15 +0000
Subject: [issue7976] warnings should provide a public API for accessing its
	option parsing code
In-Reply-To: <1266771333.82.0.427614024661.issue7976@psf.upfronthosting.co.za>
Message-ID: <1289525715.82.0.801420622793.issue7976@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: unit test needed -> needs patch
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7976>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:36:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:36:27 +0000
Subject: [issue5616] Distutils 2to3 support doesn't have the doctest_only flag.
In-Reply-To: <1238452498.24.0.140926416369.issue5616@psf.upfronthosting.co.za>
Message-ID: <1289525787.22.0.748847486654.issue5616@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils2 -2to3 (2.x to 3.0 conversion tool)
stage:  -> unit test needed
versions: +3rd party, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5616>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:36:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:36:38 +0000
Subject: [issue5616] Distutils 2to3 support doesn't have the doctest_only flag.
In-Reply-To: <1238452498.24.0.140926416369.issue5616@psf.upfronthosting.co.za>
Message-ID: <1289525798.45.0.363321947149.issue5616@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5616>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:42:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:42:09 +0000
Subject: [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1289526129.73.0.198422720452.issue10149@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  There are a few typos (pices, recive) and markup glitches, which you can fix if you?d like to learn more about the markup, or else leave to someone else.  Those glitches are: bad indentation, missing blank line to make a new paragraph, text in backquotes without a :role: (or double backquotes for False).  From a checkout, run ?make html? to see the result.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10149>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:43:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:43:06 +0000
Subject: [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1289526186.42.0.493118879703.issue10149@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Also, s/receive few calls/receive more than one call/ (clearer IMO).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10149>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:47:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:47:48 +0000
Subject: [issue1051216] make distutils.core.run_setup re-entrant
Message-ID: <1289526468.76.0.296960154497.issue1051216@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Bob, thanks for the report and patch.  Could you add a test for this behavior?

(This is irrelevant for distutils2, where run_setup is gone.)

----------
assignee:  -> eric.araujo
nosy: +eric.araujo
type: feature request -> behavior
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1051216>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:54:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 01:54:05 +0000
Subject: [issue1051216] make distutils.core.run_setup re-entrant
Message-ID: <1289526845.37.0.365465542981.issue1051216@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

To clarify my position: This does not look like a sane use case, but if the code does not behave as documented it?s a bug that should be fixed.  Do you remember how you discovered the bug?

On second thought, I wonder if it?s useful to fix this.  Since there is a bug, are people using the function?  If not, is it worth fixing, since the function is removed in distutils2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1051216>
_______________________________________

From report at bugs.python.org  Fri Nov 12 02:57:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Nov 2010 01:57:39 +0000
Subject: [issue6226] Inconsistent 'file' vs 'stream' kwarg in pprint,
	other stdlibs
In-Reply-To: <1244325728.64.0.945262534879.issue6226@psf.upfronthosting.co.za>
Message-ID: <1289527059.86.0.726829451856.issue6226@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, simply saying "make it consistent" is a won't fix, because of backward compatibility issues.  Specific proposals for specific functions in a way that deals with the backward compatibility issues should be opened as new issues.

----------
nosy: +r.david.murray
resolution:  -> wont fix
stage: needs patch -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6226>
_______________________________________

From report at bugs.python.org  Fri Nov 12 03:01:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 02:01:12 +0000
Subject: [issue8561] Install .exes generated with distutils to not do a CRC
	check
In-Reply-To: <1272482067.44.0.313764636607.issue8561@psf.upfronthosting.co.za>
Message-ID: <1289527272.61.0.646497031549.issue8561@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  I think this is not specific to .exe installers, but an issue that may happen with any kind of download.  PyPI publishes MD5 checksums of distributions, which should be checked by tools that download distributions.  distutils2 does, and I?m sure other tools like pip are doing the same thing.  Does that address your concern?

----------
components: +Distutils2 -Distutils
nosy: +alexis, eric.araujo
versions: +3rd party -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8561>
_______________________________________

From report at bugs.python.org  Fri Nov 12 03:01:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 02:01:47 +0000
Subject: [issue8561] Install .exes generated with distutils to not do a CRC
	check
In-Reply-To: <1272482067.44.0.313764636607.issue8561@psf.upfronthosting.co.za>
Message-ID: <1289527307.62.0.634881613817.issue8561@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8561>
_______________________________________

From report at bugs.python.org  Fri Nov 12 03:16:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 02:16:12 +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: <1289528172.26.0.794153522344.issue9312@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I hope the patch is not outdated.  Terry, Georg, are you okay with it?

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Fri Nov 12 03:28:26 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Nov 2010 02:28:26 +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: <1289528906.55.0.445908032336.issue9312@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Fri Nov 12 03:29:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 02:29:23 +0000
Subject: [issue6226] Inconsistent 'file' vs 'stream' kwarg in pprint,
	other stdlibs
In-Reply-To: <1244325728.64.0.945262534879.issue6226@psf.upfronthosting.co.za>
Message-ID: <1289528963.91.0.515420465753.issue6226@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6226>
_______________________________________

From report at bugs.python.org  Fri Nov 12 03:32:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 02:32:42 +0000
Subject: [issue9338] argparse optionals with nargs='+' can't be followed by
	positionals
In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za>
Message-ID: <1289529162.68.0.254333441207.issue9338@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good to me.  Do you want to propose a code patch too, and/or more tests for non-simple cases?

----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9338>
_______________________________________

From report at bugs.python.org  Fri Nov 12 04:04:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 12 Nov 2010 03:04:26 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1289531066.93.0.526360056574.issue1553375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Vinay, your example with communicate only works because you removed the [:-1].  If you run your version against a debug build, the tests will fail.

I'm updating the patch with a version that works with both a non-debug and a debug build, and adds an additional test that shows that the chained full traceback fails even if the exception handler is not at the top level.  Tomorrow I'll post a request for help to python-dev, since I've nowhere near the knowledge of the CPython internals needed to figure out what is going on here.  (It is possible the traceback is in fact correct, but if so it is certainly unexpected and makes allframes a bit less useful.)

----------
Added file: http://bugs.python.org/file19574/full_traceback6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Fri Nov 12 04:05:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 03:05:47 +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: <1289531147.77.0.0882669267029.issue9312@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ok with me also to commit and backport for next releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Fri Nov 12 04:08:44 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 03:08:44 +0000
Subject: [issue10008] Two links point to same place
In-Reply-To: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>
Message-ID: <1289531324.13.0.136199737647.issue10008@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Georg, do you have any idea what the source of the index glitch is?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10008>
_______________________________________

From report at bugs.python.org  Fri Nov 12 05:20:25 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 12 Nov 2010 04:20:25 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1289535625.21.0.918785331701.issue10142@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Amaury, thanks for your valuable feedback.

1. I forgot about the python implementation. I am not familiar with the new IO framework. Implemented now.

3. These new SEEK modes should not be used in text mode. In my new patch the modes are rejected in text mode, allowed in binary mode.

2. I have spend the last 3 hours studying "test_io.py", and I don't understand the Mock* usage. Your MockRawIO hint is valuable, but I can't think a way to test that C/Python implementation passes the new flags to the OS. If I understand correctly, any method implemented in the Mock will be hit instead of the IO implementation, and anything that reach IO implementation will not go back to the Mock. I don't understand... :-?. Or can you magically insert the Mock between the IO module and the OS?. I know something like this is happening, but I don't understand the mechanism.

How do you choose what Mock* are you using in each test?.

I have read about Mock testing in the past, but I don't understand the use here. Are they actually Mocks, as explained in http://agiletesting.blogspot.com/2009/07/python-mock-testing-techniques-and.html , for example?

Sorry.

Could you provide some hint?. Maybe in python-dev, for more audience?.

I have implemented a test "test_posix", if your OS can report holes in a file (so far modern Solaris/OpenSolaris/OpenIndiana, don't know about *bsd). Other OSs will ignore the test.

I know your time is valuable. Thanking for investing in me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Fri Nov 12 05:20:39 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 12 Nov 2010 04:20:39 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1289535639.67.0.404347020572.issue10142@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
assignee: pitrou -> amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Fri Nov 12 05:36:30 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 04:36:30 +0000
Subject: [issue10304] error in tutorial triple-string example
In-Reply-To: <1288830503.92.0.649702536247.issue10304@psf.upfronthosting.co.za>
Message-ID: <1289536590.09.0.446455777731.issue10304@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

1. I decided to add '\' since this is what I normally do and also add one sentence explanation.

2. I changed ending from ' ' to ','.

Uploaded patch committed in rev86422, rev86423

----------
keywords: +patch
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
versions: +Python 3.1
Added file: http://bugs.python.org/file19575/Issue 10304.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10304>
_______________________________________

From report at bugs.python.org  Fri Nov 12 05:49:51 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 04:49:51 +0000
Subject: [issue1437699] allow unicode arguments for robotparser.can_fetch
Message-ID: <1289537391.46.0.234891520845.issue1437699@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The .../orig.html link now works and was last updated in August.
It has a link to .../robotstext.html.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1437699>
_______________________________________

From report at bugs.python.org  Fri Nov 12 05:54:45 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 04:54:45 +0000
Subject: [issue1654974] Binding annotations in tracebacks.
Message-ID: <1289537685.1.0.551471632899.issue1654974@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> out of date
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1654974>
_______________________________________

From report at bugs.python.org  Fri Nov 12 05:57:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 04:57:25 +0000
Subject: [issue1733259] ZipFile CallBack Needed...
Message-ID: <1289537845.51.0.739185700102.issue1733259@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1733259>
_______________________________________

From report at bugs.python.org  Fri Nov 12 05:59:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 04:59:34 +0000
Subject: [issue1777134] minidom pretty xml output improvement
Message-ID: <1289537974.8.0.553390188878.issue1777134@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/issue1777134>
_______________________________________

From report at bugs.python.org  Fri Nov 12 06:26:20 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 05:26:20 +0000
Subject: [issue3720] segfault in for loop with evil iterator
In-Reply-To: <1219983572.61.0.35264499467.issue3720@psf.upfronthosting.co.za>
Message-ID: <1289539580.41.0.467639662827.issue3720@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Too late for 2.6.6 ;-)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3720>
_______________________________________

From report at bugs.python.org  Fri Nov 12 06:31:10 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 05:31:10 +0000
Subject: [issue4015] Make installed scripts executable on windows
In-Reply-To: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>
Message-ID: <1289539870.93.0.246713166254.issue4015@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
nosy:  -terry.reedy
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4015>
_______________________________________

From report at bugs.python.org  Fri Nov 12 06:33:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 05:33:12 +0000
Subject: [issue4037] doctest.py should include method descriptors when looking
	inside a class __dict__
In-Reply-To: <1223079206.04.0.17382541424.issue4037@psf.upfronthosting.co.za>
Message-ID: <1289539992.11.0.109987722136.issue4037@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4037>
_______________________________________

From report at bugs.python.org  Fri Nov 12 06:58:03 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 05:58:03 +0000
Subject: [issue5578] unqualified exec in class body
In-Reply-To: <1238164857.67.0.53034733648.issue5578@psf.upfronthosting.co.za>
Message-ID: <1289541483.31.0.647429631458.issue5578@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5578>
_______________________________________

From report at bugs.python.org  Fri Nov 12 06:58:44 2010
From: report at bugs.python.org (Brad Greenlee)
Date: Fri, 12 Nov 2010 05:58:44 +0000
Subject: [issue10392] GZipFile crash when fileobj.mode is None
In-Reply-To: <1289541524.38.0.073026896043.issue10392@psf.upfronthosting.co.za>
Message-ID: <1289541524.38.0.073026896043.issue10392@psf.upfronthosting.co.za>


New submission from Brad Greenlee <brad at footle.org>:

If GZipFile.__init_ is passed a fileobj that has a mode attribute set to None, it will crash with a "'NoneType' object is unsubscriptable" error when it tries to read the first character of the mode.

I ran across this when trying to pass GZipFile an uploaded file in Django 1.2.3. Django produced an InMemoryUploadedFile object that has a mode attribute set to None.

The attached patch fixes the issue by only using fileobj.mode if it exists and is not None.

(The patch is against 2.7, although the issue exists in all versions I've looked at.)

----------
components: Library (Lib)
files: gzip_mode_fix.diff
keywords: patch
messages: 121021
nosy: bgreenlee
priority: normal
severity: normal
status: open
title: GZipFile crash when fileobj.mode is None
type: crash
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19576/gzip_mode_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10392>
_______________________________________

From report at bugs.python.org  Fri Nov 12 07:03:38 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 12 Nov 2010 06:03:38 +0000
Subject: [issue9312] Fix usage of :option: markup in stdlib ReST docs
In-Reply-To: <1289531147.77.0.0882669267029.issue9312@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=ktWS6QnJUwfeHpFEf5k5o6U+LSexko0MO5DfA@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

On Fri, Nov 12, 2010 at 05:05, Terry J. Reedy <report at bugs.python.org>wrote:

Please let me know if there are problems applying it and with which
versions, I will fix it up to bring it up to date. It's a tricky patch
(affects many files in many places), so there might be difficulties.

----------
Added file: http://bugs.python.org/file19577/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________
-------------- next part --------------
<div dir="ltr"><div class="gmail_quote">On Fri, Nov 12, 2010 at 05:05, Terry J. Reedy <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;">

<div class="im"><br>
Terry J. Reedy &lt;<a href="mailto:tjreedy at udel.edu">tjreedy at udel.edu</a>&gt; added the comment:<br>
<br>
</div>Ok with me also to commit and backport for next releases.<br>
<br></blockquote></div><br>Please let me know if there are problems applying it and with which 
versions, I will fix it up to bring it up to date. It&#39;s a tricky patch 
(affects many files in many places), so there might be difficulties.<br><br>
<br><br></div>

From report at bugs.python.org  Fri Nov 12 07:06:24 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 06:06:24 +0000
Subject: [issue6216] Raise Unicode KEEPALIVE_SIZE_LIMIT from 9 to 32?
In-Reply-To: <1244246653.62.0.629764911773.issue6216@psf.upfronthosting.co.za>
Message-ID: <1289541984.85.0.740077186625.issue6216@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Two weeks left for 3.2 ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6216>
_______________________________________

From report at bugs.python.org  Fri Nov 12 07:07:58 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 06:07:58 +0000
Subject: [issue6335] Add support for mingw
In-Reply-To: <1245849042.65.0.399048729588.issue6335@psf.upfronthosting.co.za>
Message-ID: <1289542078.59.0.690385821935.issue6335@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6335>
_______________________________________

From report at bugs.python.org  Fri Nov 12 07:14:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Nov 2010 06:14:07 +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: <1289542447.68.0.138607324448.issue9312@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file19577/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Fri Nov 12 07:14:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 06:14:43 +0000
Subject: [issue6942] email.generator.Generator memory consumption
In-Reply-To: <1253318032.63.0.187743524666.issue6942@psf.upfronthosting.co.za>
Message-ID: <1289542483.91.0.931750381533.issue6942@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/issue6942>
_______________________________________

From report at bugs.python.org  Fri Nov 12 07:16:05 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Nov 2010 06:16:05 +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: <1289542565.98.0.578209555831.issue9312@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, please apply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Fri Nov 12 07:21:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Nov 2010 06:21:02 +0000
Subject: [issue10008] Two links point to same place
In-Reply-To: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>
Message-ID: <1289542862.14.0.272360268507.issue10008@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It is indeed what Hirokazu suggested: there were two ".. class:: ZipFile" entries in the docs.  I've added ":noindex:" now to one of them in r86425.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10008>
_______________________________________

From report at bugs.python.org  Fri Nov 12 08:23:35 2010
From: report at bugs.python.org (Collin Winter)
Date: Fri, 12 Nov 2010 07:23:35 +0000
Subject: [issue1625576] add ability to specify name to os.fdopen
Message-ID: <1289546615.58.0.11948683674.issue1625576@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Christian: yes, that sounds fine.

----------
assignee: collinwinter -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625576>
_______________________________________

From report at bugs.python.org  Fri Nov 12 08:57:03 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Nov 2010 07:57:03 +0000
Subject: [issue1625576] add ability to specify name to os.fdopen
Message-ID: <1289548623.59.0.17768007689.issue1625576@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Collin: I doubt Christian will do much about this anymore :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625576>
_______________________________________

From report at bugs.python.org  Fri Nov 12 10:17:39 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 12 Nov 2010 09:17:39 +0000
Subject: [issue10371] Deprecate trace module undocumented API
In-Reply-To: <1289269952.54.0.146506315747.issue10371@psf.upfronthosting.co.za>
Message-ID: <1289553459.22.0.698088431451.issue10371@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Alexander, http://bugs.python.org/file19553/trace-deprecations.diff looks good to me

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10371>
_______________________________________

From report at bugs.python.org  Fri Nov 12 10:26:38 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 12 Nov 2010 09:26:38 +0000
Subject: [issue962772] when both maintainer and author provided,
	author discarded
Message-ID: <1289553998.59.0.765859902412.issue962772@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I think this might be more than a documentation bug. Akira's example shows
that the maintainer is erroneously listed as the author. This does not
seem fair to an author who in general will have written most of a package.

I'd prefer a separate maintainer field.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue962772>
_______________________________________

From report at bugs.python.org  Fri Nov 12 10:55:06 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 12 Nov 2010 09:55:06 +0000
Subject: [issue962772] when both maintainer and author provided,
	author discarded
Message-ID: <1289555706.77.0.973306781254.issue962772@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

PEP 345 adds a Maintainer field to fix this, and this is now present and active in Ditsutils2. You can now have both.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue962772>
_______________________________________

From report at bugs.python.org  Fri Nov 12 11:03:36 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 12 Nov 2010 10:03:36 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1289556216.88.0.568978866353.issue9264@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Alexander,

I'm submitting a patch for Doc/library/trace.rst for 3.2, incorporating the stylistic changes you propose.

It would be really great to see this fixed for the next release of 3.2, since the documentation improvement is major, and it's already in for 2.6

Perhaps if this is found acceptable, the same patch could be applied to 2.7 as well.

Let me know if any more fixes are needed, I will make my best attempt to respond promptly.

----------
Added file: http://bugs.python.org/file19578/issue9264.py32.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Fri Nov 12 11:17:56 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 12 Nov 2010 10:17:56 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289295899.43.0.275178242611.issue10359@psf.upfronthosting.co.za>
Message-ID: <hbf.20101112v851@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

STINNER Victor writes:
> Python-ast.c: why do you move req_name and req_type outside PyAST_obj2mod()?

Eh, in case I've managed to be sufficiently unclear: The reason I
modified it at all was because the initialization is not valid in C90,
only in C99.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Fri Nov 12 11:33:56 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 12 Nov 2010 10:33:56 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1289332049.46.0.37828514943.issue10070@psf.upfronthosting.co.za>
Message-ID: <hbf.20101112viie@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Martin v. L??wis writes:
> And I still don't understand the rationale for this request. Can you
> please post an example Python module that has this markup you are asking
> for, so I can show you how to achieve what you want without the markup?

Eh.  I thought you said you did understand.  But here is one:
    http://folk.uio.no/hbf/ZipHTTPServer.py

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Fri Nov 12 14:15:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 13:15:56 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1289567756.65.0.0739373793952.issue10070@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think 2to3 is designed to take 2.x code and turn it into 3.x code.  Codebases using tricks and hacks to support both 2.x and 3.x (like the example you linked to) cannot be handled by 2to3.  You have to make a choice between manual maintenance of parallel codebases, automatic 2to3 translation or cross-version compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Fri Nov 12 15:04:00 2010
From: report at bugs.python.org (Abyx)
Date: Fri, 12 Nov 2010 14:04:00 +0000
Subject: [issue10393] "with" statement isn't thread-safe
In-Reply-To: <1289570640.39.0.977918718998.issue10393@psf.upfronthosting.co.za>
Message-ID: <1289570640.39.0.977918718998.issue10393@psf.upfronthosting.co.za>


New submission from Abyx <fl.lllj at gmail.com>:

Code to reproduce the bug:

#include <python.h>
#include <windows.h>

DWORD WINAPI thread_fn(void* code)
{
	PyGILState_STATE state = PyGILState_Ensure();
	PyRun_SimpleString("with sync: print('.')\n");
	PyGILState_Release(state);
	return 0;
}

int main()
{
	PyEval_InitThreads();
	Py_Initialize();
	PyRun_SimpleString("import _thread\n");
	PyRun_SimpleString("sync = _thread.allocate_lock()\n");
	PyThreadState* mainstate = PyEval_SaveThread();

	HANDLE hThread1 = CreateThread(0, 0, thread_fn, 0, 0, 0);
	HANDLE hThread2 = CreateThread(0, 0, thread_fn, 0, 0, 0);
	WaitForSingleObject(hThread1, INFINITE);
	WaitForSingleObject(hThread2, INFINITE);

	PyEval_RestoreThread(mainstate);
	Py_Finalize();
}

------------ Output ------
.
.
Traceback (most recent call last):
  File "<string>", line 2, in <module>
NameError: name '_[1]' is not defined
----------- End of output -----

Probably both threads uses the same "_" global variable. First thread releases GIL in "print" function, then second thread overwrites "_", and then first thread raises the NameError accessing "_" later. Sometimes (not ever) the "sync" kept locked, and program deadlocks on next "sync.acquire()" call from another thread (if any).

----------
components: Interpreter Core
messages: 121035
nosy: Abyx
priority: normal
severity: normal
status: open
title: "with" statement isn't thread-safe
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10393>
_______________________________________

From report at bugs.python.org  Fri Nov 12 15:05:08 2010
From: report at bugs.python.org (Christoph Mathys)
Date: Fri, 12 Nov 2010 14:05:08 +0000
Subject: [issue10394] subprocess Popen deadlock
In-Reply-To: <1289570708.02.0.0744739807294.issue10394@psf.upfronthosting.co.za>
Message-ID: <1289570708.02.0.0744739807294.issue10394@psf.upfronthosting.co.za>


New submission from Christoph Mathys <eraserix at gmail.com>:

The ctor of subprocess.Popen has a race condition, which the attached program should demonstrate (on my computer a few seconds are enough). Program One sleeps for 2 seconds, Program Two exits right after execve. Now I would expect Program Two to take a very short time between Popen and the completion of wait(), but it regularly takes about 2 seconds.

The problem is this: Popen._execute_child opens a pipe and sets the FD_CLOEXEC flag. If thread_1 just finished creating the pipe but could not yet set FD_CLOEXEC when thread_2 fork()s, thread_1 will lock up when it reads on the pipe (errpipe_read). The process forked by thread_1 will close the pipe, but the process forked by thread_2 will only close the pipe when it exits, blocking thread_1 inside the read function until then.

I see different options:
Linux has the platform specific flag O_CLOEXEC to set this flag during open() (the manpage of open says since 2.6.23, so highly platform dependent)

To just solve the problem for Popens ctor it is enough to serialize all code from before pipe() until after fork(). This can still lead to problems if fork is called in other contexts than Popens ctor.

A general solution would be to use a socket which can be shutdown().

If close_fds is set for Popens ctor, the problem does not occur because the extra pipe of the forked process will be closed.

----------
components: Library (Lib)
files: deadlock.py
messages: 121036
nosy: Christoph.Mathys
priority: normal
severity: normal
status: open
title: subprocess Popen deadlock
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19579/deadlock.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10394>
_______________________________________

From report at bugs.python.org  Fri Nov 12 15:39:32 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Nov 2010 14:39:32 +0000
Subject: [issue10393] "with" statement isn't thread-safe
In-Reply-To: <1289570640.39.0.977918718998.issue10393@psf.upfronthosting.co.za>
Message-ID: <1289572772.08.0.897826498851.issue10393@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Agreed. There was a similar issue in python2.6 with list comprehensions.
The issue is that both threads run the code with the same globals dictionary, and top-level code use the same dict for locals and globals.

This is already fixed in 2.7 and 3.2, temporary variables are no more used.

Meanwhile, I can see two workarounds:
- Run the code in a python function; the _[1] variable will be local to the function, and distinct for each thread.
- Use PyRun_String(), and pass a different dictionary for each thread::

    PyObject *d, *v;
    d = PyDict_New();
    v = PyRun_String(command, Py_file_input, d, d);
    Py_XDECREF(v);
    Py_XDECREF(d);

But the 3.2 fix cannot be ported to 3.1: it needs a new opcode.

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10393>
_______________________________________

From report at bugs.python.org  Fri Nov 12 16:14:07 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 12 Nov 2010 15:14:07 +0000
Subject: [issue10395] os.path.commonprefix broken by design
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>


New submission from Ronald Oussoren <ronaldoussoren at mac.com>:

The documentation for os.path.commonprefix notes:

os.path.commonprefix(list)
Return the longest path prefix (taken character-by-character) that is a prefix of all paths in list. If list is empty, return the empty string (''). Note that this may return invalid paths because it works a character at a time.

And indeed:


>>> os.path.commonprefix(['/usr/bin', '/usr/bicycle'])
'/usr/bi'


This is IMHO useless behaviour for a function in the os.path namespace, I'd expect that os.path.commonprefix works with path elements (e.g. that the call above would have returned '/usr').

----------
components: Library (Lib)
messages: 121038
nosy: ronaldoussoren
priority: low
severity: normal
status: open
title: os.path.commonprefix broken by design
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10395>
_______________________________________

From report at bugs.python.org  Fri Nov 12 16:38:00 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 12 Nov 2010 15:38:00 +0000
Subject: [issue10395] os.path.commonprefix broken by design
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1289576280.62.0.63141469767.issue10395@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Indeed, that behavior seems completely useless.

I've verified that it works the same in 2.5.1.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10395>
_______________________________________

From report at bugs.python.org  Fri Nov 12 16:48:20 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 12 Nov 2010 15:48:20 +0000
Subject: [issue10395] os.path.commonprefix broken by design
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1289576900.32.0.558648730696.issue10395@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Although there are test cases in test_genericpath that verify this behavior, so apparently it's intentional.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10395>
_______________________________________

From report at bugs.python.org  Fri Nov 12 17:03:02 2010
From: report at bugs.python.org (Abyx)
Date: Fri, 12 Nov 2010 16:03:02 +0000
Subject: [issue10393] "with" statement isn't thread-safe
In-Reply-To: <1289570640.39.0.977918718998.issue10393@psf.upfronthosting.co.za>
Message-ID: <1289577782.37.0.694067186499.issue10393@psf.upfronthosting.co.za>


Abyx <fl.lllj at gmail.com> added the comment:

Thanks.

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10393>
_______________________________________

From report at bugs.python.org  Fri Nov 12 17:04:38 2010
From: report at bugs.python.org (Typo)
Date: Fri, 12 Nov 2010 16:04:38 +0000
Subject: [issue10364] Color coding fails after running program.
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1289577878.4.0.691833732174.issue10364@psf.upfronthosting.co.za>


Typo <lol.rabbit at yahoo.com> added the comment:

Hey, I found out what the problem was. I wasn't saving the files as a .py file. As soon as I did that the color came back. Sorry to have wasted your time >.<

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10364>
_______________________________________

From report at bugs.python.org  Fri Nov 12 17:18:08 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 12 Nov 2010 16:18:08 +0000
Subject: [issue10395] os.path.commonprefix broken by design
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1289578688.42.0.606225414262.issue10395@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

That's why I write 'broken by design' in the title.

A "fix" for this will have to a new function, if any get added (I've written a unix implementation that finds the longest shared path several times and can provide an implementation and tests when others agree that this would be useful)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10395>
_______________________________________

From report at bugs.python.org  Fri Nov 12 17:47:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 16:47:08 +0000
Subject: [issue10364] Color coding fails after running program.
In-Reply-To: <1289239102.42.0.620564801896.issue10364@psf.upfronthosting.co.za>
Message-ID: <1289580428.69.0.354513265923.issue10364@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thank you for reporting back. This could be closed as invalid, but since I think this is something I should have known or guessed, I will leave it open for now as a reminder to look at the docs sometime and see if anything should be added somewhere.

----------
assignee:  -> terry.reedy
components: +Documentation -None
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10364>
_______________________________________

From report at bugs.python.org  Fri Nov 12 18:07:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Nov 2010 17:07:03 +0000
Subject: [issue10359] ISO C cleanup
In-Reply-To: <1289225493.06.0.31753137713.issue10359@psf.upfronthosting.co.za>
Message-ID: <1289581623.07.0.11049998428.issue10359@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Stable branches (2.7 and 3.1) only get bug fixes, not new features or
> code cleanups.

?ric, making code compliant *is* a bug fix (admittedly of minor importance here, since all modern compilers accept the non-compliant code anyway).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10359>
_______________________________________

From report at bugs.python.org  Fri Nov 12 18:10:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Nov 2010 17:10:39 +0000
Subject: [issue1625576] add ability to specify name to os.fdopen
Message-ID: <1289581839.66.0.278179718811.issue1625576@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The requested feature would require an additional argument to fdopen() and open(), which already have many args. It would be better IMO to make the `name` attribute on file objects writeable.

By the way, right now (in 3.x) fdopen() gives you the file descriptor number, which is better than nothing:

>>> import os
>>> f = os.fdopen(2, "w")
>>> f
<_io.TextIOWrapper name=2 encoding='UTF-8'>

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625576>
_______________________________________

From report at bugs.python.org  Fri Nov 12 18:22:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 17:22:09 +0000
Subject: [issue10373] Setup Script example incorrect
In-Reply-To: <1289308146.55.0.869173171863.issue10373@psf.upfronthosting.co.za>
Message-ID: <1289582529.08.0.914212432047.issue10373@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Setuptools is not a part of Python, and distutils docs don?t mention issues specific to third-party tools.  I think I will reject this bug.

----------
assignee: docs at python -> eric.araujo
nosy: +eric.araujo
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10373>
_______________________________________

From report at bugs.python.org  Fri Nov 12 18:25:42 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 12 Nov 2010 17:25:42 +0000
Subject: [issue8332] regrtest single TestClass/test_method
In-Reply-To: <1270631958.05.0.652340331128.issue8332@psf.upfronthosting.co.za>
Message-ID: <1289582742.17.0.978804521808.issue8332@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Yes. You're missing the second case. In:
> regrtest [options] test_file.test_method

You don't specify class name. This saves some time you need to navigate and copy/paste name of container class. It will save more time if masks are used by default. To illustrate this let's introduce '-l' key that lists all found tests to test test discovery (no errors in this sentence).

> regrtest -l *des*
test_file.FancyRenameTests.test_no_*des*t_exists
test_file.FancyRenameTests.test_*des*t_exists
test_file.FancyRenameTests.test_*des*t_opened
test_file.GitFile*des*tTests.test_invalid
test_file.GitFile*des*tTests.test_readonly
test_*des*t.SomeClass.some_test
....

*stars* in results highlight matched substring.

Rationale: The most common operation when looking for tests to run is grep. You don't need to remember option name to specify mask - just use mask - it will run discovery and execute only tests found. '-l' key in test runner can be used to quickly grep available tests to find the exact name and run only it.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8332>
_______________________________________

From report at bugs.python.org  Fri Nov 12 18:50:21 2010
From: report at bugs.python.org (Michael Hoffman)
Date: Fri, 12 Nov 2010 17:50:21 +0000
Subject: [issue10396] stdin argument to pdb.Pdb doesn't work unless you also
	set Pdb.use_rawinput = False
In-Reply-To: <1289584221.71.0.586527779083.issue10396@psf.upfronthosting.co.za>
Message-ID: <1289584221.71.0.586527779083.issue10396@psf.upfronthosting.co.za>


New submission from Michael Hoffman <qq9jsuvyyw at snkmail.com>:

If you create a Pdb instance with an stdin argument, the default behavior is for commands to be retrieved using raw_input(), which uses sys.stdin instead, thereby causing the stdin argument to be without effect.

You can work around this by setting the use_rawinput attribute of the instance to False, but this should be done whenever an stdin argument is given to the constructor.

----------
components: Library (Lib)
files: testcase.py
messages: 121050
nosy: hoffman
priority: normal
severity: normal
status: open
title: stdin argument to pdb.Pdb doesn't work unless you also set Pdb.use_rawinput = False
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19580/testcase.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10396>
_______________________________________

From report at bugs.python.org  Fri Nov 12 18:51:12 2010
From: report at bugs.python.org (Michael Hoffman)
Date: Fri, 12 Nov 2010 17:51:12 +0000
Subject: [issue10396] stdin argument to pdb.Pdb doesn't work unless you also
	set Pdb.use_rawinput = False
In-Reply-To: <1289584221.71.0.586527779083.issue10396@psf.upfronthosting.co.za>
Message-ID: <1289584272.26.0.0570002980197.issue10396@psf.upfronthosting.co.za>


Changes by Michael Hoffman <qq9jsuvyyw at snkmail.com>:


Added file: http://bugs.python.org/file19581/expected_behavior.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10396>
_______________________________________

From report at bugs.python.org  Fri Nov 12 18:54:17 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 17:54:17 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1289584457.06.0.80240927502.issue10342@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>What is the best way to pass around source code?
> - file-like objects, line iterators, readline-like function?

Line iterator (list of lines) as returned by open().readlines.
Memory should not be an issue. Read disk once and close.

with open('file', ...) as f:
  src = f.readlines()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Fri Nov 12 19:00:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 18:00:05 +0000
Subject: [issue10344] codecs.readline doesn't care buffering=0
In-Reply-To: <1289084418.05.0.231852584468.issue10344@psf.upfronthosting.co.za>
Message-ID: <1289584805.92.0.77981929031.issue10344@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please suggest a specific alteration in the codecs.readline doc that we can then discuss.

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
nosy: +docs at python, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10344>
_______________________________________

From report at bugs.python.org  Fri Nov 12 19:34:53 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 18:34:53 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1289586893.41.0.221416127267.issue10356@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/issue10356>
_______________________________________

From report at bugs.python.org  Fri Nov 12 19:50:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Nov 2010 18:50:01 +0000
Subject: [issue4471] IMAP4 missing support for starttls
In-Reply-To: <1228062796.45.0.215183772699.issue4471@psf.upfronthosting.co.za>
Message-ID: <1289587801.98.0.750840096289.issue4471@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The starttls patch has been committed in r86431. Thank you very much for writing the initial patch.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4471>
_______________________________________

From report at bugs.python.org  Fri Nov 12 19:50:29 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 18:50:29 +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: <1289587829.09.0.429597016654.issue10365@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

That suggests that the last statement needs to be guarded somehow.
I re-versioned to 3.2 because 3.1.final will be out very soon.
I expect 3.2 and 2.7 should have same problem.

----------
nosy: +terry.reedy
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10365>
_______________________________________

From report at bugs.python.org  Fri Nov 12 19:57:24 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 18:57:24 +0000
Subject: [issue10375] 2to3 print(single argument)
In-Reply-To: <1289311942.35.0.609245522343.issue10375@psf.upfronthosting.co.za>
Message-ID: <1289588244.4.0.608123742555.issue10375@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>[Copied from Issue10070.]
which is to say (for the benefit of other reviewers):
This was a minor sub-issue mentioned there in passing and independent of the main issue and ignored in the extensive discussion thereof.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10375>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:00:06 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 12 Nov 2010 19:00:06 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1289588406.95.0.896698401792.issue1589@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:09:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 12 Nov 2010 19:09:08 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289584457.06.0.80240927502.issue10342@psf.upfronthosting.co.za>
Message-ID: <AANLkTinXZY-sP98jAehSo4hu_c90kQkx4N+Rk9bYMRMh@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 12, 2010 at 12:54 PM, Terry J. Reedy <report at bugs.python.org> wrote:
..
>>What is the best way to pass around source code?
>> - file-like objects, line iterators, readline-like function?
>
> Line iterator (list of lines) as returned by open().readlines.
> Memory should not be an issue. Read disk once and close.
>
> with open('file', ...) as f:
> ?src = f.readlines()

Line iterator does not carry the information about source encoding
which may be important for annotating the source code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:09:49 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 19:09:49 +0000
Subject: [issue10385] Mark up "subprocess" as module in its doc
In-Reply-To: <1289444045.02.0.247018067393.issue10385@psf.upfronthosting.co.za>
Message-ID: <1289588989.7.0.267240001369.issue10385@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

1. Does the markup make any visual difference?
2. Does the markup affect the index?
3. What do other module docs do?

I notice that 'Tkinter' appears in several section headings. Is it marked? (Is the upper case a holdover that should be lowercased?)

'Turtle' also appears in several section headers. That could be interpreted as a reference to the class rather than the module.

----------
nosy: +georg.brandl, terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10385>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:16:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 12 Nov 2010 19:16:56 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1289589416.97.0.797537733451.issue10070@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't understand the example, either. If I run 2to3 on it, I get, as the only change

 if sys.version_info[0] < 3:             # Python 2
-    from urllib           import quote, unquote
-    from urlparse         import urlparse, urlunparse
-    from BaseHTTPServer   import HTTPServer
-    from SimpleHTTPServer import SimpleHTTPRequestHandler
+    from urllib.parse import quote, unquote
+    from urllib.parse         import urlparse, urlunparse
+    from http.server   import HTTPServer
+    from http.server import SimpleHTTPRequestHandler
     def str2data(s, is_nonascii=re.compile("[^\0-\x7F]").search):

As this code is in a Python 2.x block: why does this change cause problems to you? You are supposed to run the 2to3 result in Python 3, and this conversion result will run correctly in Python 3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:17:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 19:17:43 +0000
Subject: [issue10384] SyntaxError should contain exact location of the invalid
	character in identifier
In-Reply-To: <1289439285.11.0.506002899946.issue10384@psf.upfronthosting.co.za>
Message-ID: <1289589463.83.0.676532714207.issue10384@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I see the marker pointing to the space after '=', which is *really* not helpful. If '5' were instead an identifier, one might be really misdirected. So best would be "Invalid char '0xnnnn' at position n in identifier 'something'"
+1 to any improvement in SyntaxError reports.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10384>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:21:51 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Fri, 12 Nov 2010 19:21:51 +0000
Subject: [issue10397] Unified Benchmark Suite fails on py3k with --track-memory
In-Reply-To: <1289589711.2.0.279349979417.issue10397@psf.upfronthosting.co.za>
Message-ID: <1289589711.2.0.279349979417.issue10397@psf.upfronthosting.co.za>


New submission from Bobby Impollonia <bobbyi at gmail.com>:

Steps to reproduce (requires linux because the --track-memory (-m) option to perf.py is linux-only):
hg clone http://hg.python.org/benchmarks/ py2benchmarks
mkdir py3benchmarks
cd py3benchmarks
../py2benchmarks/make_perf3.sh ../py2benchmarks
py3k perf.py -f -m -b normal_startup old_py3k new_py3k

With --track-memory, the normal_startup benchmark (which is part of the py3k benchmark group) invokes the interpreter under test as:
py3k -c 'for _ in xrange(200000): pass'

This fails on py3k due to the use of xrange, which is not caught by 2to3 since it appears inside a quoted string (the command line argument).

A patch is attached that resolves the issue by changing the for loop with xrange into a while loop.

----------
assignee: collinwinter
components: Benchmarks
files: perf.patch
keywords: patch
messages: 121060
nosy: bobbyi, collinwinter, pitrou
priority: normal
severity: normal
status: open
title: Unified Benchmark Suite fails on py3k with --track-memory
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19582/perf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10397>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:27:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 12 Nov 2010 19:27:36 +0000
Subject: [issue10385] Mark up "subprocess" as module in its doc
In-Reply-To: <1289588989.7.0.267240001369.issue10385@psf.upfronthosting.co.za>
Message-ID: <AANLkTinfMmZv-4Xy0=boCv0-x1ftWX4G5FTcVfSFBGL4@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 12, 2010 at 2:09 PM, Terry J. Reedy <report at bugs.python.org> wrote:
..
> 1. Does the markup make any visual difference?

It does on my browser.  (I wouldn't have noticed it otherwise.) See
http://docs.python.org/dev/contents.html

> 2. Does the markup affect the index?

I don't think so because module names are already in the index.

This is either holdover or title-case.  In either case it should be
fixed.  Note that in some section titles it is lower case and marked
up properly.

> 'Turtle' also appears in several section headers. That could be interpreted
> as a reference to the class rather than the module.

In "Turtle graphics" it is neither -- just part of the name of the
graphics framework.  When it is a name of the class, as in " Overview
of available Turtle and Screen methods," is should be marked up with
:class: IMO.  In "Tell Turtle?s state", I think "turtle" should be
lower-cased.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10385>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:32:12 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 19:32:12 +0000
Subject: [issue10350] errno is read too late
In-Reply-To: <1289206098.51.0.17539694799.issue10350@psf.upfronthosting.co.za>
Message-ID: <1289590332.36.0.347389142952.issue10350@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This stuff is hard to write automated tests for, hence there are none.

The patch is mostly straightforward: capture errno with new variable err at point of possible error when intervening calculation is needed before testing the value of errno. This seems like a good idea.

There is one relocation of memory freeing and the additions of
+        if (res >= 0)
+            break;
which I cannot evaluate.

----------
nosy: +terry.reedy
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10350>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:35:37 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 12 Nov 2010 19:35:37 +0000
Subject: [issue10395] os.path.commonprefix broken by design
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1289590537.91.0.571008177506.issue10395@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This goes back to issue400788 and

http://mail.python.org/pipermail/python-dev/2000-July/005897.html
http://mail.python.org/pipermail/python-dev/2000-August/008385.html

Skip changed it to do something meaningful (more than ten years ago), Mark Hammond complained that it was backwards incompatible, Tim Peters argued that you shouldn't change a function if the documented behavior matches the implementation, and Skip reverted the change and added more documentation to make the actual behavior more explicit.

It may be useless, but it's certainly not broken. In addition, it's very likely that applications of it rely on the very semantics that it has.

In any case, anybody proposing a change should go back and re-read the old threads.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10395>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:36:08 2010
From: report at bugs.python.org (Jani Poikela)
Date: Fri, 12 Nov 2010 19:36:08 +0000
Subject: [issue10398] errors in docs re module initialization vs self arg to
	functions
In-Reply-To: <1289590568.94.0.655390055242.issue10398@psf.upfronthosting.co.za>
Message-ID: <1289590568.94.0.655390055242.issue10398@psf.upfronthosting.co.za>


New submission from Jani Poikela <poppis.poikela at gmail.com>:

Copy of issue 6421
Affects 2.7 too...

----------
assignee: docs at python
components: Documentation
messages: 121064
nosy: Jani.Poikela, aleax, docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: errors in docs re module initialization vs self arg to functions
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10398>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:46:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Nov 2010 19:46:06 +0000
Subject: [issue10398] errors in docs re module initialization vs self arg to
	functions
In-Reply-To: <1289590568.94.0.655390055242.issue10398@psf.upfronthosting.co.za>
Message-ID: <1289591166.72.0.0722964115999.issue10398@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, done in r86432.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10398>
_______________________________________

From report at bugs.python.org  Fri Nov 12 20:48:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 12 Nov 2010 19:48:25 +0000
Subject: [issue10385] Mark up "subprocess" as module in its doc
In-Reply-To: <1289444045.02.0.247018067393.issue10385@psf.upfronthosting.co.za>
Message-ID: <1289591305.39.0.518633031194.issue10385@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Eric: any :mod: role never affects the index.  Only the module directive does.

Otherwise, I concur that it's not mandatory to mark up every occurrence of the module name, but it's nice in section headings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10385>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:08:00 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 20:08:00 +0000
Subject: [issue10342] trace module cannot produce coverage reports for zipped
	modules
In-Reply-To: <1289057209.7.0.964126417973.issue10342@psf.upfronthosting.co.za>
Message-ID: <1289592480.61.0.0462681141639.issue10342@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>Line iterator does not carry the information about source encoding
which may be important for annotating the source code.

I would pass around both encoding and lines, possibly as a tuple.

A person heavily into OO might define a _Source class and turn the private functions into methods. But that would not play well with the deprecation process until it is done with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10342>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:16:53 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 12 Nov 2010 20:16:53 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

In msg#120541 of issue#1346238 Raymond suggested to "aim high", so here goes...

I'm opening this as a separate bug as it's a very different approach to the patches in that bug; adding those on the nosy list for that bug.  Sorry in advance about the epic length of this comment.

I've been experimenting with AST optimizations, and have a (very) primitive implementation of function-call inlining.  As is, it's deeply flawed, but in a spirit of "Release Early, Release Often" I though I'd post what I have so far, and try to enumerate the rest of the work that would need doing to get this into, say Python 3.3

The attached patch adds an AST optimization pass to Python/compiler.c.  It does this by adding an __optimizer__.py module: the compiler converts the AST to a Python representation using ast2mod, and calls out to __optimizer__.optimize_ast().  This can then (potentially) apply a series of manipulations to the tree.  The result is then converted back from python to ast objects, and compilation proceeds as normal on the modified AST tree.

I initially was experimenting with a .c implementation, but moving to .py makes things _much_ easier to develop and debug.  In particular, I'm using graphviz's "dot" tool to generate before/after visualizations of the AST.

The optimizer doesn't try to optimize itself (or anything that it imports), to avoid infinite recursion when we have a cold .pyo cache.

Currently I'm doing the AST optimization before symbol table generation.  This means that the inlining is deeply flawed, as it has no knowledge of the scope of names.  A robust implementation would compare the scopes of the callsite and that of the function body, and remap locals accordingly.  The current implementation renames all name references in the function body, which is clearly wrong for e.g. references to globals.  See below for notes on that.

Here's my test code::
    def function_to_be_inlined(x, y, z):
        return (2 * x * y) + z
    print(function_to_be_inlined(3, 4, 5))

Here's what it compiles to after going through the inliner (clearly, line numbering needs some work).  Note the removal of the CALL_FUNCTION of our target call site; the remaining CALL_FUNCTION is to "print":
  2           0 LOAD_CONST               0 (<code object function_to_be_inlined at 0x1e9b998, file "<dis>", line 2>) 
              3 MAKE_FUNCTION            0 
              6 STORE_NAME               0 (function_to_be_inlined) 

  4           9 LOAD_CONST               1 (3) 
             12 STORE_NAME               1 (__inline1f22840__x) 
             15 LOAD_CONST               2 (4) 
             18 STORE_NAME               2 (__inline1f22840__y) 
             21 LOAD_CONST               3 (5) 
             24 STORE_NAME               3 (__inline1f22840__z) 

259          27 LOAD_CONST               4 (2) 
             30 LOAD_NAME                1 (__inline1f22840__x) 
             33 BINARY_MULTIPLY      
             34 LOAD_NAME                2 (__inline1f22840__y) 
             37 BINARY_MULTIPLY      
             38 LOAD_NAME                3 (__inline1f22840__z) 
             41 BINARY_ADD           
             42 STORE_NAME               4 (__inline1f22840____returnval__) 

260          45 LOAD_NAME                5 (print) 
             48 LOAD_NAME                4 (__inline1f22840____returnval__) 
             51 CALL_FUNCTION            1 
             54 POP_TOP              
             55 LOAD_CONST               5 (None) 
             58 RETURN_VALUE         

The idea is that a further optimization pass would go through and ellide the unnecessary store-to-local/load-from-local instructions, followed by const folding, getting this down to:
   LOAD_CONST (<code object>)
   MAKE_FUNCTION
   STORE_NAME (function_to_be_inlined)
; inlined callsite:
   LOAD_NAME  (print)
   LOAD_CONST (29)
   CALL_FUNCTION 1


The biggest issue here is dealing with runtime differences between which function was inlined, and which function is being called, either via monkeypatching, or in method calls - we can inline intra-method calls within one class, but we have to cope with overriding of those methods in subclasses.

Thinking aloud of a way of solving this (this isn't implemented yet):
   add to AST:
     Specialize(expr name,
                stmt* specialized,
                stmt* generalized)

where you have some interpretation of name (e.g. "self.do_something"), and carry two different implementations.

  so that e.g.
  class Something:
     def foo(self, x, y, z):
           ... # some code
           self.bar(x, y, z)
           ... # more code
  the:
     Call(Attribute(Name(id='self'), id='bar'), args=[etc])
  becomes
     Specialize(name=Attribute(Name(id='self'), id='bar'),
                specialized=[inlined implementation of Something.bar for "self"],
                generalized=[Call(Attribute(Name(id='self'), id='bar'), args=[etc])])

Similarly, would need a new bytecode, say "JUMP_IF_SPECIALIZABLE"

      LOAD_NAME (self)
      GET_ATTR  ('bar')
  ; method self.bar is now on top of stack
      LOAD_CONST (<code object for the regular implementation of "bar">)
      JUMP_IF_SPECIALIZABLE -> label_inline_body
  ; Start of non-inlined call
      eval and push args
      CALL_FUNCTION
      JUMP_ABSOLUTE -> label_after
  ; ...end of non-inlined call; return value is top-of-stack

label_inline_body:
      eval args (potentially optimizing with knowledge of what's to come)
      inlined call
      push "return value"
  ; ...end of inlined call; "return value" is top-of-stack

label_after:     

   ; etc


JUMP_IF_SPECIALIZABLE
Inputs:
TOS    : A: code object we inlined for (via a LOAD_CONST, injected by the inliner)
TOS -1 : B: function object via runtime lookup (LOAD_GLOBAL, or e.g. LOAD_LOCAL "self"; GET_ATTR "do_something")

Action:
  if B's __code__ is A, we can specialize:
     PC += oparg
     POP
  else:
     PC += 1
     POP
     POP

I'm not sure if this covers all cases (e.g. specializing a CFunction such as the builtins), or if this a sane approach that actually works; need to have a standard interpretation of what a name lookup means, and to inject LOAD_CONST of that value into the bytecode, for use by the JUMP_IF_SPECIALIZABLE operation.

As I understand it, functions are "name-resolved" before the arguments are evaluated, so if argument evaluation leads to the name being bound to a different function (as a side effect), the status quo in CPython currently is that the old function is used for that call; JUMP_IF_SPECIALIZABLE would preserve that behavior.

It could also slightly slow down overridden method calls, as it would add a test for "am I overridden" that would generally take the "overridden" branch; perhaps we could detect classes with subclasses in the same AST and suppress inlining for this case.  Similarly, it could spot the
    def override_me(self):
         raise NotImplementedError
pattern and not try to inline.


Other issues:
  - Somehow need to tie together symbol tables with ast2mod.  One approach: do the symtable generation first, then adjust ast2mod so that it adds PySymtableEntry references to the generated python tree as appopriate.  This would expose the name scope structure.  But after the tree changes, do we need to regenerate the symbol table?  Or we could annotate the python ast.Name objects with scope information, and the ast optimizer would be responsible for keeping this correct.  The compiler could then rerun the symtable analysis on the returned AST, or could trust the optimizer's info.

  - What to do with the "locals()" builtin?  Inlined functions could save a copy of locals with duplicate names, keeping their existing names for the locals in the inlined copy.  This would lead to "locals()" having additional items when called from an inlined function.

  - Many optimizations would have to assume that locals don't change value.  Can we assume that in an optimized build that it's acceptable that code that use the inspect module and manipulates the f_locals of a frame may have surprising behavior in the face of optimization?  (e.g. I'd like to be able to optimize away locals if we can prove that absence of side-effects).

  - PyAST_obj2mod enforces checking for a particular top-level element.  To cope with this, I needed to pass this around in a few places, so I introduced "enum PyCompilationMode" to avoid having the magic 0, 1, or 2 to designate the grammar variant.  This better distinguishes these values from other places which use the ID of the start token: semantically equivalent, but with different constants.  I haven't yet fixed this up in Modules/parsermodule.c

  - Plenty of FIXMEs in the code, many of which are in themselves major issues
 
  - I'm not yet checking the optimization flag; that should probably be required to be on for this to be called.

  - Is "__optimizer__" a sane name?  perhaps just "optimizer"

  - Too unstable to benchmark as yet.

  - There are probably other issues I haven't thought of yet.

Notes:
  - the patch also contains a fix for issue 10391 (error handling is important when manipulating the AST)
  - potentially could add an optimize_cfg() hook, and expose the CFG struct basicblock and struct instr as Python objects in a similar way, as a later optimization pass
  
Thanks to Red Hat for giving me time to experiment on this

----------
components: Interpreter Core
files: py3k-ast-optimization-inlining-2010-11-12-001.patch
keywords: patch
messages: 121068
nosy: alex, belopolsky, benjamin.peterson, dmalcolm, jhylton, nnorwitz, rhettinger, sdahlbac, thomas.lee, titanstar
priority: normal
severity: normal
status: open
title: AST Optimization: inlining of function calls
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file19583/py3k-ast-optimization-inlining-2010-11-12-001.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:18:28 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 12 Nov 2010 20:18:28 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1289593108.27.0.162260584419.issue10399@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


Added file: http://bugs.python.org/file19584/before.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:18:58 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 12 Nov 2010 20:18:58 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1289593138.03.0.477564512105.issue10399@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


Added file: http://bugs.python.org/file19585/after.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:22:15 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 20:22:15 +0000
Subject: [issue10385] Mark up "subprocess" as module in its doc
In-Reply-To: <1289444045.02.0.247018067393.issue10385@psf.upfronthosting.co.za>
Message-ID: <1289593335.09.0.327017096802.issue10385@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>http://docs.python.org/dev/contents.html
The only thing I see there is the bold-facing of *PEP 3101*.
Is that what you are referring to?

In any case, with Georg's concurrence go ahead with this and any other modules you care about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10385>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:23:08 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Fri, 12 Nov 2010 20:23:08 +0000
Subject: [issue10400] updating unicodedata to Unicode 6
In-Reply-To: <1289593388.77.0.423367709943.issue10400@psf.upfronthosting.co.za>
Message-ID: <1289593388.77.0.423367709943.issue10400@psf.upfronthosting.co.za>


New submission from Vlastimil Brom <vlastimil.brom at gmail.com>:

I'd like to suggest updating the unicodedata module according to the recent Unicode standard 6.0
http://www.unicode.org/versions/Unicode6.0.0/
I'm sorry to bother, in case this is planned automatically, I just wasn't able to find the respective information.
Would it be possible to apply such update also for the upcomming python 2.7.1, or are there some showstoppers/incompatibilities... with regard to the new unicode version?
  regards,
      vbr

----------
components: Unicode
messages: 121070
nosy: vbr
priority: normal
severity: normal
status: open
title: updating unicodedata to Unicode 6
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10400>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:30:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 12 Nov 2010 20:30:06 +0000
Subject: [issue10400] updating unicodedata to Unicode 6
In-Reply-To: <1289593388.77.0.423367709943.issue10400@psf.upfronthosting.co.za>
Message-ID: <1289593806.22.0.914824707755.issue10400@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The database had been updated already in r85371. Backporting this change to maintenance branches is not allowed by policy.

----------
nosy: +loewis
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10400>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:35:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 20:35:44 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1289594144.83.0.527824547156.issue10252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ported to 3.1 and 2.7 in r86433 and r86434.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:43:41 2010
From: report at bugs.python.org (William Barr)
Date: Fri, 12 Nov 2010 20:43:41 +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: <1289594621.4.0.893416094439.issue10365@psf.upfronthosting.co.za>


William Barr <webmaster961 at gmail.com> added the comment:

Ok.  I'll see if I can get some protection around that then.  

I did test the issue with 2.7, and I didn't find it.  The window didn't open, but it didn't generate an exception that would kill the IDLE process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10365>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:49:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Nov 2010 20:49:39 +0000
Subject: [issue10397] Unified Benchmark Suite fails on py3k with --track-memory
In-Reply-To: <1289589711.2.0.279349979417.issue10397@psf.upfronthosting.co.za>
Message-ID: <1289594979.46.0.331662906682.issue10397@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Please note that some benchmarks are now natively py3k-compatible, you don't have to run make_perf3.sh.
Anyway, the patch is now pushed to http://hg.python.org/benchmarks/rev/7c7dc1c4d8d4, thank you!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10397>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:50:11 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:50:11 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1289595011.3.0.92184029357.issue1376292@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Not likely to be worked on, and whether to write such a guide is a question for the docs editor (or the Doc-SIG).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:55:46 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20: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: <1289595346.23.0.784059353604.issue2212@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2212>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:55:56 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:55:56 +0000
Subject: [issue2209] mailbox module doesn't support compressed mbox
In-Reply-To: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za>
Message-ID: <1289595356.99.0.359929261617.issue2209@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2209>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:56:07 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:56:07 +0000
Subject: [issue2657] Curses sometimes fails to initialize terminal
In-Reply-To: <1208559068.96.0.196247088071.issue2657@psf.upfronthosting.co.za>
Message-ID: <1289595367.7.0.632999348763.issue2657@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2657>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:57:22 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:57:22 +0000
Subject: [issue3786] _curses,
	_curses_panel & _multiprocessing can't be build in 2.6b3 w/ SunStudio
	12
In-Reply-To: <1220608521.1.0.66106932182.issue3786@psf.upfronthosting.co.za>
Message-ID: <1289595442.14.0.223372549467.issue3786@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3786>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:57:33 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:57:33 +0000
Subject: [issue1687125] cannot catch KeyboardInterrupt when using curses
	getkey()
Message-ID: <1289595453.98.0.302005638527.issue1687125@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1687125>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:57:57 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:57:57 +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: <1289595477.63.0.908121615038.issue5368@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5368>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:58:34 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:58:34 +0000
Subject: [issue4254] _cursesmodule.c callable update_lines_cols()
In-Reply-To: <1225724529.97.0.843166149521.issue4254@psf.upfronthosting.co.za>
Message-ID: <1289595514.59.0.037175960415.issue4254@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4254>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:59:07 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:59:07 +0000
Subject: [issue9557] test_mailbox failure under a Windows VM
In-Reply-To: <1281447971.09.0.314164589839.issue9557@psf.upfronthosting.co.za>
Message-ID: <1289595547.86.0.856779521709.issue9557@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9557>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:59:14 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:59:14 +0000
Subject: [issue1723038] Curses Menu
Message-ID: <1289595554.76.0.140210660724.issue1723038@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1723038>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:59:41 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:59:41 +0000
Subject: [issue1512163] mailbox (2.5b1): locking doesn't work (esp. on FreeBSD)
Message-ID: <1289595581.5.0.948337247239.issue1512163@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1512163>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:59:49 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:59:49 +0000
Subject: [issue1745108] 2.5.1 curses panel segfault in new_panel on aix 5.3
Message-ID: <1289595589.27.0.486778310995.issue1745108@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745108>
_______________________________________

From report at bugs.python.org  Fri Nov 12 21:59:58 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 20:59:58 +0000
Subject: [issue1671676] test_mailbox is hanging while doing gmake test on
	HP-UX v3
Message-ID: <1289595598.69.0.234946286203.issue1671676@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1671676>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:00:10 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 21:00:10 +0000
Subject: [issue1751519] curses - new window methods: addchstr and addchnstr
Message-ID: <1289595610.69.0.790567115994.issue1751519@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1751519>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:00:18 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 21:00:18 +0000
Subject: [issue1599254] mailbox: other programs' messages can vanish without
	trace
Message-ID: <1289595618.38.0.0874315027611.issue1599254@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1599254>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:00:53 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 21:00:53 +0000
Subject: [issue1488934] file.write + closed pipe = no error
Message-ID: <1289595653.91.0.324692143389.issue1488934@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1488934>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:01:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Nov 2010 21:01:46 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1289595706.38.0.682342517393.issue10399@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

<i>As I understand it, functions are "name-resolved" before the arguments are evaluated,</i>

There is no difference between resolution of function names and of other names. For example, global names (LOAD_GLOBAL) are resolved entirely at runtime (just before the function gets called).

The specialization issue means this would cooperate well with a globals cache (I've got a lingering patch for this, will post in a separate issue).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:02:21 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Fri, 12 Nov 2010 21:02:21 +0000
Subject: [issue10400] updating unicodedata to Unicode 6
In-Reply-To: <1289593388.77.0.423367709943.issue10400@psf.upfronthosting.co.za>
Message-ID: <1289595741.34.0.967106624881.issue10400@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Thanks for the clarification;
I obviously looked in an inappropriate branch before.
Sorry for the noise...
vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10400>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:02:45 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 12 Nov 2010 21:02:45 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1289595765.53.0.132697187285.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file19586/python-2.7-20101112-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:03:08 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 12 Nov 2010 21:03:08 +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: <1289595788.76.0.421873627813.issue3871@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file19587/python-2.7-20101112-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:03:19 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 21:03:19 +0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1289595799.44.0.649655848077.issue2124@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:03:50 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 21:03:50 +0000
Subject: [issue1028088] Cookies without values are silently ignored (by
	design?)
Message-ID: <1289595830.0.0.676541588258.issue1028088@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028088>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:03:57 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 12 Nov 2010 21:03:57 +0000
Subject: [issue3754] cross-compilation support for python build
In-Reply-To: <1220305759.82.0.468834426074.issue3754@psf.upfronthosting.co.za>
Message-ID: <1289595837.17.0.593855810255.issue3754@psf.upfronthosting.co.za>


Changes by Roumen Petrov <bugtrack at roumenpetrov.info>:


Added file: http://bugs.python.org/file19588/python-py3k-20101112-CROSS.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3754>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:04:04 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 21:04:04 +0000
Subject: [issue1483] xml.sax.saxutils.prepare_input_source ignores character
	stream in InputSource
In-Reply-To: <1195653795.8.0.542576278207.issue1483@psf.upfronthosting.co.za>
Message-ID: <1289595844.53.0.507777705231.issue1483@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1483>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:04:11 2010
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 12 Nov 2010 21:04:11 +0000
Subject: [issue1665333] Documentation missing for OptionGroup class in optparse
Message-ID: <1289595851.19.0.491657894265.issue1665333@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee: akuchling -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1665333>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:05:35 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Fri, 12 Nov 2010 21:05:35 +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: <1289595935.11.0.370484933074.issue3871@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

And the patch for py3k (future 3.2) . Note require python-py3k-20101112-CROSS.patch from issue 3754 to be applied first.

----------
Added file: http://bugs.python.org/file19589/python-py3k-20101112-MINGW.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:11:02 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 21:11:02 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1289596262.65.0.556940978924.issue2986@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

r86437 - correct and replicate version-added message

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:13:46 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 12 Nov 2010 21:13:46 +0000
Subject: [issue2657] Curses sometimes fails to initialize terminal
In-Reply-To: <1208559068.96.0.196247088071.issue2657@psf.upfronthosting.co.za>
Message-ID: <1289596426.07.0.915660570758.issue2657@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

That should be, for 2.7 or 3.2, as 3.1 is nearly finished.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2657>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:24:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Nov 2010 21:24:41 +0000
Subject: [issue10401] Globals / builtins cache
In-Reply-To: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>
Message-ID: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Here is the Nth patch for a globals/builtins cache. As other caches at the same kind, it shows very small to no gain on non-micro benchmarks, showing that contrary to popular belief, globals/builtins lookup are not a major roadblock in today's Python performance.

However, this patch could be useful in combination with other optimizations such as issue10399.  Indeed, using the globals/builtins version id, it is easy and very cheap to detect whether the function pointed to by a global name has changed or not.

As for micro-benchmarks, they show that there is indeed a good improvement on builtins lookups:

$ ./python -m timeit "x=len;x=len;x=len;x=len;x=len;x=len;x=len;x=len;x=len;x=len;"
-> without patch:
1000000 loops, best of 3: 0.282 usec per loop
-> with patch:
10000000 loops, best of 3: 0.183 usec per loop

----------
components: Interpreter Core
files: globcache5.patch
keywords: patch
messages: 121081
nosy: alex, belopolsky, benjamin.peterson, dmalcolm, jhylton, nnorwitz, pitrou, rhettinger, sdahlbac, thomas.lee, titanstar
priority: low
severity: normal
stage: patch review
status: open
title: Globals / builtins cache
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file19590/globcache5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10401>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:30:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Nov 2010 21:30:26 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1289597426.65.0.821834222994.issue10399@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Globals cache patch posted on issue10401.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Fri Nov 12 22:53:44 2010
From: report at bugs.python.org (Kirk Clendinning)
Date: Fri, 12 Nov 2010 21:53:44 +0000
Subject: [issue10373] Setup Script example incorrect
In-Reply-To: <1289582529.08.0.914212432047.issue10373@psf.upfronthosting.co.za>
Message-ID: <35DAEBAE-3158-48FF-9AAD-E0A04876634E@heliospectra.se>


Kirk Clendinning <kirk at heliospectra.se> added the comment:

Interesting... the link at the bottom of the page for reporting bugs went to the python bug tracker.. perhaps the web page should be checked for an incorrect link.

-k-

On Nov 12, 2010, at 18:22 , ?ric Araujo wrote:

> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Thanks for the report.  Setuptools is not a part of Python, and distutils docs don?t mention issues specific to third-party tools.  I think I will reject this bug.
> 
> ----------
> assignee: docs at python -> eric.araujo
> nosy: +eric.araujo
> status: open -> pending
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10373>
> _______________________________________

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10373>
_______________________________________

From report at bugs.python.org  Fri Nov 12 23:00:50 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 12 Nov 2010 22:00:50 +0000
Subject: [issue10373] Setup Script example incorrect
In-Reply-To: <1289308146.55.0.869173171863.issue10373@psf.upfronthosting.co.za>
Message-ID: <1289599250.09.0.723910410775.issue10373@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

> perhaps the web page should be checked for an incorrect link.

The link from the Python documentation to the Python bug tracker is fine.

If you were using distutils directly, it would be an issue for the Python tracker.

You're not.  setuptools is a separate project; you should refer to it's documentation and it's tracker.

----------
nosy: +fdrake
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10373>
_______________________________________

From report at bugs.python.org  Fri Nov 12 23:04:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 22:04:25 +0000
Subject: [issue10373] Setup Script example incorrect
In-Reply-To: <1289308146.55.0.869173171863.issue10373@psf.upfronthosting.co.za>
Message-ID: <1289599465.08.0.671716338048.issue10373@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: rejected -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10373>
_______________________________________

From report at bugs.python.org  Fri Nov 12 23:39:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 22:39:16 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1289601556.76.0.225071443565.issue10252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No file object was created for stdin, so my patch was buggy.  Fixed in r86438, r86439, r86440.  Thanks to Antoine and Brian.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Fri Nov 12 23:59:26 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 12 Nov 2010 22:59:26 +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: <1289602766.4.0.473835828527.issue3871@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I'm trying to read the patch. It contains many interesting things (and others I have no opinon about), but it is very large, and makes it difficult to comment or find why some change were made etc.

I do believe that better supporting the mingw32 platform is a worthy goal, but a single large patch, even after review, is something difficult to trust.

I suggest to present this work in another form. Maybe something like a Mercurial Patch Queue?  This would give us a collection of smaller patches, each with its own interest.  Each one can be discussed, modified, reviewed separately and by different people. Large easy tasks (like a massive rename) are distinct from small-but-hard changes. And when something is updated, the reviewers don't have to parse the whole file again; they just look at the recent patches.

As an example: among the many changes, you had to handle the Modules/getpath.c vs. PC/getpathp.c inconsistency.  You chose to have both filenames in the Makefile, but in my opinion it would be better to try to merge the files.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:09:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 12 Nov 2010 23:09:54 +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: <1289603394.7.0.318475259287.issue3871@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let?s try again.  The current situation is that building with mingw32 is not supported.  Adding support for mingw32 is by definition a new feature.  You seem to agree on that: ?a NEW compiler and linker type - an ADDITIONAL compiler and linker type?.

Second, distutils is frozen.  That?s the policy decided by Tarek, who?s spent literal months working on PEPs to move the situation forward.  It?s just not possible to fix things in distutils, so it?s frozen and new work happens in distutils2, at the suggestion of Python creator Guido van Rossum.  Please accept the feature freeze.

In conclusion, such pervasive changes will not happen in distutils.

----------
assignee:  -> tarek
components: +Distutils2
versions: +3rd party, Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:34:32 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Fri, 12 Nov 2010 23:34:32 +0000
Subject: [issue10284] NNTP should accept bytestrings for username and password
In-Reply-To: <1288642960.68.0.00972306001487.issue10284@psf.upfronthosting.co.za>
Message-ID: <1289604872.15.0.357130822508.issue10284@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

RFC 4616 about SASL PLAIN:

   The mechanism consists of a single message, a string of [UTF-8]
   encoded [Unicode] characters, from the client to the server.  The
   client presents the authorization identity (identity to act as),
   followed by a NUL (U+0000) character, followed by the authentication
   identity (identity whose password will be used), followed by a NUL
   (U+0000) character, followed by the clear-text password.  As with
   other SASL mechanisms, the client does not provide an authorization
   identity when it wishes the server to derive an identity from the
   credentials and use that as the authorization identity.
[...]
   The authorization identity (authzid), authentication identity
   (authcid), password (passwd), and NUL character deliminators SHALL be
   transferred as [UTF-8] encoded strings of [Unicode] characters.


That's one of the reasons why AUTHINFO SASL is better than AUTHINFO USER.  It also allows whitespaces (a few news servers do not parse well whitespaces in user names or passwords after AUTHINFO USER/PASS -- imagine " test" with a leading space).  Solved with SASL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10284>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:39:22 2010
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 12 Nov 2010 23:39:22 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1289605162.94.0.221305055633.issue3781@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

erik, i'm really sorry, but the freeze on distutils simply cannot be accepted: there really is no other way, as you can see from the previous walkthrough analysis, and is reinforced by the further analysis below.

simply put: if the freeze on distutils is not lifted, then this entire set of work, which has been going on for years and _precedes_ the distutils freeze by at least 18 months, is completely, utterly and totally wasted.

let's walk through the situation where distutils2 is forced to be used.

what you're asking for is, basically, that every single third party package, of which there must be tens of thousands, must be patched for compilation on mingw32... _just_ so that it says "if sys.platform == 'mingw32': from distutils2.core import setup else: from distutils.core import setup", is that correct?

does that strike you as being completely and utterly unreasonable an expectation, to ask third parties to modify setup.py scripts which have worked perfectly well for years, many of which are likely to no longer even have a maintainer?

that leaves patching - which should be nothing more than _adding_ to - not "changing existing compilers" - ADDING an extra compiler - distutils as the only option.

now, that can be done monkey-patch style (i.e. at runtime, by adding in code very early on in python startup, or perhaps by patching the import system to replace the word "distutils" with "distutilsmingw32") or it can be done... by lifting the distutils freeze.

perhaps i should ask: what _exactly_ is the problem, and why do several teams complete and utter failure to do the correct thing by making changes to _existing_ compile platforms have anything to do with _this_ team's patches which add a new totally separate platform that has absolutely nothing to do with any of the other platforms?

i could say more, but i believe the point is clear: none of the people involved in seeing mingw32 added as a platform had _anything_ to do with the past failures, so why "punish" and mis-trust the python-mingw32 for other peoples' failures?

----------
nosy: +lkcl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:41:06 2010
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 12 Nov 2010 23:41:06 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1289605266.18.0.604167356944.issue3781@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

NUTS.  many apologies: my comments should have gone to issue 3871 not 3781.  arse!  is it possible to delete comments? :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:41:54 2010
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 12 Nov 2010 23:41:54 +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: <1289605314.24.0.0110028173196.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

erik, i'm really sorry, but the freeze on distutils simply cannot be accepted: there really is no other way, as you can see from the previous walkthrough analysis, and is reinforced by the further analysis below.

simply put: if the freeze on distutils is not lifted, then this entire set of work, which has been going on for years and _precedes_ the distutils freeze by at least 18 months, is completely, utterly and totally wasted.

let's walk through the situation where distutils2 is forced to be used.

what you're asking for is, basically, that every single third party package, of which there must be tens of thousands, must be patched for compilation on mingw32... _just_ so that it says "if sys.platform == 'mingw32': from distutils2.core import setup else: from distutils.core import setup", is that correct?

does that strike you as being completely and utterly unreasonable an expectation, to ask third parties to modify setup.py scripts which have worked perfectly well for years, many of which are likely to no longer even have a maintainer?

that leaves patching - which should be nothing more than _adding_ to - not "changing existing compilers" - ADDING an extra compiler - distutils as the only option.

now, that can be done monkey-patch style (i.e. at runtime, by adding in code very early on in python startup, or perhaps by patching the import system to replace the word "distutils" with "distutilsmingw32") or it can be done... by lifting the distutils freeze.

perhaps i should ask: what _exactly_ is the problem, and why do several teams complete and utter failure to do the correct thing by making changes to _existing_ compile platforms have anything to do with _this_ team's patches which add a new totally separate platform that has absolutely nothing to do with any of the other platforms?

i could say more, but i believe the point is clear: none of the people involved in seeing mingw32 added as a platform had _anything_ to do with the past failures, so why "punish" and mis-trust the python-mingw32 for other peoples' failures?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:44:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Nov 2010 23:44:10 +0000
Subject: [issue10351] Add autocompletion for keys in dictionaries
In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>
Message-ID: <1289605450.47.0.890839932015.issue10351@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/issue10351>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:44:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 12 Nov 2010 23:44:25 +0000
Subject: [issue10284] NNTP should accept bytestrings for username and password
In-Reply-To: <1289604872.15.0.357130822508.issue10284@psf.upfronthosting.co.za>
Message-ID: <1289605456.3525.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello Julien,

> That's one of the reasons why AUTHINFO SASL is better than AUTHINFO
> USER.  It also allows whitespaces (a few news servers do not parse
> well whitespaces in user names or passwords after AUTHINFO USER/PASS
> -- imagine " test" with a leading space).  Solved with SASL.

If you want to contribute SASL auth for NNTP, it might make sense to
have a dedicated module to provide SASL mechanisms (and then let imaplib
reuse that module). Of course, not all mechanisms need to be provided at
the start.

(FWIW, I had written a patch providing generic SASL support for Twisted
years ago: http://twistedmatrix.com/trac/ticket/2015 )

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10284>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:50:26 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Nov 2010 23:50:26 +0000
Subject: [issue10385] Mark up "subprocess" as module in its doc
In-Reply-To: <1289444045.02.0.247018067393.issue10385@psf.upfronthosting.co.za>
Message-ID: <1289605826.53.0.811046848136.issue10385@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think that using e.g. :mod:`subprocess` in the subprocess page is redundant because there's no need to add a link to the page you are already reading. I'm also not sure that it looks too nice in the headers (iirc the font is different), but I haven't tried to apply the patch and see how it looks.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10385>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:51:31 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 12 Nov 2010 23:51:31 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1289605891.44.0.65538805089.issue3871@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

We don't punish anyone here. We try to avoid breaking distutils because it's really easy to get broken and get people upset. (you ask me)

This bug has been opened for years and no one commited it because it's very very hard to review. it involves many parts, many people.

I am not sure how we should do this, but here's my proposal for distutils2 at least:

- make this new feature a standalone package that patches distutils
- release it for 2.x
- let's add your work in distutils2 as well, so it's back in the stdlib in 3.x

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:52:29 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Nov 2010 23:52:29 +0000
Subject: [issue10384] SyntaxError should contain exact location of the invalid
	character in identifier
In-Reply-To: <1289439285.11.0.506002899946.issue10384@psf.upfronthosting.co.za>
Message-ID: <1289605949.76.0.0804417333624.issue10384@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/issue10384>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:53:31 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 12 Nov 2010 23:53:31 +0000
Subject: [issue10395] os.path.commonprefix broken by design
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1289606011.37.0.33750960507.issue10395@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/issue10395>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:55:31 2010
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Fri, 12 Nov 2010 23:55:31 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1221433699.47.0.0165458312451.issue3871@psf.upfronthosting.co.za>
Message-ID: <1289606131.06.0.264231340532.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

> I'm trying to read the patch. It contains many interesting things (and 
> others I have no opinon about), but it is very large, and makes it
> difficult to comment or find why some change were made etc.

amaury: unfortunately, the development on adding mingw32 as a platform has been ongoing for well over three years, with absolute silence and rejection of its existence.  it was only when a fourth person showed interest in it (LRN) that it became "accepted" - but that was... only two months ago!

basically, this situation should never have been allowed to get this
far: the very first patch that was created, three nearly four years ago, should have been accepted, and then an incremental process could have been taken, _and_ the silly situation in which distutils gets frozen during the time when people have been completely ignoring this ongoing work would never have occurred.

but, that's the situation: the bed has been made, and now developers have to lie in it.  sorry to be the one that's pointing this out, but...

anyway.

your idea to split this into a series has merit: personally i much prefer git, because of git-format-patch, but i have to say i've never done "patch regeneration" based on a "review / change-patch-in-middle-of-series / regenerate git-format-patch" cycle.  should be fun! :)

but the very very first thing that has to happen - before any of this work is begun - is for the distutils freeze to be lifted, or for someone to come up with a _sensible_ alternative solution.

if that cannot be done, then roumen and LRN won't _stop_ working on python-mingw32: the end result will be that they just... continue to create a single patch file that will just get larger and larger.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Nov 13 00:59:49 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 12 Nov 2010 23:59:49 +0000
Subject: [issue10401] Globals / builtins cache
In-Reply-To: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>
Message-ID: <1289606389.9.0.573110675561.issue10401@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/issue10401>
_______________________________________

From report at bugs.python.org  Sat Nov 13 01:02:45 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Sat, 13 Nov 2010 00:02:45 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1289606565.9.0.191900990967.issue10070@psf.upfronthosting.co.za>


Bobby Impollonia <bobbyi at gmail.com> added the comment:

> Can you please post an example Python module that has this markup you are asking for, so I can show you how to achieve what you want without the markup?

Hi, Martin. Here's a real-world example:
http://www.sqlalchemy.org/trac/browser/lib/sqlalchemy/types.py?rev=6884:b181f1e53603

The syntax is:
# Py3K
# <python 3 code>
# Py2K
<python 2 code>
# end Py2K

For example, starting on line 152 we have,
        # Py3K
        #return unicode(self.compile())
        # Py2K
        return unicode(self.compile()).\
                        encode('ascii', 'backslashreplace')
        # end Py2K

When the code is converted with 2to3, the py3k code on line 153 will be uncommented and used to replace the py2k code on lines 155-156. Having the py3k version commented before conversion resolves the issue that "you must not use syntax that is exclusively Python 3 in an if-python3 block".

Here is their modified version of 2to3 to support this syntax:
http://www.sqlalchemy.org/trac/browser/sa2to3.py

Their explanation is:
"This tool monkeypatches a preprocessor onto lib2to3.refactor.RefactoringTool, so that conditional sections can replace non-fixable Python 2 code sections for the appropriate Python 3 version before 2to3 is run."

----------
nosy: +bobbyi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Sat Nov 13 01:03:10 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 13 Nov 2010 00:03:10 +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: <1289606590.01.0.841766637827.issue3871@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I understand your frustration, but I can't lift the freeze because any change to distutils potentially break third party projects out there. We suffered from that in the past and we decided to proceed on a new version and freeze this one.

Having this compiler released on its own project is absolutely possible and acceptable and can be done in a way that works with distutils1 and distutils2, and I'd happily integrate it to distutils2 today once we manage to review it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Nov 13 01:14:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Nov 2010 00:14:57 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1289607297.41.0.660935015738.issue3781@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg121089

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sat Nov 13 01:15:08 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Nov 2010 00:15:08 +0000
Subject: [issue3781] warnings.catch_warnings fails gracelessly when recording
	warnings but no warnings are emitted
In-Reply-To: <1220566209.35.0.614126643007.issue3781@psf.upfronthosting.co.za>
Message-ID: <1289607308.54.0.374026607981.issue3781@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg121090

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3781>
_______________________________________

From report at bugs.python.org  Sat Nov 13 01:17:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 13 Nov 2010 00:17:15 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1289606565.9.0.191900990967.issue10070@psf.upfronthosting.co.za>
Message-ID: <4CDDD907.4030906@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> For example, starting on line 152 we have,
>         # Py3K
>         #return unicode(self.compile())
>         # Py2K
>         return unicode(self.compile()).\
>                         encode('ascii', 'backslashreplace')
>         # end Py2K

Ok, I can propose two different spellings of this without any
macro processor:

A. conditionally encode for 2.x

   def __str__(self):
       res = unicode(self.compile())
       if sys.version_info < (3,):
           res = res.encode('ascii', 'backslashreplace')
       return res

B. (if A is deemed to incur too much per-call cost, due to
   the version test)

   if sys.version_info >= (3,):
       def __str__(self):
           return unicode(self.compile())
   else:
       def __str__(self):
           return unicode(self.compile()). \
                  encode('ascii', 'backslashreplace')

In addition, I fail to see how the markup hfuru proposed can be
used to express this case. IIUC, he asks for markup that can tell
2to3 to leave a certain piece of code alone, i.e. unmodified. I
fail to see how this would help in this sqlalchemy example.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Sat Nov 13 01:19:16 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 13 Nov 2010 00:19:16 +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: <1289607556.71.0.79118963899.issue3871@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> but the very very first thing that has to happen - before any of this
> work is begun - is for the distutils freeze to be lifted, or for 
> someone to come up with a _sensible_ alternative solution.

Tarek's approach looks right to me: mingw32 support in distutils should take the form of an external module that subclasses (when possible) or monkeypatches (on last resort) the standard distutils behavior.

The current patch makes too many changes in core distutils functions; it cannot be accepted in this form.  I'm sure that most of the needed changes can be made in a subclass of the present Mingw32CCompiler.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Nov 13 01:51:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 00:51:37 +0000
Subject: [issue10402] sporadic test_bsddb3 failures
In-Reply-To: <1289609497.28.0.489511317462.issue10402@psf.upfronthosting.co.za>
Message-ID: <1289609497.28.0.489511317462.issue10402@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

test_bsddb3 often produces the following failure under the Windows buildbots. It could probably be solved by choosing a larger timeout (time.time() on Windows is rather imprecise):

test test_bsddb3 failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\2.7.bolen-windows7\build\lib\bsddb\test\test_lock.py", line 139, in test04_lock_timeout2
    self.assertTrue((end_time-start_time) >= 0.0999)
AssertionError: False is not True

----------
assignee: jcea
components: Library (Lib), Tests
keywords: buildbot
messages: 121100
nosy: jcea, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: sporadic test_bsddb3 failures
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10402>
_______________________________________

From report at bugs.python.org  Sat Nov 13 02:18:08 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Nov 2010 01:18:08 +0000
Subject: [issue10377] cProfile incorrectly labels its output
In-Reply-To: <1289330157.64.0.804847448743.issue10377@psf.upfronthosting.co.za>
Message-ID: <20101113011756.GA1313@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Tue, Nov 09, 2010 at 07:15:57PM +0000, Jean-Paul Calderone wrote:
> >>> cProfile.run("import time; time.sleep(1)")
>          4 function calls in 1.012 CPU seconds
> 
> It is not the case that the profiled code uses >1 CPU seconds.  It
> spends the entire time sleeping.  The default timer for cProfile is
> a wallclock timer.  The output should reflect this.

So, It should just be 1.012 seconds, instead of 1.012 CPU seconds. Correct?
Or is there any other technically more accurate way to say?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10377>
_______________________________________

From orsenthil at gmail.com  Sat Nov 13 02:17:56 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Sat, 13 Nov 2010 09:17:56 +0800
Subject: [issue10377] cProfile incorrectly labels its output
Message-ID: <20101113011756.GA1313@rubuntu>

On Tue, Nov 09, 2010 at 07:15:57PM +0000, Jean-Paul Calderone wrote:
> >>> cProfile.run("import time; time.sleep(1)")
>          4 function calls in 1.012 CPU seconds
> 
> It is not the case that the profiled code uses >1 CPU seconds.  It
> spends the entire time sleeping.  The default timer for cProfile is
> a wallclock timer.  The output should reflect this.

So, It should just be 1.012 seconds, instead of 1.012 CPU seconds. Correct?
Or is there any other technically more accurate way to say?

From report at bugs.python.org  Sat Nov 13 02:18:21 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Nov 2010 01:18:21 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <20101113011812.GB1313@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Fri, Nov 12, 2010 at 12:35:49AM +0000, ?ukasz Langa wrote:
> This is unfortunately a backwards compatibility concern. Originally
> it wasn't made so that set() converts to string or accepts only
> strings and when the developers realized this mistake, it was too
> late (there were programs using this misfeature). That's one of the

Where would coercing to str() for set methods result in failures or
backward compatibility problems? I think get() methods always return
strings.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From orsenthil at gmail.com  Sat Nov 13 02:18:12 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Sat, 13 Nov 2010 09:18:12 +0800
Subject: [issue10387] ConfigParser's getboolean method is broken
Message-ID: <20101113011812.GB1313@rubuntu>

On Fri, Nov 12, 2010 at 12:35:49AM +0000, ?ukasz Langa wrote:
> This is unfortunately a backwards compatibility concern. Originally
> it wasn't made so that set() converts to string or accepts only
> strings and when the developers realized this mistake, it was too
> late (there were programs using this misfeature). That's one of the

Where would coercing to str() for set methods result in failures or
backward compatibility problems? I think get() methods always return
strings.

From report at bugs.python.org  Sat Nov 13 02:20:45 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 13 Nov 2010 01:20:45 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289477184.84.0.648837356177.issue10387@psf.upfronthosting.co.za>
Message-ID: <1289611245.62.0.317083076863.issue10387@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

You think wrong. Try it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Sat Nov 13 02:28:54 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Sat, 13 Nov 2010 01:28:54 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1289611734.06.0.674944392154.issue10070@psf.upfronthosting.co.za>


Bobby Impollonia <bobbyi at gmail.com> added the comment:

Consider here:
http://www.sqlalchemy.org/trac/browser/lib/sqlalchemy/engine/base.py?rev=6884:b181f1e53603#L1329
the py3k code uses the "raise ... from" syntax which isn't legal in Python 2. Using either  "Approach A" or "Approach B" would prevent the program from working in py2k due to syntax errors.

I agree that the markup hrufu proposed didn't solve that problem either. SQLA's trick of having the py3k code commented out is the critical part that they add.

Additionally, the runtime cost prevents Approach A from being general solution for libraries like SQLA who have put a lot of work into reducing the number of function calls and checks in their critical paths.

Approach B isn't a general solution because it requires you to replace entire functions at a time. If you have a 25 line function where only 1 line needs to be changed for py3k, you either end up with 24 duplicated lines of code, or you have to factor that single line out into its own function, confusing the flow of the code and incurring runtime cost.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Sat Nov 13 02:56:15 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 13 Nov 2010 01:56:15 +0000
Subject: [issue10401] Globals / builtins cache
In-Reply-To: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>
Message-ID: <1289613375.16.0.796942466004.issue10401@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Might such a cache lay the groundwork for more aggressive optimizations
by JITs like Unladen Swallow?

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10401>
_______________________________________

From report at bugs.python.org  Sat Nov 13 04:12:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Nov 2010 03:12:41 +0000
Subject: [issue10395] new os.path function to extract common prefix based on
	path components
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1289617961.86.0.393136955962.issue10395@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Indeed, as I remember it there are people using commonprefix as a string function in situations having nothing to do with os paths.

I'm changing the title to reflect the fact that this is really a feature request for a new function.  IMO it is a reasonable feature request.  Finding a name for it ought to be an interesting exercise.

I think that this should only be accepted if there is also a windows implementation.

----------
nosy: +r.david.murray
stage:  -> needs patch
title: os.path.commonprefix broken by design -> new os.path function to extract common prefix based on path components
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10395>
_______________________________________

From report at bugs.python.org  Sat Nov 13 04:24:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Nov 2010 03:24:27 +0000
Subject: [issue10392] GZipFile crash when fileobj.mode is None
In-Reply-To: <1289541524.38.0.073026896043.issue10392@psf.upfronthosting.co.za>
Message-ID: <1289618667.28.0.265413497029.issue10392@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Why do you consider this a bug in GZipFile rather than a bug in Django?  GZipFile is already careful to consider mode only when it is defined as an attribute.  It seems to me that if it is defined, it should be meaningful.

----------
nosy: +pitrou, r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> pending
type: crash -> behavior
versions:  -Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10392>
_______________________________________

From report at bugs.python.org  Sat Nov 13 04:50:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Nov 2010 03:50:22 +0000
Subject: [issue8332] regrtest single TestClass/test_method
In-Reply-To: <1270631958.05.0.652340331128.issue8332@psf.upfronthosting.co.za>
Message-ID: <1289620222.25.0.806301385469.issue8332@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm -1 on your second case.  That syntax is too magical, especially since a test method can appear on more than one test case.  

The additional pattern matching suggestion is more interesting, but it would be necessary to implement that in unittest, since test classes and methods can be created on the fly. I suggest opening a new issue against unittest to extend pattern matching to test case and test method names if you think that feature is valuable enough to add.

I agree with Sandro, I think the valid part of this request is satisfied by the unittest CLI.  It is true that more work needs to be done before all Python tests can be run successfully in this fashion, since some depend on regrtest features.  But making those fixes (moving useful regrtest features to unittest and eliminating the non-useful regrtest dependencies) is a better investment of resources than adding run-single-test support directly to regrtest, IMO.

If you want to submit a patch for first case, though, feel free to reopen this.  I doubt we'd reject it if you want to do the work.

----------
nosy: +r.david.murray
resolution: fixed -> works for me
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8332>
_______________________________________

From report at bugs.python.org  Sat Nov 13 05:22:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Nov 2010 04:22:18 +0000
Subject: [issue10396] stdin argument to pdb.Pdb doesn't work unless you also
	set Pdb.use_rawinput = False
In-Reply-To: <1289584221.71.0.586527779083.issue10396@psf.upfronthosting.co.za>
Message-ID: <1289622138.26.0.876423648405.issue10396@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of issue 2571.  If after reading that discussion you have ideas about and interest in working on the feature request as suggested, you may either comment on that one or open a new feature request, whichever seems clearer to you.

Note that the pdb docs direct you the cmd docs, which clearly document the need to set use_rawinput, so this is not even a doc bug.

----------
nosy: +r.david.murray
resolution:  -> duplicate
stage:  -> committed/rejected
superseder:  -> cmd.py always uses raw_input, even when another stdin is specified

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10396>
_______________________________________

From report at bugs.python.org  Sat Nov 13 05:37:22 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 13 Nov 2010 04:37:22 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>


New submission from Fred L. Drake, Jr. <fdrake at acm.org>:

Some portions of the documentation are using the term "member" to mean "data attribute".  This appears to be an aberration at this time, but occurrences should be identified and corrected, and "Documenting Python" updated to note correct usage.

Example use:

http://docs.python.org/dev/py3k/library/xmlrpc.client.html#fault-objects

http://docs.python.org/dev/py3k/library/urllib.request.html#basehandler-objects
(paragraph starting "The following members and methods should")

"Members and methods" should just be "attributes".

----------
assignee: docs at python
components: Documentation
messages: 121110
nosy: docs at python, fdrake
priority: normal
severity: normal
status: open
title: Use "member" consistently

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Sat Nov 13 05:37:52 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sat, 13 Nov 2010 04:37:52 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1289623072.04.0.306829376162.issue10403@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Sat Nov 13 05:54:55 2010
From: report at bugs.python.org (Brad Greenlee)
Date: Sat, 13 Nov 2010 04:54:55 +0000
Subject: [issue10392] GZipFile crash when fileobj.mode is None
In-Reply-To: <1289541524.38.0.073026896043.issue10392@psf.upfronthosting.co.za>
Message-ID: <1289624095.5.0.411066207834.issue10392@psf.upfronthosting.co.za>


Brad Greenlee <brad at footle.org> added the comment:

GzipFile.__init__ considers mode == None to be the equivalent of undefined, and sets it to the default of 'rb'. I see fileobj.mode == None as the same thing.

That said, it is probably a bug in Django as well; I'll look into that. I still think that GzipFile should handle this gracefully.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10392>
_______________________________________

From report at bugs.python.org  Sat Nov 13 06:00:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Nov 2010 05:00:08 +0000
Subject: [issue10392] GZipFile crash when fileobj.mode is None
In-Reply-To: <1289541524.38.0.073026896043.issue10392@psf.upfronthosting.co.za>
Message-ID: <1289624408.59.0.292883495746.issue10392@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, the __init__ argument default value is the standard way of indicating "this argument was not specified".  It is not in any way a value for 'mode'.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10392>
_______________________________________

From report at bugs.python.org  Sat Nov 13 06:11:15 2010
From: report at bugs.python.org (Brad Greenlee)
Date: Sat, 13 Nov 2010 05:11:15 +0000
Subject: [issue10392] GZipFile crash when fileobj.mode is None
In-Reply-To: <1289541524.38.0.073026896043.issue10392@psf.upfronthosting.co.za>
Message-ID: <1289625075.59.0.02591690802.issue10392@psf.upfronthosting.co.za>


Brad Greenlee <brad at footle.org> added the comment:

Yes, but if I actually passed mode=None in, the behavior would be the same, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10392>
_______________________________________

From report at bugs.python.org  Sat Nov 13 06:39:29 2010
From: report at bugs.python.org (Alex)
Date: Sat, 13 Nov 2010 05:39:29 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1289626769.03.0.540415476979.issue10399@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Just a thought: it's possible to cover all the cases properly with inlining (locals, globals (even with cross module inlining), tracebacks, sys._getframe(), etc.), however I think you're going to find that manually managing all of those is going to quickly drive you up a tree if you want to also get meaningful speedups (from removing frame allocation, argument parsing, etc.).

My 2?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Sat Nov 13 06:51:15 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sat, 13 Nov 2010 05:51:15 +0000
Subject: [issue10366] Remove unneeded '(object)' from 3.x class examples
In-Reply-To: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>
Message-ID: <1289627475.66.0.857852085705.issue10366@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Attached a patch to implement the suggested changes on 3.2. If the patch is ok I can do the same for 3.1.

----------
keywords: +patch
nosy: +xuanji
Added file: http://bugs.python.org/file19591/issue10366_remove_unneeded_object_py3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10366>
_______________________________________

From report at bugs.python.org  Sat Nov 13 07:33:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Nov 2010 06:33:07 +0000
Subject: [issue8746] os.chflags() and os.lchflags() are not built when they
	should be be
In-Reply-To: <1274173521.53.0.771933425772.issue8746@psf.upfronthosting.co.za>
Message-ID: <1289629987.33.0.588035011214.issue8746@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Same for a4.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sat Nov 13 07:53:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 13 Nov 2010 06:53:13 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1289611734.06.0.674944392154.issue10070@psf.upfronthosting.co.za>
Message-ID: <4CDE35D6.6020103@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Consider here:
> http://www.sqlalchemy.org/trac/browser/lib/sqlalchemy/engine/base.py?rev=6884:b181f1e53603#L1329
> the py3k code uses the "raise ... from" syntax which isn't legal in Python 2. 

In this case, I would write

   error = exc.DBAPIError.instance(statement,
                            parameters,
                            e,
                            connection_invalidated=is_disconnect)
   if sys.version_info < (3,):
       raise error, None, sys.exc_info()[2]
   else:
       error.__cause__ = e
       raise error

You don't *have* to use the from syntax to set the cause.

> Approach B isn't a general solution because it requires you to replace entire functions at a time. 

I don't claim that. However, I claim that there will be always an
appropriate solution using existing techniques, so that such a macro
processing wouldn't be necessary. IOW, I'm not aware of a case where
using such preprocessing would be appropriate and better than what
you can do without.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Sat Nov 13 07:58:00 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Nov 2010 06:58:00 +0000
Subject: [issue10396] stdin argument to pdb.Pdb doesn't work unless you also
	set Pdb.use_rawinput = False
In-Reply-To: <1289584221.71.0.586527779083.issue10396@psf.upfronthosting.co.za>
Message-ID: <1289631480.35.0.904504028068.issue10396@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10396>
_______________________________________

From report at bugs.python.org  Sat Nov 13 07:59:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Nov 2010 06:59:25 +0000
Subject: [issue10401] Globals / builtins cache
In-Reply-To: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>
Message-ID: <1289631565.41.0.307832722325.issue10401@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/issue10401>
_______________________________________

From report at bugs.python.org  Sat Nov 13 09:39:23 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Nov 2010 08:39:23 +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: <1289637563.28.0.230524563263.issue10404@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

In several contexts, IDLE binds clicking of the right mouse button to context popup menus, most importantly, to provide the Set Breakpoint and Clear Breakpoint actions in edit windows.  On OS X systems, however, one cannot assume there will be more than one (e.g. the left) mouse button.  Further, Aqua Tk, the default on OS X, binds a right button if present to <Button-2>, rather than <Button-3> as with other Tk implementations and ignores <Button-3> bindings.  The net effect is that there is currently no way to use IDLE's breakpoint facility with Aqua Tk, with or without a multi-button mouse.

----------
assignee: ronaldoussoren
components: IDLE, Macintosh
messages: 121118
nosy: ned.deily, ronaldoussoren
priority: critical
severity: normal
stage: patch review
status: open
title: IDLE on OS X popup menus do not work: cannot set/clear breakpoints
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Sat Nov 13 09:43:23 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Nov 2010 08:43:23 +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: <1289637803.59.0.533197606881.issue10404@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The attached patch modifies IDLE on OS X to bind popup menus to Control-Click (of the main or "left" button), as is commonly done elsewhere in OS X.

----------
Added file: http://bugs.python.org/file19592/issue10404-idle_no_context_menus.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Sat Nov 13 09:45:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 13 Nov 2010 08:45:01 +0000
Subject: [issue10392] GZipFile crash when fileobj.mode is None
In-Reply-To: <1289541524.38.0.073026896043.issue10392@psf.upfronthosting.co.za>
Message-ID: <1289637901.44.0.302454062577.issue10392@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes.  However, if None were a valid value for mode, then the would would instead do something like:

SENTINEL = object()

class GZipFile...

    def __init__(self, filename=None, mode=SENTINEL, ...

and then where None currently appears in the logic of the method, mode would be checked against SENTINEL to see if no value had been passed to the mode argument.

Thus the presence of None in the __init__ signature actually indicates that None is explicitly *not* a valid value for mode (and thus can safely be used as a sentinel value).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10392>
_______________________________________

From report at bugs.python.org  Sat Nov 13 09:54:34 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Nov 2010 08:54:34 +0000
Subject: [issue10405] IDLE breakpoint facility undocumented
In-Reply-To: <1289638474.62.0.690259510388.issue10405@psf.upfronthosting.co.za>
Message-ID: <1289638474.62.0.690259510388.issue10405@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

In neither the IDLE section of the Library Reference nor in IDLE's own help file is there any documentation on how to use its breakpoint capability.  Since the menu options only appear if the user knows to Right-click (or Control-click on OS X - see issue10404), it would be easy for a user to never realize that the breakpoint capability exists.

----------
assignee: docs at python
components: Documentation, IDLE
messages: 121121
nosy: docs at python, kbk, ned.deily, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: IDLE breakpoint facility undocumented
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10405>
_______________________________________

From report at bugs.python.org  Sat Nov 13 09:55:31 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Nov 2010 08:55:31 +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: <1289638531.69.0.881424486959.issue10404@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +Bruce.Sherwood, kbk, taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Sat Nov 13 10:01:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Nov 2010 09:01:02 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1289638862.43.0.825485837238.issue10356@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay; go ahead and apply (preferably in two separate commits, since you're fixing two only marginally related issues here).

----------
assignee:  -> skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Sat Nov 13 10:26:42 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Nov 2010 09:26:42 +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: <1289640402.26.0.448285710534.issue10406@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

r73001 for Issue5150 added the Rstrip extension to IDLE and modified the extensions configuration file, config-extensions.def, to enable it by default.  For Python 2 OS X installs, however, the config-extensions.def file from Lib/idlelib is replaced by a tailored one from Mac/IDLE and the changes for Issue5101 are lost.  The attached patch updates the Mac/IDLE version appropriately.  Note, for Python 3 installs, this is not a problem as there is no longer a separate Mac-only copy of the file.

----------
assignee: ronaldoussoren
components: IDLE, Macintosh
messages: 121123
nosy: Bruce.Sherwood, kbk, ned.deily, ronaldoussoren, taleinat
priority: normal
severity: normal
stage: patch review
status: open
title: IDLE 2.7 on OS X does not enable Rstrip extension by default
type: performance
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10406>
_______________________________________

From report at bugs.python.org  Sat Nov 13 10:29:22 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 13 Nov 2010 09:29:22 +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: <1289640562.13.0.500340332429.issue10406@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file19593/issue10406-idle27-rstrip-27.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10406>
_______________________________________

From report at bugs.python.org  Sat Nov 13 10:31:21 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Nov 2010 09:31:21 +0000
Subject: [issue10205] Can't have two tags with the same QName
In-Reply-To: <1288122049.66.0.916624044666.issue10205@psf.upfronthosting.co.za>
Message-ID: <1289640681.12.0.664388777212.issue10205@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thanks for the explanation, ?ric. That helps.
- Backported QName tests in r86447 to release31-maint.

As for the logic of the fix, it follows like this:

If True and False:
  #Doesn't go here
elif True:
  # Goes here

vs

if True:
   # Goes here
   if False:
      # Does not matter
elif:
   # Doesn't go here.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10205>
_______________________________________

From report at bugs.python.org  Sat Nov 13 10:54:35 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 13 Nov 2010 09:54:35 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1289642075.92.0.749866037522.issue10141@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch looks good at first glance, but is there a way to test the feature?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Sat Nov 13 11:29:39 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 13 Nov 2010 10:29:39 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>
Message-ID: <1289644179.94.0.488772230649.issue10260@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ok, here is a new patch which slightly expands the documentation and improves the timeout unittest.
If there are no objections I'll then commit this shortly.

----------
Added file: http://bugs.python.org/file19594/wait_for2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10260>
_______________________________________

From report at bugs.python.org  Sat Nov 13 11:31:01 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 13 Nov 2010 10:31:01 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1289644261.92.0.937903883568.issue10356@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

The Fraction type has the same behaviour, so I've fixed it to match the proposed new Decimal behaviour in r86448.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Sat Nov 13 11:38:25 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Nov 2010 10:38:25 +0000
Subject: [issue10387] ConfigParser's getboolean method is broken
In-Reply-To: <1289611245.62.0.317083076863.issue10387@psf.upfronthosting.co.za>
Message-ID: <20101113103810.GA1026@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sat, Nov 13, 2010 at 01:20:45AM +0000, ?ukasz Langa wrote:
> You think wrong. Try it.

Okay, I get it. Coercing would be a bad idea in RawConfigParser
because there are cases where get method can have raw=True and
coercing would break those behaviors.

The way the OP expressed it, it looked like a bug to me.
Here is one way, the OP's concern can be resolved.

Index: Lib/configparser.py
===================================================================
--- Lib/configparser.py (revision 86441)
+++ Lib/configparser.py (working copy)
@@ -892,6 +892,8 @@
         """
         if value.lower() not in self.BOOLEAN_STATES:
             raise ValueError('Not a boolean: %s' % value)
+        if str(value) in self.BOOLEAN_STATES:
+            return self.BOOLEAN_STATES[str(value)]
         return self.BOOLEAN_STATES[value.lower()]

     def _validate_value_type(self, value):

But this seems specific to the special case as this bug is raised for.
I am personally, +0 for this too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10387>
_______________________________________

From report at bugs.python.org  Sat Nov 13 11:40:00 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 13 Nov 2010 10:40:00 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>
Message-ID: <1289644800.73.0.00989518646049.issue10260@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Good, but please wait until after the a4 freeze.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10260>
_______________________________________

From report at bugs.python.org  Sat Nov 13 13:04:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 12:04:58 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1289644179.94.0.488772230649.issue10260@psf.upfronthosting.co.za>
Message-ID: <1289649892.3572.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Ok, here is a new patch which slightly expands the documentation and improves the timeout unittest.
> If there are no objections I'll then commit this shortly.

Again, I think you should use a larger timeout value than 0.1, to avoid
intermittent buildbot failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10260>
_______________________________________

From report at bugs.python.org  Sat Nov 13 13:25:48 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Nov 2010 12:25:48 +0000
Subject: [issue1520831] urrlib2 max_redirections=0 disables redirects
Message-ID: <1289651148.87.0.93352217493.issue1520831@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

This is an invalid bug report at the moment. In fact, aged.
The redirection depends upon max_redirections and max_repeats together. Setting it to 0 explicitly (inside the code) is not a good use case under any condition.

----------
nosy:  -BreamoreBoy
resolution:  -> wont fix
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1520831>
_______________________________________

From report at bugs.python.org  Sat Nov 13 13:28:48 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Nov 2010 12:28:48 +0000
Subject: [issue5111] httplib: wrong Host header when connecting to IPv6
	litteral URL
In-Reply-To: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>
Message-ID: <1289651328.17.0.382013206833.issue5111@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r86450 (py3k). Will be back porting shortly.

----------
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5111>
_______________________________________

From report at bugs.python.org  Sat Nov 13 13:34:59 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 13 Nov 2010 12:34:59 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1289651699.86.0.561094378663.issue10116@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Sat Nov 13 14:04:49 2010
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 13 Nov 2010 13:04:49 +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: <1289653489.93.0.489089255367.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

> I am not sure how we should do this, but here's my proposal
> for distutils2 at least:

> - make this new feature a standalone package that patches distutils
> - release it for 2.x
> - let's add your work in distutils2 as well, so it's back in the stdlib in 3.x

 that would work very well: people doing new setup.py files, converting from python2 etc., will, duh, need to do _some_ conversion: they'll expect breakage and to be using distutils2 anyway.

thank you tarek.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Nov 13 14:11:30 2010
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sat, 13 Nov 2010 13:11:30 +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: <1289653890.86.0.317926943336.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

> The current patch makes too many changes in core distutils functions;
> it cannot be accepted in this form.  I'm sure that most of the needed
> changes can be made in a subclass of the present Mingw32CCompiler.

 that's what i did when creating the _other_ (yet another)
 mingw32 patch - however _some_ minimal changes to core distutils
 _are_ unfortunately required.  and to sys.py and os.py - this is,
 after all, a new platform!  it starts off with
 "sys.platform == 'mingw32'", requiring detection of gcc compiler
 type BUT and os type of win32, and goes from there.

 right now, detection logic is:

 * "if gcc on win32 platform, platform MUST be cygwin"
 * "if msvc compiler, platform MUST be win32"

 both of which are... well... wrong! :)

 so, i found that it was necessary to start in os.py and sys.py,
 create a platform-type "mingw32" and _then_ it was easy to do
 a MingW32Compiler etc. with (mostly) additions not modifications
 to distutils, but _necessary_ to add in detection of the type.

 if distutils was designed to do "exec import distutils.compiler.%s as compiler" % sys.platform and go from there then this would be an entirely non-issue: no modifications to distutils would be required, just a completely separate module containing the new compiler...

 ... but distutils isn't designed that way, is it? :)

 l.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Nov 13 14:17:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 13:17:47 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1289651699.93.0.697658444558.issue10116@psf.upfronthosting.co.za>
Message-ID: <1289654256.3572.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

There are still sporadic failures such as:

======================================================================
ERROR: testURLread (test.test_urllibnet.URLTimeoutTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/2.7.hansen-osx-x86/build/Lib/test/test_urllibnet.py", line 40, in testURLread
    x = f.read()
  File "/Users/pythonbuildbot/buildarea/2.7.hansen-osx-x86/build/Lib/socket.py", line 351, in read
    data = self._sock.recv(rbufsize)
timeout: timed out

which seems to show that not everything has been properly converted.

(http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%
202.7/builds/156/steps/test/logs/stdio )

Le samedi 13 novembre 2010 ? 12:34 +0000, Senthil Kumaran a ?crit :
> Changes by Senthil Kumaran <orsenthil at gmail.com>:
> 
> 
> ----------
> status: pending -> closed
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10116>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Sat Nov 13 14:47:29 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Sat, 13 Nov 2010 13:47:29 +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: <1289656049.29.0.161510973132.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I'd have liked to suggest updating the underlying unicode data to the latest standard 6.0, but it turns out, it might be problematic with the cross-version compatibility;
according to the clarification in 
http://bugs.python.org/issue10400
the 3... versions are going to be updated, while it is not allowed in the 2.x series.
I guess it would cause maintainance problems (as the needed properties are not available via unicodedata).
Anyway, while I'd like the recent unicode data to be supported (new characters, ranges, scripts, and corrected individual properties...),
I'm much happier, that there is support for the 2 series in regex...
vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Nov 13 15:06:39 2010
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 13 Nov 2010 14:06:39 +0000
Subject: [issue10407] missing errno import in distutils/dir_util.py
In-Reply-To: <1289657199.35.0.294057606181.issue10407@psf.upfronthosting.co.za>
Message-ID: <1289657199.35.0.294057606181.issue10407@psf.upfronthosting.co.za>


New submission from Zbyszek Szmek <zbyszek at in.waw.pl>:

Fix is trivial:
diff -r 8daacdacf720 -r 1a821081b470 Lib/distutils/dir_util.py
--- a/Lib/distutils/dir_util.py Sat Nov 13 13:27:49 2010 +0100
+++ b/Lib/distutils/dir_util.py Sat Nov 13 14:37:49 2010 +0100
@@ -5,6 +5,7 @@
 __revision__ = "$Id: dir_util.py 86244 2010-11-06 04:48:05Z eric.araujo $"
 
 import os, sys
+import errno
 from distutils.errors import DistutilsFileError, DistutilsInternalError
 from distutils import log

----------
assignee: tarek
components: Distutils
messages: 121137
nosy: eric.araujo, tarek, zbysz
priority: normal
severity: normal
status: open
title: missing errno import in distutils/dir_util.py
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10407>
_______________________________________

From report at bugs.python.org  Sat Nov 13 15:14:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 13 Nov 2010 14:14:01 +0000
Subject: [issue10407] missing errno import in distutils/dir_util.py
In-Reply-To: <1289657199.35.0.294057606181.issue10407@psf.upfronthosting.co.za>
Message-ID: <1289657641.86.0.963703624009.issue10407@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  I?ve run pyflakes over the distutils directory and found another error in test_sysconfig.  Will fix shortly.

----------
assignee: tarek -> eric.araujo
status: open -> pending
type: crash -> behavior
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10407>
_______________________________________

From report at bugs.python.org  Sat Nov 13 15:48:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 14:48:12 +0000
Subject: [issue10408] Denser dicts and linear probing
In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za>
Message-ID: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is a patch experiment which does two things:
- make dicts denser by making the resize factor 2 instead of 4 for small dicts
- improve cache locality on collisions by using linear probing

It should be noted that these two changes are not independent. Improving cache locality on collisions makes probing cheaper, and in turn should allow to make small dicts denser.

Linear probing is motivated by the fact that collisions can happen frequently.  The comments in dictobject.c seem a bit mistaken:

?If we *usually* find the key we're looking for on the first try (and, it turns out, we usually do -- the table load factor is kept under 2/3, so the odds are solidly in our favor), then it makes best sense to keep the initial index computation dirt cheap.?

According to http://www.cse.ust.hk/~yike/pods10-hashing.pdf, however, things are not so rosy. The average number of probes for successful lookups, depending on the load factor "alpha", is given by:

>>> c = lambda alpha: 0.5 * (1 + 1/(1-alpha))

while the average number of probes for unsuccessful lookups is:

>>> cp = lambda alpha: 0.5 * (1 + 1/(1-alpha)**2)

(note: this is with a perfectly random hash function; I intuitively assume an imperfect random function gives higher figures)

For a load factor of 2/3, we then get:

>>> c(2/3)
1.9999999999999998
>>> cp(2/3)
4.999999999999999

Since the current non-linear probing schemes guarantees that each probing will access a different cache line, the cache locality of a lookup becomes very poor.

The problem with linear probing, as noted in the comments, is that it degrades performance quite a lot when the hashing function clusters results. The solution I'm proposing is to apply an *initial* perturbation, by multiplying the hash() with a prime number. Multiplication is very fast on modern CPUs, so this doesn't adversely affect performance.

----------
components: Interpreter Core
files: dictopts.patch
keywords: patch
messages: 121139
nosy: mark.dickinson, pitrou, rhettinger, tim_one
priority: normal
severity: normal
status: open
title: Denser dicts and linear probing
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file19595/dictopts.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10408>
_______________________________________

From report at bugs.python.org  Sat Nov 13 15:53:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 14:53:07 +0000
Subject: [issue10408] Denser dicts and linear probing
In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za>
Message-ID: <1289659987.29.0.746622015253.issue10408@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a benchmark adapted from another bug entry (I merely adapted the dict sizes in order to better exhibit the performance degradation when the CPU cache becomes too small to hold the whole dict).

Results without the patch:

   10000 words (    9092 keys), 2928369 inserts/s, 13911456 lookups/s, 86 bytes/key (0.8MB)
   20000 words (   17699 keys), 3290037 inserts/s, 12746707 lookups/s, 44 bytes/key (0.8MB)
   40000 words (   34490 keys), 2620007 inserts/s, 7723605 lookups/s, 91 bytes/key (3.0MB)
   80000 words (   67148 keys), 2698863 inserts/s, 6573500 lookups/s, 46 bytes/key (3.0MB)
  160000 words (  130897 keys), 2401067 inserts/s, 4886971 lookups/s, 48 bytes/key (6.0MB)
  320000 words (  254233 keys), 2077558 inserts/s, 5061763 lookups/s, 49 bytes/key (12.0MB)
  640000 words (  493191 keys), 1923967 inserts/s, 4490697 lookups/s, 51 bytes/key (24.0MB)
 1280000 words (  956820 keys), 1792729 inserts/s, 4353711 lookups/s, 52 bytes/key (48.0MB)

Results with the patch:

   10000 words (    9092 keys), 3324590 inserts/s, 13911456 lookups/s, 43 bytes/key (0.4MB)
   20000 words (   17699 keys), 3243603 inserts/s, 13202090 lookups/s, 44 bytes/key (0.8MB)
   40000 words (   34490 keys), 2858372 inserts/s, 10686124 lookups/s, 45 bytes/key (1.5MB)
   80000 words (   67148 keys), 2585146 inserts/s, 6917441 lookups/s, 46 bytes/key (3.0MB)
  160000 words (  130897 keys), 2395923 inserts/s, 6455817 lookups/s, 48 bytes/key (6.0MB)
  320000 words (  254233 keys), 2247141 inserts/s, 5529826 lookups/s, 49 bytes/key (12.0MB)
  640000 words (  493191 keys), 2064675 inserts/s, 5073732 lookups/s, 51 bytes/key (24.0MB)
 1280000 words (  956820 keys), 1997615 inserts/s, 4760878 lookups/s, 52 bytes/key (48.0MB)


Lookups become 10% faster when the dict is bigger than the cache, and even inserts seem to benefit a bit.
(not to mention that small dicts take almost half the memory)

----------
Added file: http://bugs.python.org/file19596/dcbench-py3k.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10408>
_______________________________________

From report at bugs.python.org  Sat Nov 13 16:31:08 2010
From: report at bugs.python.org (John J Lee)
Date: Sat, 13 Nov 2010 15:31:08 +0000
Subject: [issue1520831] urrlib2 max_redirections=0 disables redirects
Message-ID: <1289662268.06.0.289848789691.issue1520831@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Why not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1520831>
_______________________________________

From report at bugs.python.org  Sat Nov 13 16:31:11 2010
From: report at bugs.python.org (Stein Magnus Jodal)
Date: Sat, 13 Nov 2010 15:31:11 +0000
Subject: [issue10409] mkcfg crashes with ValueError
In-Reply-To: <1289662271.73.0.0539651224408.issue10409@psf.upfronthosting.co.za>
Message-ID: <1289662271.73.0.0539651224408.issue10409@psf.upfronthosting.co.za>


New submission from Stein Magnus Jodal <stein.magnus at jodal.no>:

I'm using Distutils2 1.0a3 with Python 2.6.6.


To reproduce:

1. Run ``python -m distutils2.mkcfg``
2. When you get to the Trove classifier step enter e.g. "Apache 2" as license
3. When asked to select a matching license, enter something else than a number, e.g. "Apache"
4. mkcfg crashes with a ValueError


Traceback (most recent call last):
  File "/usr/lib/python2.6/runpy.py", line 122, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python2.6/runpy.py", line 34, in _run_code
    exec code in run_globals
  File "/usr/local/lib/python2.6/dist-packages/distutils2/mkcfg.py", line 415, in <module>
    main()
  File "/usr/local/lib/python2.6/dist-packages/distutils2/mkcfg.py", line 409, in main
    program.query_user()
  File "/usr/local/lib/python2.6/dist-packages/distutils2/mkcfg.py", line 242, in query_user
    self.set_classifier()
  File "/usr/local/lib/python2.6/dist-packages/distutils2/mkcfg.py", line 254, in set_classifier
    self.set_license(self.classifiers)
  File "/usr/local/lib/python2.6/dist-packages/distutils2/mkcfg.py", line 319, in set_license
    foundIndex = foundList[int(troveLicense) - 1]
ValueError: invalid literal for int() with base 10: 'Apache'

----------
assignee: tarek
components: Distutils2
messages: 121142
nosy: eric.araujo, jodal, tarek
priority: normal
severity: normal
status: open
title: mkcfg crashes with ValueError
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10409>
_______________________________________

From report at bugs.python.org  Sat Nov 13 17:51:22 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 13 Nov 2010 16:51:22 +0000
Subject: [issue10409] mkcfg crashes with ValueError
In-Reply-To: <1289662271.73.0.0539651224408.issue10409@psf.upfronthosting.co.za>
Message-ID: <1289667082.16.0.11022674629.issue10409@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Thanks for the feedback, I can reproduce this. Fixing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10409>
_______________________________________

From report at bugs.python.org  Sat Nov 13 17:56:55 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 13 Nov 2010 16:56:55 +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: <1289667415.01.0.560899036562.issue3871@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> this is, after all, a new platform! it starts off with 
> "sys.platform == 'mingw32'"

I disagree; programs compiled with mingw32 run on Windows, and use the MSVC runtime. It's the same platform as the current win32 build.
It's even possible to use mingw32 to compile extensions for the VS9.0 based python.exe.
A different compiler does not make a new platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Sat Nov 13 18:15:25 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 13 Nov 2010 17:15: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: <1289668525.2.0.287997234241.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101113.zip is a new version of the regex module.

It now supports Unicode 6.0.0.

----------
Added file: http://bugs.python.org/file19597/issue2636-20101113.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Nov 13 18:26:45 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 13 Nov 2010 17:26:45 +0000
Subject: [issue10409] mkcfg crashes with ValueError
In-Reply-To: <1289662271.73.0.0539651224408.issue10409@psf.upfronthosting.co.za>
Message-ID: <1289669205.82.0.929688422509.issue10409@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Commited in a99e29d63071 (hg.python.org)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10409>
_______________________________________

From report at bugs.python.org  Sat Nov 13 19:03:19 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 13 Nov 2010 18:03:19 +0000
Subject: [issue10401] Globals / builtins cache
In-Reply-To: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>
Message-ID: <1289671399.73.0.815141500047.issue10401@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Unladen actually has something like this in place for performance optimizations. Not sure how Antoine's approach differs, though.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10401>
_______________________________________

From report at bugs.python.org  Sat Nov 13 19:09:47 2010
From: report at bugs.python.org (Michael Hoffman)
Date: Sat, 13 Nov 2010 18:09:47 +0000
Subject: [issue2571] cmd.py always uses raw_input,
	even when another stdin is specified
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1289671787.92.0.427867164876.issue2571@psf.upfronthosting.co.za>


Changes by Michael Hoffman <qq9jsuvyyw at snkmail.com>:


----------
nosy: +hoffman

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Sat Nov 13 19:13:17 2010
From: report at bugs.python.org (Michael Hoffman)
Date: Sat, 13 Nov 2010 18:13:17 +0000
Subject: [issue10396] stdin argument to pdb.Pdb doesn't work unless you also
	set Pdb.use_rawinput = False
In-Reply-To: <1289584221.71.0.586527779083.issue10396@psf.upfronthosting.co.za>
Message-ID: <1289671997.72.0.220633007154.issue10396@psf.upfronthosting.co.za>


Michael Hoffman <qq9jsuvyyw at snkmail.com> added the comment:

As always, it seems a bit more complicated than I originally expected. Since it's too late for a Python 2.x feature addition, I'll wait until I upgrade to 3.x to work on that.

You are correct, technically this is not a docs bug but I think the clarity of the docs would be greatly improved if you would add the text from the cmd module docs to the pdb docs:

"If you want a given stdin to be used, make sure to set the instance?s use_rawinput attribute to False, otherwise stdin will be ignored."

I hope you will agree that this is unexpected behavior that doesn't really fit into the zen of Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10396>
_______________________________________

From report at bugs.python.org  Sat Nov 13 19:13:46 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Sat, 13 Nov 2010 18:13:46 +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: <1289672026.98.0.725082545791.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Thank you very much!
a quick test with my custom unicodedata with 6.0 on py 2.7 seems ok.
I hope, there won't be problems with "cooperation" of the more recent internal data with the original 5.2 database in python 2.x releases.

vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Nov 13 19:14:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 18:14:15 +0000
Subject: [issue10401] Globals / builtins cache
In-Reply-To: <1289597080.96.0.9732660757.issue10401@psf.upfronthosting.co.za>
Message-ID: <1289672055.92.0.943585449534.issue10401@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There aren't many possible approaches. The more complex variants of globals caches try to also speedup writes, which is IMO a waste of time since rebinding globals is not a good coding practice, and especially not in the middle of time-critical loops.

(by the way, the patch only addresses normal functions, but generators would easily benefit from a similar treatment)

And Skip is right that this would be most useful when paired with a JIT (allowing for aggressive specialization, and possibly inlining).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10401>
_______________________________________

From report at bugs.python.org  Sat Nov 13 19:21:56 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 13 Nov 2010 18:21:56 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1289672516.22.0.381319619959.issue10399@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

While I have nothing to say directly about the inline optimization, I do have some stuff to say about moving to AST optimizations.

First, doing in Python is a good thing. It not only makes prototyping easier, but it allows other VMs to use the optimizations w/o having to re-implement themselves.

Second, the symtable pass does need to eventually get exposed (most likely as an optional pass one can do to an AST). I am actually in the middle of an AST-heavy project that will end up wanting the symbol table info as well.

Third, for that Graphviz output, was anything special required? If so, I would toss the code into Tools for others to benefit from.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Sat Nov 13 20:18:29 2010
From: report at bugs.python.org (INADA Naoki)
Date: Sat, 13 Nov 2010 19:18:29 +0000
Subject: [issue10410] Is iterable a container type?
In-Reply-To: <1289675908.98.0.73683654885.issue10410@psf.upfronthosting.co.za>
Message-ID: <1289675908.98.0.73683654885.issue10410@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

In http://docs.python.org/release/2.6.6/glossary.html, "iterable" is described as
"A container object capable of returning its members one at a time."
Is it correct? Is stream object like file a container type?

Container ABC requires only "__contains__" abstract method. I think file
is iterable but is not container.

Likewise, "and objects of any classes you define with an __iter__() or
__getitem__() method." is wrong because __getitem__ method is not relate to
iterable.

----------
assignee: docs at python
components: Documentation
messages: 121152
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Is iterable a container type?
versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10410>
_______________________________________

From report at bugs.python.org  Sat Nov 13 23:54:13 2010
From: report at bugs.python.org (Brad Greenlee)
Date: Sat, 13 Nov 2010 22:54:13 +0000
Subject: [issue10392] GZipFile crash when fileobj.mode is None
In-Reply-To: <1289541524.38.0.073026896043.issue10392@psf.upfronthosting.co.za>
Message-ID: <1289688853.63.0.83392668585.issue10392@psf.upfronthosting.co.za>


Brad Greenlee <brad at footle.org> added the comment:

Understood. I just felt that fileobj.mode == None should be handled the same way that GzipFile(...,mode=None) is handled.

I've submitted a patch to Django: http://code.djangoproject.com/ticket/14681

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10392>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:00:37 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Sat, 13 Nov 2010 23:00:37 +0000
Subject: [issue10411] Pickle benchmark fails after converting Benchmark Suite
	to py3k
In-Reply-To: <1289689237.0.0.348719210289.issue10411@psf.upfronthosting.co.za>
Message-ID: <1289689237.0.0.348719210289.issue10411@psf.upfronthosting.co.za>


New submission from Bobby Impollonia <bobbyi at gmail.com>:

After checking out and converting the benchmark suite to py3k, the py3k benchmark set fails because of an ImportError in bm_pickle.py.  

Steps to reproduce:
hg clone http://hg.python.org/benchmarks/ py2benchmarks
mkdir py3benchmarks
cd py3benchmarks
../py2benchmarks/make_perf3.sh ../py2benchmarks
py3k perf.py -f -b py3k old_py3k new_py3k

The ImportError comes from the new py2k/ py3k compatibility code. bm_pickle imports "long" from compat.py. However, when 2to3 is run, it changes the import line from saying "import ... long" to saying "import ... int", which fails because compat.py does not define "int".

Is this a bug in lib2to3? I would not expect names used as lvalues to get converted. I'm using lib2to3 from python 2.6.5.

A similar case is that the line
    unicode = str
in compat.py gets changed by 2to3 to:
    str = str
This isn't currently causing any problems because no one is trying to import "unicode" from compat, but if they did, they would fail on py3k.

Regardless, a patch is attached that fixes bm_pickle by using "int_" as the name for our typedef instead of "long".

----------
assignee: collinwinter
components: Benchmarks
files: compat.patch
keywords: patch
messages: 121154
nosy: bobbyi, collinwinter, pitrou
priority: normal
severity: normal
status: open
title: Pickle benchmark fails after converting Benchmark Suite to py3k
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19598/compat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10411>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:02:34 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Nov 2010 23:02:34 +0000
Subject: [issue10408] Denser dicts and linear probing
In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za>
Message-ID: <1289689354.8.0.363857776985.issue10408@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

My previous experiments along these lines showed it was a dead-end.  The number of probes was the most important factor and beat-out any effort to improve cache utilization from increased density.  

Doing extra work (more probes) in order to improve cache effects is very difficult because most real programs have an uneven access pattern so that the most frequently accesses items are usually already in cache.  So, the attempted improvement only helps the less frequently accessed items and isn't worth the extra number of probes.

Another result from earlier experiments is that benchmarking the experiment is laden with pitfalls.  Tight timing loops don't mirror real world programs, nor do access patterns with uniform random distributions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10408>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:12:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 23:12:19 +0000
Subject: [issue10408] Denser dicts and linear probing
In-Reply-To: <1289689354.8.0.363857776985.issue10408@psf.upfronthosting.co.za>
Message-ID: <1289689933.3561.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> My previous experiments along these lines showed it was a dead-end.
> The number of probes was the most important factor and beat-out any
> effort to improve cache utilization from increased density.  

Can you describe your experiments? What workloads or benchmarks did you
use?

Do note that there are several levels of caches in modern CPUs. L1 is
very fast (latency is 3 or 4 cycles) but rather small (32 or 64KB). L2,
depending on the CPU, has a latency between 10 and 20+ cycles and can be
256KB to 1MB large. L3, when present, is quite larger but also quite
slower (latency sometimes up to 50 cycles).
So, even if access patterns are uneven, it is probably rare to have all
frequently accessed data in L1 (especially with Python since objects are
big).

> Another result from earlier experiments is that benchmarking the
> experiment is laden with pitfalls.  Tight timing loops don't mirror
> real world programs, nor do access patterns with uniform random
> distributions.

I can certainly understand that; can you suggest workloads approaching
"real world programs"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10408>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:14:19 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Nov 2010 23:14:19 +0000
Subject: [issue10408] Denser dicts and linear probing
In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za>
Message-ID: <1289690059.37.0.930145765696.issue10408@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, one way to make a dict denser without increasing the number of probes is to use Brent's Variation of Algorithm D in Knuth.  That optimizes the insertion order to minimize the number of collisions and lets you pack well over two-thirds full without degradation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10408>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:24:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 23:24:08 +0000
Subject: [issue10408] Denser dicts and linear probing
In-Reply-To: <1289690059.37.0.930145765696.issue10408@psf.upfronthosting.co.za>
Message-ID: <1289690644.3561.16.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> FWIW, one way to make a dict denser without increasing the number of
> probes is to use Brent's Variation of Algorithm D in Knuth.  That
> optimizes the insertion order to minimize the number of collisions and
> lets you pack well over two-thirds full without degradation.

He, you suggested that several years ago on python-dev and I supplied
the code. Also, IIRC, it didn't bring any improvement - although I don't
remember which benchmarks, if any, were run.

But the experiment here is mostly to decrease the (direct and indirect)
cost of collisions by improving temporal locality of lookups.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10408>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:26:41 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Nov 2010 23:26:41 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1289690801.57.0.235163194714.issue10403@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> "Members and methods" should just be "attributes".

+1 

That substitution should be made almost everywhere.

Individual slot variable are still called members though
and their type is a member_descriptor.  And the C API
still has a tp_members entry.  Otherwise, it looks like
the term member is out-of-date.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:27:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 23:27:16 +0000
Subject: [issue10411] Pickle benchmark fails after converting Benchmark Suite
	to py3k
In-Reply-To: <1289689237.0.0.348719210289.issue10411@psf.upfronthosting.co.za>
Message-ID: <1289690836.75.0.993825617691.issue10411@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, since this benchmark is already 3.x compatible, there's not much sense in making a 2to3 pass, is there?
So perhaps "make_perf3.sh" (which I've never used) should be a bit smarter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10411>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:31:31 2010
From: report at bugs.python.org (Maciek J)
Date: Sat, 13 Nov 2010 23:31:31 +0000
Subject: [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1289691091.33.0.848598163662.issue10149@psf.upfronthosting.co.za>


Maciek J <egil at wp.pl> added the comment:

Couldn't compile to html at the moment, but it should be fine anyway.

Note that I didn't wanted to start a new paragraph (I'm guessing you meant the sentence at line 13 of the patch) as there was no new paragraph in a previous version.

----------
Added file: http://bugs.python.org/file19599/pyexpat.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10149>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:38:24 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Nov 2010 23:38:24 +0000
Subject: [issue10408] Denser dicts and linear probing
In-Reply-To: <1289659692.61.0.467153013048.issue10408@psf.upfronthosting.co.za>
Message-ID: <1289691504.91.0.876369065996.issue10408@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See Objects/dictnotes.txt for some of the results.
I spent about full month trying to optimize dict
performance either by tuning parameters or using
different algorithms.

There were a couple wins that were not implemented.
1) Allowing users to control insertion order or
at least specify which keys are frequently accessed
so that we could assure a first-time hit.
2) Allowing users to pre-size a dictionary so that
resizes wouldn't be needed or an so they could control
density.
Guido didn't want to expose these controls.

The PyPy guys published a paper on their results with
alternative dict implementations and specialized dicts.
You might want to look at that.  IIRC, they found only
minor wins.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10408>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:40:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 23:40:42 +0000
Subject: [issue10408] Denser dicts and linear probing
In-Reply-To: <1289691504.91.0.876369065996.issue10408@psf.upfronthosting.co.za>
Message-ID: <1289691637.3561.18.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> See Objects/dictnotes.txt for some of the results.
> I spent about full month trying to optimize dict
> performance either by tuning parameters or using
> different algorithms.

Well, I've seen those results. I'm asking about which workloads or
benchmarks were used so that I can try to reproduce these experiments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10408>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:41:19 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Sat, 13 Nov 2010 23:41:19 +0000
Subject: [issue10411] Pickle benchmark fails after converting Benchmark Suite
	to py3k
In-Reply-To: <1289689237.0.0.348719210289.issue10411@psf.upfronthosting.co.za>
Message-ID: <1289691679.26.0.658528159153.issue10411@psf.upfronthosting.co.za>


Bobby Impollonia <bobbyi at gmail.com> added the comment:

Are there any files in performance/ that need 2to3?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10411>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:41:30 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Nov 2010 23:41:30 +0000
Subject: [issue10410] Is iterable a container type?
In-Reply-To: <1289675908.98.0.73683654885.issue10410@psf.upfronthosting.co.za>
Message-ID: <1289691690.13.0.437384612024.issue10410@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10410>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:44:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 13 Nov 2010 23:44:49 +0000
Subject: [issue10411] Pickle benchmark fails after converting Benchmark Suite
	to py3k
In-Reply-To: <1289691679.26.0.658528159153.issue10411@psf.upfronthosting.co.za>
Message-ID: <1289691886.3561.20.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Are there any files in performance/ that need 2to3?

All the ones that require external libs (such as django, spambayes,
etc.). Although, of course, since they require external libs it's not
sure the translation will work either.

I think I've converted all the standalone benchmarks. You can select
them by specifying "-b 2n3" to perf.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10411>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:51:25 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 13 Nov 2010 23:51:25 +0000
Subject: [issue10410] Is iterable a container type?
In-Reply-To: <1289675908.98.0.73683654885.issue10410@psf.upfronthosting.co.za>
Message-ID: <1289692285.61.0.112137812002.issue10410@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> "iterable" is described as "A container object 
> capable of returning its members one at a time."

That wording is confusing.  I'll fix it.

> Likewise, "and objects of any classes you define 
> with an __iter__() or __getitem__() method." is 
> wrong because __getitem__ method is not relate to
> iterable

That wording is correct.  Sequences are automatically
iterable even if they don't define __iter__.  For example:

>>> class A:
...     def __getitem__(self, i):
...         if i > 10:
...             raise IndexError(i)
...         return i * 100
	
>>> list(A())
[0, 100, 200, 300, 400, 500, 600, 700, 800, 900, 1000]

If you're curious, the details are in the PyObject_GetIter() function in http://svn.python.org/view/python/branches/release27-maint/Objects/abstract.c?view=markup .

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10410>
_______________________________________

From report at bugs.python.org  Sun Nov 14 00:55:38 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Sat, 13 Nov 2010 23:55:38 +0000
Subject: [issue10412] Add py3k support for "slow" pickle benchmark in
	Benchmark Suite
In-Reply-To: <1289692538.69.0.952593194282.issue10412@psf.upfronthosting.co.za>
Message-ID: <1289692538.69.0.952593194282.issue10412@psf.upfronthosting.co.za>


New submission from Bobby Impollonia <bobbyi at gmail.com>:

A patch is attached that does the following:
1) Add py3k support for the "slow" (pure-Python) pickle/ unpickle benchmarks.
2) Add a runtime check to the pickle benchmark verifying that we do or don't have the C accelerators as expected.
3) Rename the cPickle versions to "fastpickle"/ "fastunpickle" and add a group called "pickle" that contains all of the pickling benchmarks.
4) Add the "pickle" benchmark group to the py3k and 2n3 groups.

----------
assignee: collinwinter
components: Benchmarks
files: slowpickle.patch
keywords: patch
messages: 121167
nosy: bobbyi, collinwinter, pitrou
priority: normal
severity: normal
status: open
title: Add py3k support for "slow" pickle benchmark in Benchmark Suite
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19600/slowpickle.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10412>
_______________________________________

From report at bugs.python.org  Sun Nov 14 01:34:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 14 Nov 2010 00:34:17 +0000
Subject: [issue10413] Comments in unicode.h are out of date
In-Reply-To: <1289694856.74.0.857329002017.issue10413@psf.upfronthosting.co.za>
Message-ID: <1289694856.74.0.857329002017.issue10413@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch updates some comments in unicode.h mostly reflecting the fact that the default encoding is now unconditionally UTF-8.

----------
assignee: belopolsky
components: Documentation, Interpreter Core
files: unicode-comments.diff
keywords: patch
messages: 121168
nosy: belopolsky, haypo, lemburg, loewis
priority: normal
severity: normal
stage: patch review
status: open
title: Comments in unicode.h are out of date
versions: Python 3.2
Added file: http://bugs.python.org/file19601/unicode-comments.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10413>
_______________________________________

From report at bugs.python.org  Sun Nov 14 01:50:43 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Nov 2010 00:50:43 +0000
Subject: [issue9520] Add Patricia Trie high performance container
In-Reply-To: <1280969963.37.0.950740145402.issue9520@psf.upfronthosting.co.za>
Message-ID: <1289695843.34.0.175373600196.issue9520@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I don't think a Patricia Trie is going to find its way into the code distribution.  It has a better chance as a third-party module listed on PyPI (much in the same way that people access memcached from Python).

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9520>
_______________________________________

From report at bugs.python.org  Sun Nov 14 03:03:11 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 14 Nov 2010 02:03:11 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1289700191.84.0.509300775835.issue9807@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

this adds the modifier to the <prefix>/python3.2<abi>/config directory.

Now you end up with both
  
  <prefix>/python3.2<abi>/config

and

    <prefix>/python3.2/

for anything else. This is not what Debian, Fedora and Ubuntu are currently doing. Is this really wanted? I'd rather like to see this as

    <prefix>/python3.2/config-<abi>

so that everything is again in one prefix.


$ ls -l <prefix>/lib/pkgconfig/
total 4
-rw-r--r-- 1 doko doko 282 Nov 14 02:44 python-3.2.pc
lrwxrwxrwx 1 doko doko  13 Nov 14 02:44 python-3.2mu.pc -> python-3.2.pc

python-3.2mu.pc should be the file, python-3.2.pc the symlink.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Sun Nov 14 03:20:35 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 14 Nov 2010 02:20:35 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>
Message-ID: <1289701235.85.0.963473343851.issue10260@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Good point, Antoine.  I'm always trying to keep those timeouts low, however, to avoid having the testsuite duration grow too much with every test :)

I think we can probably fix the issue by having the lock_tests.Bunch() function only return when all threads have checked in, thus avoiding thread startup delays affecting our timeouts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10260>
_______________________________________

From report at bugs.python.org  Sun Nov 14 03:35:10 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 14 Nov 2010 02:35:10 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1289702110.48.0.917444635139.issue9807@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

the change to python.pc should make the abi change to includedir, not Cflags.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Sun Nov 14 04:33:11 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 14 Nov 2010 03:33:11 +0000
Subject: [issue5111] httplib: wrong Host header when connecting to IPv6
	litteral URL
In-Reply-To: <1233334139.62.0.259128767537.issue5111@psf.upfronthosting.co.za>
Message-ID: <1289705591.85.0.490917669327.issue5111@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

r86461 (release31-maint)
r86462 (release27-maint)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5111>
_______________________________________

From report at bugs.python.org  Sun Nov 14 05:35:18 2010
From: report at bugs.python.org (david)
Date: Sun, 14 Nov 2010 04:35:18 +0000
Subject: [issue10414] socket.gethostbyname  doesn't return an ipv6 address
In-Reply-To: <1289709318.9.0.235139859689.issue10414@psf.upfronthosting.co.za>
Message-ID: <1289709318.9.0.235139859689.issue10414@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

(socket.gethostbyname  doesn't return an ipv6 address)
So just to start with I know the documentation says [0] "and getaddrinfo() should be used instead for IPv4/v6 dual stack support."
However, the getaddrinfo() method provides more information than required. Why can't getaddrinfo support ipv6 ? or a method for ipv6 added to the socket module to make getting a host address by name easier (for ipv6) ? 



[0] - http://docs.python.org/library/socket.html#socket.gethostbyname

----------
messages: 121174
nosy: db
priority: normal
severity: normal
status: open
title: socket.gethostbyname  doesn't return an ipv6 address

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10414>
_______________________________________

From report at bugs.python.org  Sun Nov 14 06:27:58 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 14 Nov 2010 05:27:58 +0000
Subject: [issue10410] Is iterable a container type?
In-Reply-To: <1289675908.98.0.73683654885.issue10410@psf.upfronthosting.co.za>
Message-ID: <1289712478.81.0.126349059671.issue10410@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Removed the incorrect "container" reference.
See r86463.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10410>
_______________________________________

From report at bugs.python.org  Sun Nov 14 06:28:46 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Sun, 14 Nov 2010 05:28:46 +0000
Subject: [issue10411] Pickle benchmark fails after converting Benchmark Suite
	to py3k
In-Reply-To: <1289689237.0.0.348719210289.issue10411@psf.upfronthosting.co.za>
Message-ID: <1289712526.12.0.410093592912.issue10411@psf.upfronthosting.co.za>


Bobby Impollonia <bobbyi at gmail.com> added the comment:

Patch is attached for make_perf3.sh to have it not convert things that don't need to be converted. This fixes the issue and with the patch all the py3k benchmarks run successfully after running the script.

----------
Added file: http://bugs.python.org/file19602/make_perf3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10411>
_______________________________________

From report at bugs.python.org  Sun Nov 14 07:31:47 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Sun, 14 Nov 2010 06:31:47 +0000
Subject: [issue10411] Pickle benchmark fails after converting Benchmark Suite
	to py3k
In-Reply-To: <1289689237.0.0.348719210289.issue10411@psf.upfronthosting.co.za>
Message-ID: <1289716307.5.0.070531425086.issue10411@psf.upfronthosting.co.za>


Bobby Impollonia <bobbyi at gmail.com> added the comment:

Attached is a patch for perf.py that goes along with the previous patch for make_perf3.sh. This patch changes the py3k group to include everything in the 2n3 group since we can still run all those tests after converting.

Previously, nqueens, unpack_sequance and richards weren't run as part of -b py3k

----------
Added file: http://bugs.python.org/file19603/perf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10411>
_______________________________________

From report at bugs.python.org  Sun Nov 14 08:12:15 2010
From: report at bugs.python.org (Justin Lebar)
Date: Sun, 14 Nov 2010 07:12:15 +0000
Subject: [issue10415] readline.insert_text documentation incomplete
In-Reply-To: <1289718734.94.0.0887962692453.issue10415@psf.upfronthosting.co.za>
Message-ID: <1289718734.94.0.0887962692453.issue10415@psf.upfronthosting.co.za>


New submission from Justin Lebar <justin.lebar at gmail.com>:

The readline documentation currently says:

> readline.insert_text(string)
>     Insert text into the command line.

But as far as I can tell, readline.insert_text() does something only when called from startup_hook or pre_input_hook.

Here's an example of someone using the module in a way that works:

http://swapoff.org/svn/cly/tags/0.7/cly/interactive.py

----------
assignee: docs at python
components: Documentation
messages: 121178
nosy: Justin.Lebar, docs at python
priority: normal
severity: normal
status: open
title: readline.insert_text documentation incomplete
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10415>
_______________________________________

From report at bugs.python.org  Sun Nov 14 08:14:46 2010
From: report at bugs.python.org (Justin Lebar)
Date: Sun, 14 Nov 2010 07:14:46 +0000
Subject: [issue10415] readline.insert_text documentation incomplete
In-Reply-To: <1289718734.94.0.0887962692453.issue10415@psf.upfronthosting.co.za>
Message-ID: <1289718886.1.0.671776354961.issue10415@psf.upfronthosting.co.za>


Justin Lebar <justin.lebar at gmail.com> added the comment:

Actually, maybe startup_hook doesn't do what it sounds like it does and insert_text() only works from startup_hook.

If this is the case, then the documentation for startup_hook could also be improved:

> The startup_hook function is called with no arguments just before 
> readline prints the first prompt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10415>
_______________________________________

From report at bugs.python.org  Sun Nov 14 08:26:41 2010
From: report at bugs.python.org (Ron Adam)
Date: Sun, 14 Nov 2010 07:26:41 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1289719601.15.0.639950475764.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Ok, here is the latest patch for review.  "issue2001_a.diff'

I restored the pydoc.py file and then put most of the new code in these two functions,

  _startserver(urlhandler, port)
  _browse(port=0, *, open_browser=True)

This creates a bettor organized file, and reduces the number of names with leading underscores.  As far as I know you can't import things that are located inside a function.

I still need to depreciate the '-g' option and the gui() function along with the old server parts.

Is there a guide on how to depreciate things?

----------
Added file: http://bugs.python.org/file19604/issue2001_a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Sun Nov 14 08:40:12 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 14 Nov 2010 07:40:12 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1289720412.26.0.75698795903.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Just call warnings.warn with an appropriate message, a category of DeprecationWarning and a stacklevel of 2 (so the warning will refer to the function's caller rather than to the pydoc code).

It's basically the example from the warnings.warn docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Sun Nov 14 10:33:54 2010
From: report at bugs.python.org (Julius Tuomisto)
Date: Sun, 14 Nov 2010 09:33:54 +0000
Subject: [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>
Message-ID: <1289727234.45.0.0772663512024.issue9991@psf.upfronthosting.co.za>


Julius Tuomisto <zforzulu at gmail.com> added the comment:

Renderfarm.fi's python based "uploader" for Blender 2.5 (GPL licensed and a part of the main distribution of Blender) is still suffering from this bug. We're hopeful that this issue would be fixed in the next versions of Python. Thank you!

----------
nosy: +Julius.Tuomisto

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9991>
_______________________________________

From report at bugs.python.org  Sun Nov 14 11:01:44 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 14 Nov 2010 10:01:44 +0000
Subject: [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1289727234.45.0.0772663512024.issue9991@psf.upfronthosting.co.za>
Message-ID: <AANLkTiktSaGOzvq5vM=i8hXmEpMeUvjBnamO=NDuyBuL@mail.gmail.com>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

That's sad. The fix is very simple. We shall have it before 3.2 alpha4 or beta1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9991>
_______________________________________

From report at bugs.python.org  Sun Nov 14 11:25:24 2010
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 14 Nov 2010 10:25:24 +0000
Subject: [issue10410] Is iterable a container type?
In-Reply-To: <1289692285.61.0.112137812002.issue10410@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=8k5N6pQoVCjWs_=s_wkP3vzL7naOAda+Ea2GX@mail.gmail.com>


INADA Naoki <songofacandy at gmail.com> added the comment:

>> Likewise, "and objects of any classes you define
>> with an __iter__() or __getitem__() method." is
>> wrong because __getitem__ method is not relate to
>> iterable
>
> That wording is correct. ?Sequences are automatically
> iterable even if they don't define __iter__. ?For example:

Wow, thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10410>
_______________________________________

From report at bugs.python.org  Sun Nov 14 11:30:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 14 Nov 2010 10:30:53 +0000
Subject: [issue10414] socket.gethostbyname  doesn't return an ipv6 address
In-Reply-To: <1289709318.9.0.235139859689.issue10414@psf.upfronthosting.co.za>
Message-ID: <1289730653.84.0.164771082159.issue10414@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Python has a policy of exposing low-level APIs as-is, i.e. the way the operating system implements them. gethostbyname is an old BSD socket API function that is limited to IPv4, and Python exposes it as such.

If you want another convenience function, I recommend to write it yourself, and then use it in your code.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10414>
_______________________________________

From report at bugs.python.org  Sun Nov 14 12:20:15 2010
From: report at bugs.python.org (Peter Nielsen)
Date: Sun, 14 Nov 2010 11:20:15 +0000
Subject: [issue3493] No Backslash (\) in IDLE 1.2.2
In-Reply-To: <1217703828.28.0.450562077127.issue3493@psf.upfronthosting.co.za>
Message-ID: <1289733615.34.0.0253674575173.issue3493@psf.upfronthosting.co.za>


Peter Nielsen <peter.evil1 at gmail.com> added the comment:

I have the same problem with a danish keyboard and OSX snowleopard..
I can use \ in both the command editor and pretty everywhere else but not in Idle.

----------
nosy: +Peter.Nielsen
versions: +Python 2.6, Python 3.1 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3493>
_______________________________________

From report at bugs.python.org  Sun Nov 14 12:27:30 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 14 Nov 2010 11:27:30 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1289734050.66.0.579605507198.issue9116@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Hirokazu's patch works for me. Could this approach be taken in general to
suppress all buildbot pop-ups?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9116>
_______________________________________

From report at bugs.python.org  Sun Nov 14 12:34:05 2010
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sun, 14 Nov 2010 11:34:05 +0000
Subject: [issue10416] UnicodeDecodeError when 2to3 is run on a dir with numpy
	.npy files
In-Reply-To: <1289734445.75.0.657532915911.issue10416@psf.upfronthosting.co.za>
Message-ID: <1289734445.75.0.657532915911.issue10416@psf.upfronthosting.co.za>


New submission from Zbyszek Szmek <zbyszek at in.waw.pl>:

1. 2to3 should work only only files ending with '.py', but it takes
   anything which has a dot and ends with 'py'. I'm having trouble
   with numpy .npy files.
2. 2to3 tries to decode the file and fails with traceback that is not useful:
   the name of the failing file is not given.

A patch is attached.

% ls *.npy|head -n1
S_18_7000_899811b572b309161cbb34f185b82fb618ed81da.npy

% 2to3-3.2 /usr/local/bin/2to3-3.2 .
RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: set_literal
RefactoringTool: Skipping implicit fixer: ws_comma
Traceback (most recent call last):
  File "/usr/local/bin/2to3-3.2", line 6, in <module>
    sys.exit(main("lib2to3.fixes"))
  File "/usr/local/lib/python3.2/lib2to3/main.py", line 172, in main
    options.processes)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 699, in refactor
    items, write, doctests_only)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 294, in refactor
    self.refactor_dir(dir_or_file, write, doctests_only)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 313, in refactor_dir
    self.refactor_file(fullname, write, doctests_only)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 740, in refactor_file
    *args, **kwargs)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 335, in refactor_file
    input, encoding = self._read_python_source(filename)
  File "/usr/local/lib/python3.2/lib2to3/refactor.py", line 331, in _read_python_source
    return _from_system_newlines(f.read()), encoding
  File "/usr/local/lib/python3.2/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0x93 in position 0: invalid start byte

----------
components: 2to3 (2.x to 3.0 conversion tool)
files: diff.diff
keywords: patch
messages: 121188
nosy: zbysz
priority: normal
severity: normal
status: open
title: UnicodeDecodeError when 2to3 is run on a dir with numpy .npy files
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file19605/diff.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10416>
_______________________________________

From report at bugs.python.org  Sun Nov 14 13:04:03 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 14 Nov 2010 12:04:03 +0000
Subject: [issue10416] UnicodeDecodeError when 2to3 is run on a dir with numpy
	.npy files
In-Reply-To: <1289734445.75.0.657532915911.issue10416@psf.upfronthosting.co.za>
Message-ID: <1289736243.5.0.236652540639.issue10416@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10416>
_______________________________________

From report at bugs.python.org  Sun Nov 14 13:04:56 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 14 Nov 2010 12:04:56 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1289736296.13.0.890430249811.issue1553375@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As per my response to RDM on python-dev, I think the patch is misguided as it currently stands.

The traceback on an exception is built up as the stack unwinds. The stack above the frame containing the exception handler obviously hasn't been unwound yet, so it isn't included in the traceback object.

Since the frame containing the exception handler is live, it and the frame stack above it reflect the state of the exception handler, while the tracebacks on the chain of exceptions currently being handled reflect the parts of the stack that have already been unwound.

For explicit printing, a separate section printing the stack with print_stack() is a better option than trying to embed the information in the stack trace of the exception currently being handled.

For the logging use case, a separate "stack_trace" flag to request inclusion of stack trace details independent of the exception state seems like a preferable option.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sun Nov 14 13:09:51 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 14 Nov 2010 12:09:51 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1289736591.38.0.135236878996.issue1553375@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If the allframes flag is pursued further, then the stack trace should be added (with an appropriate header clause) after the entire exception chain has been printed (including the exception currently being handled).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sun Nov 14 13:34:46 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 14 Nov 2010 12:34:46 +0000
Subject: [issue10383] test_os leaks under Windows
In-Reply-To: <1289421086.3.0.902677944517.issue10383@psf.upfronthosting.co.za>
Message-ID: <1289738086.82.0.59751810376.issue10383@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I agree that the buffer should be released. The patch fixes this leak
and another one. All tests pass.

----------
keywords: +patch
nosy: +skrah
Added file: http://bugs.python.org/file19606/posixmodule_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10383>
_______________________________________

From report at bugs.python.org  Sun Nov 14 13:47:15 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 14 Nov 2010 12:47:15 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1289738835.36.0.627622537486.issue1553375@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note that after the loop over the values is complete, the final value of tb should correctly refer to the traceback for the exception currently being handled regardless of whether or not any chaining is involved.

So moving the stack printing code that is currently inside the loop after the loop should do the right thing.

With my suggested change in the display layout, I think this idea is still worthwhile (getting it right in handling code is tricky, especially if the exception is passed around before being displayed).

----------
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sun Nov 14 14:04:51 2010
From: report at bugs.python.org (Johannes Ammon)
Date: Sun, 14 Nov 2010 13:04:51 +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: <1289739891.46.0.690681439003.issue10417@psf.upfronthosting.co.za>


New submission from Johannes Ammon <johannes.ammon at gmail.com>:

When there is a non-ASCII character in the docstring of a test function, unittest triggers an UnicodeEncodeError when called with "--verbose".

I have this file unicodetest.py:
-----------------------------------------
# -*- coding: utf-8 -*-
import unittest

class UnicodeTest(unittest.TestCase):
    def test_unicode_docstring(self):
        u"""t?st - docstring with unicode character"""
        self.assertEqual(1+1, 2)

if __name__ == '__main__':
    unittest.main()
-----------------------------------------

Running it normally is ok:

$ python unicodetest.py 
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK


But with "--verbose" it breaks:

$ python unicodetest.py --verbose
Traceback (most recent call last):
  File "unicodetest.py", line 10, in <module>
    unittest.main()
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 817, in __init__
    self.runTests()
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 861, in runTests
    result = testRunner.run(self.test)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 753, in run
    test(result)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 464, in __call__
    return self.run(*args, **kwds)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 460, in run
    test(result)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 464, in __call__
    return self.run(*args, **kwds)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 460, in run
    test(result)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 300, in __call__
    return self.run(*args, **kwds)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 266, in run
    result.startTest(self)
  File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py", line 693, in startTest
    self.stream.write(self.getDescription(test))
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 1: ordinal not in range(128)


Found with Python 2.6 on MacOS X 10.6.4

----------
components: Tests, Unicode
messages: 121193
nosy: jammon
priority: normal
severity: normal
status: open
title: unittest triggers UnicodeEncodeError with non-ASCII character in the docstring of the test function
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Sun Nov 14 14:13:53 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 14 Nov 2010 13:13:53 +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: <1289740433.15.0.399664875022.issue10417@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Sun Nov 14 15:13:35 2010
From: report at bugs.python.org (Virgil Dupras)
Date: Sun, 14 Nov 2010 14:13:35 +0000
Subject: [issue10418] test_io hangs on 3.1.3rc1
In-Reply-To: <1289744014.96.0.667442029835.issue10418@psf.upfronthosting.co.za>
Message-ID: <1289744014.96.0.667442029835.issue10418@psf.upfronthosting.co.za>


New submission from Virgil Dupras <hsoft at hardcoded.net>:

I downloaded Python 3.1.3rc1 this morning to do my civic duty of testing it. I don't know what I'm doing wrong, but for me, test_io hangs and never completed. I'm on OS X 10.6.5. I ran it with:

$ ./python.exe Lib/test/regrtest.py test_io

And I got:

test_io

Testing large file ops skipped on darwin.
It requires 2147483648 bytes and a long time.
Use 'regrtest.py -u largefile test_io' to run it.

Testing large file ops skipped on darwin.
It requires 2147483648 bytes and a long time.
Use 'regrtest.py -u largefile test_io' to run it.
python.exe(12242) malloc: *** mmap(size=9223372036854775808) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
python.exe(12242) malloc: *** mmap(size=9223372036854775808) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
python.exe(12242) malloc: *** mmap(size=9223372036854775808) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
<hangs at this point>

I build Python with this configuration:

$ ./configure --enable-universalsdk=/ --enable-framework --with-universal-archs=intel

Oh, and it's being run as 64-bit.
By looking at the size being allocated, by guess that it's some kind of overflow thing or something.

----------
components: Tests
messages: 121194
nosy: vdupras
priority: release blocker
severity: normal
status: open
title: test_io hangs on 3.1.3rc1
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10418>
_______________________________________

From report at bugs.python.org  Sun Nov 14 15:28:35 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 14 Nov 2010 14:28:35 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1289744915.99.0.142681681941.issue9807@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Could you also fix issue #10262, which is related to this issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Sun Nov 14 16:29:10 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 14 Nov 2010 15:29:10 +0000
Subject: [issue10416] UnicodeDecodeError when 2to3 is run on a dir with numpy
	.npy files
In-Reply-To: <1289734445.75.0.657532915911.issue10416@psf.upfronthosting.co.za>
Message-ID: <1289748550.85.0.553758248915.issue10416@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r86464

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10416>
_______________________________________

From report at bugs.python.org  Sun Nov 14 16:47:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 14 Nov 2010 15:47:54 +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: <1289749674.02.0.251361289681.issue10417@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Is this a duplicate of #1293741?  That issue was closed as out of date, but I'm not 100% convinced that was the correct closure.  What do you think?

Does it still happen with 2.7?  (2.6 is in security fix only mode.)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Sun Nov 14 16:50:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 14 Nov 2010 15:50:51 +0000
Subject: [issue10418] test_io hangs on 3.1.3rc1
In-Reply-To: <1289744014.96.0.667442029835.issue10418@psf.upfronthosting.co.za>
Message-ID: <1289749851.35.0.823332190456.issue10418@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10418>
_______________________________________

From report at bugs.python.org  Sun Nov 14 16:52:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Nov 2010 15:52:25 +0000
Subject: [issue10418] test_io hangs on 3.1.3rc1
In-Reply-To: <1289744014.96.0.667442029835.issue10418@psf.upfronthosting.co.za>
Message-ID: <1289749945.02.0.377528961807.issue10418@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you run regrtest with the -v option, to know which test case fails?

(we have several OS X buildbots which run this test fine, by the way, including a Snow Leopard instance)

Note: 9223372036854775808 is 2**63 or 0x8000000000000000.

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10418>
_______________________________________

From report at bugs.python.org  Sun Nov 14 17:04:50 2010
From: report at bugs.python.org (Virgil Dupras)
Date: Sun, 14 Nov 2010 16:04:50 +0000
Subject: [issue10418] test_io hangs on 3.1.3rc1
In-Reply-To: <1289744014.96.0.667442029835.issue10418@psf.upfronthosting.co.za>
Message-ID: <1289750690.32.0.0682865670972.issue10418@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

I ran the test with the -v option flag. The malloc error don't happen at the same place the hang up happens. The first one happens at:

test_readline (test.test_io.PyIOTest) ... ok
test_unbounded_file (test.test_io.PyIOTest) ... skipped 'test can only run in a 32-bit address space'
test_with_open (test.test_io.PyIOTest) ... ok
test_buffering (test.test_io.CBufferedReaderTest) ... ok
test_constructor (test.test_io.CBufferedReaderTest) ... python.exe(24083) malloc: *** mmap(size=9223372036854775808) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
ok
test_context_manager (test.test_io.CBufferedReaderTest) ... ok
test_detach (test.test_io.CBufferedReaderTest) ... ok

And the second one happens at:

test_readlines (test.test_io.PyBufferedReaderTest) ... ok
test_repr (test.test_io.PyBufferedReaderTest) ... ok
test_threads (test.test_io.PyBufferedReaderTest) ... skipped "resource 'cpu' is not enabled"
test_constructor (test.test_io.CBufferedWriterTest) ... python.exe(24083) malloc: *** mmap(size=9223372036854775808) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
ok
test_context_manager (test.test_io.CBufferedWriterTest) ... ok
test_destructor (test.test_io.CBufferedWriterTest) ... ok

And finally, the hang:

test_io_after_close (test.test_io.CMiscIOTest) ... ok
test___all__ (test.test_io.PyMiscIOTest) ... ok
test_abc_inheritance (test.test_io.PyMiscIOTest) ... ok
test_abc_inheritance_official (test.test_io.PyMiscIOTest) ... ok
test_abcs (test.test_io.PyMiscIOTest) ... ok
test_attributes (test.test_io.PyMiscIOTest) ... ok
test_blockingioerror (test.test_io.PyMiscIOTest) ... ok
test_io_after_close (test.test_io.PyMiscIOTest) ... ok
test_interrupted_write_buffered (test.test_io.CSignalsTest) ... <hang>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10418>
_______________________________________

From report at bugs.python.org  Sun Nov 14 17:24:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 14 Nov 2010 16:24:39 +0000
Subject: [issue10418] test_io hangs on 3.1.3rc1
In-Reply-To: <1289750690.32.0.0682865670972.issue10418@psf.upfronthosting.co.za>
Message-ID: <1289751874.3725.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I ran the test with the -v option flag. The malloc error don't happen
> at the same place the hang up happens. The first one happens at:

The malloc error is normal, then, it's part of that test. It's a pity OS
X dumps something on stderr, though.

> And finally, the hang:
> 
> test_io_after_close (test.test_io.CMiscIOTest) ... ok
> test___all__ (test.test_io.PyMiscIOTest) ... ok
> test_abc_inheritance (test.test_io.PyMiscIOTest) ... ok
> test_abc_inheritance_official (test.test_io.PyMiscIOTest) ... ok
> test_abcs (test.test_io.PyMiscIOTest) ... ok
> test_attributes (test.test_io.PyMiscIOTest) ... ok
> test_blockingioerror (test.test_io.PyMiscIOTest) ... ok
> test_io_after_close (test.test_io.PyMiscIOTest) ... ok
> test_interrupted_write_buffered (test.test_io.CSignalsTest) ... <hang>

Ok. I guess you would need to investigate what happens in that
particular sub-test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10418>
_______________________________________

From report at bugs.python.org  Sun Nov 14 17:29:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 14 Nov 2010 16:29:56 +0000
Subject: [issue10413] Comments in unicode.h are out of date
In-Reply-To: <1289694856.74.0.857329002017.issue10413@psf.upfronthosting.co.za>
Message-ID: <4CE00E81.6060906@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
> 
> Attached patch updates some comments in unicode.h mostly reflecting the fact that the default encoding is now unconditionally UTF-8.

Looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10413>
_______________________________________

From report at bugs.python.org  Sun Nov 14 17:44:58 2010
From: report at bugs.python.org (Virgil Dupras)
Date: Sun, 14 Nov 2010 16:44:58 +0000
Subject: [issue10418] test_io hangs on 3.1.3rc1
In-Reply-To: <1289744014.96.0.667442029835.issue10418@psf.upfronthosting.co.za>
Message-ID: <1289753098.53.0.792175958776.issue10418@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

Nobody else can reproduce the bug? I'm not sure I can fix this (although I can try).

I tried to re-compile 3.1.2 with the same flags and run test_io and it passes, so something happened between 3.1.2 and 3.1.3rc1.

So, I'll give it a look, but if someone more experienced can reproduce it...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10418>
_______________________________________

From report at bugs.python.org  Sun Nov 14 17:58:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 14 Nov 2010 16:58:35 +0000
Subject: [issue10418] test_io hangs on 3.1.3rc1
In-Reply-To: <1289744014.96.0.667442029835.issue10418@psf.upfronthosting.co.za>
Message-ID: <1289753915.7.0.342267772224.issue10418@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ronald hasn't replied yet and he's the most likely to be in a position to try to reproduce it.

Even if you can't fix it, figuring out more about how that individual test is arriving at the hang could be useful.  If you've got the chops to look at the hang in a debugger that would be even more helpful.

----------
nosy: +ned.deily, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10418>
_______________________________________

From report at bugs.python.org  Sun Nov 14 18:19:35 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 14 Nov 2010 17:19:35 +0000
Subject: [issue10418] test_io hangs on 3.1.3rc1
In-Reply-To: <1289744014.96.0.667442029835.issue10418@psf.upfronthosting.co.za>
Message-ID: <1289755175.11.0.494449984492.issue10418@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Be careful when running a framework build from the build directory without installing it.  Chances are you are actually dynamically linking to an older existing framework in /Library/Frameworks.  (Try looking at sys.modules to see what I mean.)  You'll either need to temporarily move the old fw out of the way and do the install or use a different fw path to configure or don't use a fw build.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10418>
_______________________________________

From report at bugs.python.org  Sun Nov 14 18:28:09 2010
From: report at bugs.python.org (Virgil Dupras)
Date: Sun, 14 Nov 2010 17:28:09 +0000
Subject: [issue10418] test_io hangs on 3.1.3rc1
In-Reply-To: <1289744014.96.0.667442029835.issue10418@psf.upfronthosting.co.za>
Message-ID: <1289755689.66.0.88495150103.issue10418@psf.upfronthosting.co.za>


Virgil Dupras <hsoft at hardcoded.net> added the comment:

Ooh, darn, that was it. I installed it and afterwards, the tests passed.

Sorry for the fuss, I'll keep that gotcha in mind next time.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10418>
_______________________________________

From report at bugs.python.org  Sun Nov 14 19:04:55 2010
From: report at bugs.python.org (Johannes Ammon)
Date: Sun, 14 Nov 2010 18:04:55 +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: <1289757895.39.0.0932494435213.issue10417@psf.upfronthosting.co.za>


Johannes Ammon <johannes.ammon at gmail.com> added the comment:

Same behaviour with 2.7

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Sun Nov 14 21:32:33 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Sun, 14 Nov 2010 20:32:33 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>


New submission from Hagen F?rstenau <hagen at zhuliguan.net>:

As suggested in issue 9561, I'm creating a new bug for the encoding problem in build_scripts: If a script file can't be decoded with the (locale dependent) standard encoding, then "build_scripts" fails with UnicodeDecodeError. Reproducable e.g. with LANG=C and a script file containing non ASCII chars near the beginning (so that they're read on a single readline()).

Attaching a patch that uses "surrogateescape", as proposed for issue 6011.

----------
assignee: tarek
components: Distutils
files: surrogateescape.patch
keywords: patch
messages: 121207
nosy: eric.araujo, hagen, tarek
priority: normal
severity: normal
status: open
title: distutils command build_scripts fails with UnicodeDecodeError
type: crash
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19607/surrogateescape.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Sun Nov 14 22:20:48 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 14 Nov 2010 21:20:48 +0000
Subject: [issue2405] Drop w9xpopen and all dependencies
In-Reply-To: <1205870969.55.0.774025556957.issue2405@psf.upfronthosting.co.za>
Message-ID: <1289769648.77.0.246288582322.issue2405@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It is still time to add to 3.2 a DeprecationWarning when w9xpopen is used, and remove the feature in 3.3.
See attached patch

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file19608/deprecate-w9xpopen.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2405>
_______________________________________

From report at bugs.python.org  Sun Nov 14 22:38:18 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 14 Nov 2010 21:38:18 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1289770698.96.0.197646876863.issue1553375@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I've implemented an optional keyword argument stack_info (defaulting to False) for all logging calls. If specified as True, a line 

Stack (most recent call last):

is printed, followed by the output of traceback.print_stack(). This is output after any exception information.

Checked into py3k (r86467), please can interested parties check if it meets the logging use case mentioned when the ticket was created?

Regression tests pass OK, and docs updated in this checkin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sun Nov 14 22:40:51 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 14 Nov 2010 21:40:51 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1289770851.41.0.0664358857219.issue1553375@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Re. the change in r86467, you can test using this simple script:

http://pastebin.com/ZXs3sXDW

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Mon Nov 15 00:01:14 2010
From: report at bugs.python.org (INADA Naoki)
Date: Sun, 14 Nov 2010 23:01:14 +0000
Subject: [issue10420] Document of Bdb.effective is wrong.
In-Reply-To: <1289775674.64.0.742644713798.issue10420@psf.upfronthosting.co.za>
Message-ID: <1289775674.64.0.742644713798.issue10420@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/library/bdb.html#bdb.effective

>Determine if there is an effective (active) breakpoint at this line of code.
>Return breakpoint number or 0 if none.

bdb.effective doesn't return 0. If no breakpoint is found, it returns
(None, None).

----------
assignee: docs at python
components: Documentation
messages: 121211
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Document of Bdb.effective is wrong.
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/issue10420>
_______________________________________

From report at bugs.python.org  Mon Nov 15 00:30:46 2010
From: report at bugs.python.org (admin)
Date: Sun, 14 Nov 2010 23:30:46 +0000
Subject: [issue10421] Failed issue tracker submission
In-Reply-To: <20101114233044.91B391DB89@psf.upfronthosting.co.za>
Message-ID: <20101114233044.91B391DB89@psf.upfronthosting.co.za>


New submission from admin <roundup-admin at psf.upfronthosting.co.za>:

You are not a registered user.

Unknown address: Order Real Pfizer <tracker at psf.upfronthosting.co.za>

----------
files: unnamed
messages: 121212
nosy: admin
priority: normal
severity: normal
status: open
title: Failed issue tracker submission
Added file: http://bugs.python.org/file19609/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10421>
_______________________________________
-------------- next part --------------
Return-Path: <tracker at psf.upfronthosting.co.za>
X-Original-To: tracker at psf.upfronthosting.co.za
Delivered-To: tracker at psf.upfronthosting.co.za
Received: from [190.232.74.29] (unknown [190.232.74.29])
	by psf.upfronthosting.co.za (Postfix) with ESMTP id 911921DE56
	for <tracker at psf.upfronthosting.co.za>; Mon, 15 Nov 2010 00:30:42 +0100 (CET)
From: "Order Real Pfizer <tracker at psf.upfronthosting.co.za>
To: tracker at psf.upfronthosting.co.za
Reply-To: tracker at psf.upfronthosting.co.za
Subject: Hi tracker, Best Deals. of advent were
Mime-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: <20101114233043.911921DE56 at psf.upfronthosting.co.za>
Date: Mon, 15 Nov 2010 00:30:42 +0100 (CET)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Newsletter</title>
</head>
<body>
<table width="650" cellspacing="0" cellpadding="0" bgcolor="#F2F2F2" align="center">
	<tr>
    	<td height="52" style="text-align:center;">
		<span style="color:#464646; font-size:10px; font-family:arial, helvetica, sans-serif;">View <a href="http://youve.demedics.ru/?94e8CA7dE5856" style="color:#0093D9;">Mobile</a> | View
		<a href="http://ado.demedics.ru/?23ed94aB61C" style="color:#0093D9;">Webpage</a></span></td>
    </tr>
    <tr>
    	<td>
        	<table width="600" bgcolor="#FFFFFF" cellspacing="0" cellpadding="0" align="center">
            	<tr>
                	<td style="text-align: center">
                    	<a href="http://ho.demedics.ru/?be6b30bBAD37E">
                    	<img alt="Cheapest Pills. Click here" src="http://b.demedics.ru/vue.jpg" style="border-width: 0px"></a></td>
                </tr>
			</table>
            <table width="600" bgcolor="#F2F2F2" cellspacing="0" cellpadding="0" align="center">
                <tr>
                	<td height="27"> </td>
                </tr>
            	<tr>
   	  				<td align="left">
                        <font color="#A2A2A2" face="arial, helvetica, sans-serif" size="1">
                        	PLEASE DO NOT REPLY TO THIS MESSAGE.<br>
                        	This is a system-generated Newsletter email. Replies will not be read or forwarded for handling.<br><br>
                        This message was sent to tracker at psf.upfronthosting.co.za.<br><br>
                            <a href="http://lelim.demedics.ru/?4855711607" style="color:#817979;">Contact Us</a> |
                            <a href="http://yn.demedics.ru/?3B3d0AeC42ba61&remove=tracker at psf.upfronthosting.co.za" style="color:#817979;">Unsubscribe</a> |
                            <a href="http://iibe.demedics.ru/?969972df718296E4" style="color:#817979;">Update Email Address</a> |
                            <a href="http://pele.demedics.ru/?08D96a30dEf400B7" style="color:#817979;">Privacy Policy</a><br><br>
                            Copyright 2010 leadership of Warrior. All rights reserved.
                        </font>
                    </td>
                </table>
        </td>
    </tr>
</table>
<IMG SRC="http://www.hufisymawa.com/55f8dc5160986988F81ca99e7f7C6fb6e15380bAA67AB"></body>
</html>

From report at bugs.python.org  Mon Nov 15 02:19:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 15 Nov 2010 01:19:49 +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: <1289783989.45.0.980528080637.issue10417@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/issue10417>
_______________________________________

From report at bugs.python.org  Mon Nov 15 02:22:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 15 Nov 2010 01:22:31 +0000
Subject: [issue10421] Failed issue tracker submission
In-Reply-To: <20101114233044.91B391DB89@psf.upfronthosting.co.za>
Message-ID: <1289784151.71.0.129595260971.issue10421@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy:  -admin
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10421>
_______________________________________

From report at bugs.python.org  Mon Nov 15 02:22:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 15 Nov 2010 01:22:39 +0000
Subject: [issue10421] Failed issue tracker submission
In-Reply-To: <20101114233044.91B391DB89@psf.upfronthosting.co.za>
Message-ID: <1289784159.11.0.265783438214.issue10421@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19609/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10421>
_______________________________________

From report at bugs.python.org  Mon Nov 15 02:38:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 15 Nov 2010 01:38:16 +0000
Subject: [issue2571] cmd.py always uses raw_input,
	even when another stdin is specified
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1289785096.02.0.796830657843.issue2571@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: closed -> open
type:  -> feature request
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Mon Nov 15 02:51:51 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Mon, 15 Nov 2010 01:51:51 +0000
Subject: [issue7140] imp.new_module does not function correctly if the module
	is returned from a function and used directly
In-Reply-To: <1255605892.23.0.543488610886.issue7140@psf.upfronthosting.co.za>
Message-ID: <1289785911.1.0.778682971569.issue7140@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

But there were r85393 (2.7) and r85394 (3.1).

----------
nosy: +Arfrever
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7140>
_______________________________________

From report at bugs.python.org  Mon Nov 15 05:04:36 2010
From: report at bugs.python.org (Jessica McKellar)
Date: Mon, 15 Nov 2010 04:04:36 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	relative dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1289793876.46.0.757680234219.issue7325@psf.upfronthosting.co.za>


Jessica McKellar <jesstess at mit.edu> added the comment:

Thomas, I think the weirdness you were sensing when trying to adapt the nameCheck calls in test__RandomNameSequence after adding the abspath check is that those test cases really don't need nameCheck.

For example, test_get_six_char_str should be testing that _RandomNameSequence returns something that is both a string and 6 characters, not properties of some path manufactured around it.

I've attached a patch based on Thomas's that factors out the string check in nameCheck and has the tests in test__RandomNameSequence just use the string check.

The patch is against release27-maint.

----------
nosy: +jesstess
title: tempfile.mkdtemp() does not return absolute pathname when dir is specified -> tempfile.mkdtemp() does not return absolute pathname when relative dir is specified
Added file: http://bugs.python.org/file19610/issue7325.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Mon Nov 15 08:16:02 2010
From: report at bugs.python.org (=?utf-8?q?Hagen_F=C3=BCrstenau?=)
Date: Mon, 15 Nov 2010 07:16:02 +0000
Subject: [issue9561] distutils: set encoding to utf-8 for input and output
	files
In-Reply-To: <1281462699.26.0.0348702049008.issue9561@psf.upfronthosting.co.za>
Message-ID: <1289805362.44.0.0987249033755.issue9561@psf.upfronthosting.co.za>


Hagen F?rstenau <hagen at zhuliguan.net> added the comment:

Created issue 10419 for the encoding problem in "build_scripts".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Mon Nov 15 09:13:31 2010
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Mon, 15 Nov 2010 08:13:31 +0000
Subject: [issue10419] distutils command build_scripts fails with
	UnicodeDecodeError
In-Reply-To: <1289766753.91.0.865805184241.issue10419@psf.upfronthosting.co.za>
Message-ID: <1289808811.24.0.987765642258.issue10419@psf.upfronthosting.co.za>


Changes by Micha? G?rny <mgorny at gentoo.org>:


----------
nosy: +mgorny

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10419>
_______________________________________

From report at bugs.python.org  Mon Nov 15 09:42:30 2010
From: report at bugs.python.org (Stephane Ruchet)
Date: Mon, 15 Nov 2010 08:42:30 +0000
Subject: [issue10422] pstats.py : error when loading multiple stats files
In-Reply-To: <1289810550.6.0.241071976053.issue10422@psf.upfronthosting.co.za>
Message-ID: <1289810550.6.0.241071976053.issue10422@psf.upfronthosting.co.za>


New submission from Stephane Ruchet <sruchet at parkeon.com>:

When using pstats constructor with multiple files, the add_callers method fails. Actually, add_callers need to add values of tuples, but it uses the "+" operator, that appends tuples.

I submit the fix (pstats.py.fix file) and the old one (pstats.py.bug.2.5)

----------
components: Library (Lib)
files: pstats.zip
messages: 121216
nosy: sruchet
priority: normal
severity: normal
status: open
title: pstats.py : error when loading multiple stats files
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file19611/pstats.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10422>
_______________________________________

From report at bugs.python.org  Mon Nov 15 09:49:18 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Nov 2010 08:49:18 +0000
Subject: [issue10422] pstats.py : error when loading multiple stats files
In-Reply-To: <1289810550.6.0.241071976053.issue10422@psf.upfronthosting.co.za>
Message-ID: <1289810958.24.0.784331027804.issue10422@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This bug should already be fixed in Python 2.6 and 2.7 (see #7372) and 2.5 now accepts only security fixes.
I suggest you to upgrade to a newer version of Python.
(BTW, thanks for the report and the patch, but it's usually better to avoid zip files and prefer plain diff files)

----------
nosy: +ezio.melotti
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10422>
_______________________________________

From report at bugs.python.org  Mon Nov 15 09:59:24 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 15 Nov 2010 08:59:24 +0000
Subject: [issue10350] errno is read too late
In-Reply-To: <1289590332.36.0.347389142952.issue10350@psf.upfronthosting.co.za>
Message-ID: <hbf.20101115sxfh@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Terry J. Reedy writes:
> There is one relocation of memory freeing

Modules/timemodule.c does '#if,if(..errno..)' after PyMem_Free(outbuf),
which can overwrite the desired errno.  Instead of reading errno into
a temporary, I moved the free into both branches taken by the #if,if().

> and the additions of
> +        if (res >= 0)
> +            break;
> which I cannot evaluate.

errno is only needed after an error., so I moved 'res < 0' out of the
'while'.
        if (res == MP_EXCEPTION_HAS_BEEN_SET) break;
    } while (res < 0 && errno == EINTR && !PyErr_CheckSignals());
-->
        if (res == MP_EXCEPTION_HAS_BEEN_SET) break;
        if (! (res < 0))                      break;
    } while (errno == EINTR && !PyErr_CheckSignals());
-->
        if (res >= 0)                         break;
        err = errno;
        if (res == MP_EXCEPTION_HAS_BEEN_SET) break;
    } while (err == EINTR && !PyErr_CheckSignals());

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10350>
_______________________________________

From report at bugs.python.org  Mon Nov 15 11:30:35 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 15 Nov 2010 10:30:35 +0000
Subject: [issue10423] s/args/options in arpgarse "Upgrading optparse code"
In-Reply-To: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>
Message-ID: <1289817035.63.0.362408496183.issue10423@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

>From a personal email:

----------------------------------------------------------------------
I'm not signed up for all the Python issue tracking stuff, but thought I'd let you know about a problem with the argparse doc page:

     http://docs.python.org/library/argparse.html

It says at the end:

     Replace options, args = parser.parse_args() with args = parser.parse_args() and add additional ArgumentParser.add_argument() calls for the positional arguments.

But I think it should be options = parser.parse_args(), not args.
----------------------------------------------------------------------

They're not options, so I don't like encouraging people to continue to call them options, but the docs should at least make clear that the namespace object that used to be called "options" is now called "args".

----------
assignee: docs at python
components: Documentation
messages: 121219
nosy: bethard, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: s/args/options in arpgarse "Upgrading optparse code"
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10423>
_______________________________________

From report at bugs.python.org  Mon Nov 15 11:38:44 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 15 Nov 2010 10:38:44 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>


New submission from Steven Bethard <steven.bethard at gmail.com>:

>From a private email in respect to the following class of error messages:

>>> parser = argparse.ArgumentParser(prog='PROG')
>>> parser.add_argument('--foo')
>>> parser.add_argument('--bar')
>>> parser.add_argument('ham')
>>> parser.add_argument('spam', nargs='+')
>>> parser.parse_args(['HAM'])
usage: PROG [-h] [--foo FOO] [--bar BAR] ham spam [spam ...]
PROG: error: too few arguments

----------------------------------------------------------------------
One suggestion would be that when it displays the error "too few arguments", it would nice if it said something about the argument(s) that are missing.

I modified argparse's error message when there are too few arguments.  I didn't examine the code a lot, so there might be cases where this doesn't work, but here's what I did:

    if positionals:
        self.error(_('too few arguments: %s is required' % positionals[0].dest))
----------------------------------------------------------------------

This would be a nice feature - I haven't checked if the suggested approach works in general though.

----------
components: Library (Lib)
messages: 121220
nosy: bethard
priority: normal
severity: normal
stage: needs patch
status: open
title: better error message from argparse when positionals missing
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Mon Nov 15 12:17:03 2010
From: report at bugs.python.org (Palm Kevin)
Date: Mon, 15 Nov 2010 11:17:03 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <1289819823.22.0.648639065195.issue1326113@psf.upfronthosting.co.za>


Palm Kevin <kevin.palm at labsolution.lu> added the comment:

This one is really annoying. Could you please consider fixing this one for the next release? (=lightweight change)

----------
nosy: +palm.kevin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Mon Nov 15 12:31:13 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 15 Nov 2010 11:31:13 +0000
Subject: [issue1520831] urrlib2 max_redirections=0 disables redirects
Message-ID: <1289820673.04.0.862907524646.issue1520831@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

John, I was trying to find out what does rfc say on "Client Ignoring the 30X REDIRECT headers". There is no point made on Client's trying to ignore it, instead it said that it should follow the Redirect and must not endlessly loop.

Setting max_redirect to 0 is similar to ignoring the redirect request , which I found to be a bad idea under any case.

Also, if one has to just see redirect urls coming from http server, it can be done by subclassing the HTTPRedirectHandler and logging the redirects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1520831>
_______________________________________

From report at bugs.python.org  Mon Nov 15 12:37:39 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 15 Nov 2010 11:37:39 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <1289821059.89.0.0912313497907.issue1326113@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Distutils is frozen and we fix only bugs. This case is a little bit at the edge. 

Can you show us an example of a call you are trying to make, and the gcc command line output that fails ? 

I want to see if we can find a workaround. If so, this will be changed only in Distutils2. If not I'll change this to a bug and we'll fix it in distutils too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Mon Nov 15 13:27:17 2010
From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=)
Date: Mon, 15 Nov 2010 12:27:17 +0000
Subject: [issue10425] xmlrpclib support for None isn't compliant with XMLRPC
In-Reply-To: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>
Message-ID: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>


New submission from Adam Biela?ski <abgans at gmail.com>:

XMLRPC standard doesn't support None/nil/null values. Element `<nil/>` was added as an extension to original protocol.

Currently sending None object through xmlrpclib produces `<value><nil/></value>` string. This causes parsing errors in more sophisticated XMLRPC parsers (like org.apache.xmlrpc for Java) which require `<nil/>` element to be declared in namespace for extensions: xmlns:ex='http://ws.apache.org/xmlrpc/namespaces/extensions'

Attached patch makes xmlrpclib use that namespace for sending None values both in method calls and responses, so None value might be passed both ways. It isn't bound to use fixed prefix for extensions namespace and it also parses XML produced by original xmlrpclib (without any namespace at all), so it is backward compatible.

It does its job communicating with org.apache.xmlrpc library now, using default parser on the Python side which is an improvement to original version, so I'd like to see it included in the next Python 2.x release, if possible.

----------
components: Library (Lib), XML
files: xmlrpclib.diff
keywords: patch
messages: 121224
nosy: Adam.Biela?ski
priority: normal
severity: normal
status: open
title: xmlrpclib support for None isn't compliant with XMLRPC
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19612/xmlrpclib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10425>
_______________________________________

From report at bugs.python.org  Mon Nov 15 13:31:28 2010
From: report at bugs.python.org (Palm Kevin)
Date: Mon, 15 Nov 2010 12:31:28 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <1289824288.81.0.180576538796.issue1326113@psf.upfronthosting.co.za>


Palm Kevin <kevin.palm at labsolution.lu> added the comment:

I applied the patch proposed by slanger. This one is working.
Now, I'm executing this instruction to build my extension:
"%pythonRoot%\python.exe" setup.py build_ext --include-dirs "C:\MyApp\include" --library-dir "C:\MyApp\lib" --libraries "myLib1 myLib2"
If I don't use the patch, then the error I get is 'unresolved external symbol _xxx referenced in function _abc'. Which is quite normal since I can only point to one library...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Mon Nov 15 13:59:40 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 15 Nov 2010 12:59:40 +0000
Subject: [issue10425] xmlrpclib support for None isn't compliant with XMLRPC
In-Reply-To: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>
Message-ID: <1289825980.91.0.748205106155.issue10425@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10425>
_______________________________________

From report at bugs.python.org  Mon Nov 15 14:53:46 2010
From: report at bugs.python.org (Joshua Purcell)
Date: Mon, 15 Nov 2010 13:53:46 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1289829226.57.0.848539961487.issue6941@psf.upfronthosting.co.za>


Joshua Purcell <spamail.08jpurcellserver at gmail.com> added the comment:

Sorry I've not replied to anyones thoughts until now but nothing seems to fix it

----------
components: +Windows -IDLE
resolution: works for me -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Mon Nov 15 15:06:58 2010
From: report at bugs.python.org (Joshua Purcell)
Date: Mon, 15 Nov 2010 14:06:58 +0000
Subject: [issue10426] The whole thing is NOT good
In-Reply-To: <1289830018.45.0.962254835691.issue10426@psf.upfronthosting.co.za>
Message-ID: <1289830018.45.0.962254835691.issue10426@psf.upfronthosting.co.za>


New submission from Joshua Purcell <spamail.08jpurcellserver at gmail.com>:

There is a complete FAIL in this versionand all other versions like 3.*
THEY ALL FREEZE UP MY SYSTEM (Windows) HELP

----------
components: Windows
messages: 121227
nosy: 08jpurcell
priority: normal
severity: normal
status: open
title: The whole thing is NOT good
type: crash
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10426>
_______________________________________

From report at bugs.python.org  Mon Nov 15 15:11:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 15 Nov 2010 14:11:06 +0000
Subject: [issue10426] The whole thing is NOT good
In-Reply-To: <1289830018.45.0.962254835691.issue10426@psf.upfronthosting.co.za>
Message-ID: <1289830266.12.0.213365277464.issue10426@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10426>
_______________________________________

From report at bugs.python.org  Mon Nov 15 15:17:55 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Nov 2010 14:17:55 +0000
Subject: [issue10426] The whole thing is NOT good
In-Reply-To: <1289830018.45.0.962254835691.issue10426@psf.upfronthosting.co.za>
Message-ID: <1289830675.89.0.856219113.issue10426@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm closing this until you can provide more details about the problem you have.

What version of Python have you used? (The one you selected (3.3) doesn't exist yet.)
Are you sure that the problem is related to Python and not to Windows? If it is, how did you determine it? Is Python or Windows giving you any specific error?

----------
nosy: +ezio.melotti
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10426>
_______________________________________

From report at bugs.python.org  Mon Nov 15 15:23:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 15 Nov 2010 14:23:46 +0000
Subject: [issue7186] Document specialness of __doc__,
	and possibly other "special" attributes
In-Reply-To: <1256240855.61.0.550470965616.issue7186@psf.upfronthosting.co.za>
Message-ID: <1289831026.96.0.451424652126.issue7186@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, because that patch doesn't document the special inheritance rules for __doc__ (which are uniquely special even among special methods).  Now, exactly where one would want to document those rules, I'm not sure.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7186>
_______________________________________

From report at bugs.python.org  Mon Nov 15 15:38:00 2010
From: report at bugs.python.org (ingo janssen)
Date: Mon, 15 Nov 2010 14:38:00 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>
Message-ID: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>


New submission from ingo janssen <ingoogni at gmail.com>:

Short:
make the DateTime class and related also accept 24 for the hour instead of stopping at 23:59:59.

from the python doc:

"class datetime.datetime(year, month, day[, hour[, minute[, second[,
microsecond[, tzinfo]]]]])
The year, month and day arguments are required. tzinfo may be None, or
an instance of a tzinfo subclass. The remaining arguments may be ints
or longs, in the following ranges:
[...]
0 <= hour < 24
[...]
If an argument outside those ranges is given, ValueError is raised."


from http://en.wikipedia.org/wiki/ISO_8601 :

"ISO 8601 uses the 24-hour clock system. The basic format is
[hh][mm][ss] and the extended format is [hh]:[mm]:[ss].

* [hh] refers to a zero-padded hour between 00 and 24 (where 24 is
only used to notate midnight at the end of a calendar day).
[...]
Midnight is a special case and can be referred to as both "00:00" and
"24:00". The notation "00:00" is used at the beginning of a calendar
day and is the more frequently used. At the end of a day use "24:00".
Note that "2007-04-05T24:00" is the same instant as "2007-04-06T00:00"
(see Combined date and time representations below)."

The use of 24:00 is very comfortable when using hourly datasets, the
first set of a day is saved under 1:00, the fifth (4:00 to 5:00) under
5:00 and the last (23:00 - 24:00) under 24:00. No need to suddenly use
23:59:59 or 0:00 the next day. 

Actually in another part of Python SQLlite's date and time functions accept and outputs the 24:00. Adding some Python to an existing database made me aware of the problem.

----------
messages: 121230
nosy: ingo.janssen
priority: normal
severity: normal
status: open
title: 24:00 Hour in DateTime
type: feature request
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10427>
_______________________________________

From report at bugs.python.org  Mon Nov 15 15:39:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Nov 2010 14:39:12 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1289701235.85.0.963473343851.issue10260@psf.upfronthosting.co.za>
Message-ID: <1289831942.3553.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Good point, Antoine.  I'm always trying to keep those timeouts low,
> however, to avoid having the testsuite duration grow too much with
> every test :)

Well, better to have slower tests than intermittently failing ones, I
say.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10260>
_______________________________________

From report at bugs.python.org  Mon Nov 15 15:41:30 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Nov 2010 14:41:30 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>
Message-ID: <1289832090.57.0.90612828552.issue10427@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
components: +Library (Lib)
nosy: +belopolsky, ezio.melotti
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10427>
_______________________________________

From report at bugs.python.org  Mon Nov 15 15:51:07 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 15 Nov 2010 14:51:07 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <4CDDD907.4030906@v.loewis.de>
Message-ID: <hbf.20101115z9dv@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Martin v. L?wis writes:
> As this code is in a Python 2.x block: why does this change cause
> problems to you? You are supposed to run the 2to3 result in Python 3,
> and this conversion result will run correctly in Python 3.

As I've explained, and as the if-statement and the associated comment
expresses, that piece of code is intended to work with both Python 2
and 3.

2to3 turns it into code which would break on Python 2.  I've explained
why I'd run 2to3 on such code, and thus why it'd be convenient if I
could ask 2to3 to leave such code alone.  So I requested this feature.
I don't know exactly how I'm "supposed" to use 2to3.  If you are its
inventor, you do.  Otherwise it may also be supposed to suit other
workflows than yours.

> Ok, I can propose two different spellings of this without any
> macro processor: (...)

Both your examples fit my request perfectly.  Pieces of code which I
presume are correct for both Python 2 and 3, and 2to3 break them for
both Python versions.  With "my" feature, the code would keep working
with both.

However, it is true that there are other cases where I'd like to shut
up 2to3 but where my suggested solution would not be convenient to
use.  I am after all requesting a mere convenience feature, and aimed
for something I hoped would be a simple matter to implement.  I never
imagined that merely explaining it would grow into such a discussion.

Bobby, thanks for the sa2to3 reference.  Doesn't quite do what I
wanted, but looks useful and might also be a good starting point for
what I did ask for.  Hopefully I won't need to understand too much
2to3 code first...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Mon Nov 15 15:53:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 15 Nov 2010 14:53:17 +0000
Subject: [issue7186] Document specialness of __doc__,
	and possibly other "special" attributes
In-Reply-To: <1256240855.61.0.550470965616.issue7186@psf.upfronthosting.co.za>
Message-ID: <1289832797.82.0.739261215348.issue7186@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/issue7186>
_______________________________________

From report at bugs.python.org  Mon Nov 15 15:57:42 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 15 Nov 2010 14:57:42 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <hbf.20101115z9dv@bombur.uio.no>
Message-ID: <hbf.20101115zdmq@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Hallvard B Furuseth writes:
>Martin v. L?wis writes:
>> Ok, I can propose two different spellings of this without any
>> macro processor: (...)
> 
> Both your examples fit my request perfectly.  Pieces of code which I
> presume are correct for both Python 2 and 3, (...)

Sorry, ignore that.  I "saw" you doing what I would be doing, not what
you were doing...  Not example A.  And Example B looks (to me) like it
is intended to work unmodified for both Python 2 and 3, but doesn't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Mon Nov 15 16:24:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 15 Nov 2010 15:24:34 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>
Message-ID: <1289834674.31.0.433282212685.issue10427@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

+1

Note that in Python, semi-open intervals are favored, but specifying the last hour of the day is awkward when using datetime (as OP mentioned) and impossible using just time.  Using closed intervals is not a good work-around in many cases because it requires the user to be explicit about precision:  is the last hour [23:00-23:59], [23:00:00-23:59:00], or [23:00:00.999999-23:59:00.999999]?

I offer to write the patch for the C implementation if someone comes up with a patch for datetime.py including tests.

----------
assignee:  -> belopolsky
components: +Extension Modules
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10427>
_______________________________________

From report at bugs.python.org  Mon Nov 15 16:43:37 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 15 Nov 2010 15:43:37 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1289567756.65.0.0739373793952.issue10070@psf.upfronthosting.co.za>
Message-ID: <hbf.20101115a7fq@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

?ric Araujo writes:
> I think 2to3 is designed to take 2.x code and turn it into 3.x code.
> Codebases using tricks and hacks to support both 2.x and 3.x (like the
> example you linked to) cannot be handled by 2to3.

That's fair enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Mon Nov 15 17:26:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 15 Nov 2010 16:26:23 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <1289838383.16.0.390536887512.issue1326113@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Since "--libraries" is plural, and since the help text says:

--libraries (-l)     external C libraries to link with

it should IMO be considered a bug.

(Standard UNIX linkers have a different convention: you can specify -l several times in order to link against several libraries; however, distutils seems to ignore all but the last -l option)

----------
nosy: +eric.araujo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Mon Nov 15 18:55:03 2010
From: report at bugs.python.org (Ron Adam)
Date: Mon, 15 Nov 2010 17:55:03 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1289843703.32.0.336880844024.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

This should be done or very close to done.

The -g option, gui(), and serve() functions are deprecated.

The new features are browse(port, *, open_browser=True), and a '-b' option.  The '-p port' option does browse(port=port, open_browser=False), so _startserver() does not need to be part of the API.  If anyone wants to access the server directly, then we can discuss making it it's own module, or a submodule in a package.

Because we deprecated the gui() function, I figured we need to make browse() public.  The only reason it would need to be private is if we want a different name or signature.  (Any thoughts?)

I left Lib/urllib/parse.py, Lib/test/test_pyclbr.py, and Lib/test/test_urlparse.py alone.  I presumed you fixed bugs in them that needed to be fixed anyway.

----------
Added file: http://bugs.python.org/file19613/issue2001_b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Mon Nov 15 18:55:28 2010
From: report at bugs.python.org (Ron Adam)
Date: Mon, 15 Nov 2010 17:55:28 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1289843728.97.0.995504516627.issue2001@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file19604/issue2001_a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Mon Nov 15 18:55:47 2010
From: report at bugs.python.org (Ron Adam)
Date: Mon, 15 Nov 2010 17:55:47 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1289843747.54.0.92448448795.issue2001@psf.upfronthosting.co.za>


Changes by Ron Adam <ron_adam at users.sourceforge.net>:


Removed file: http://bugs.python.org/file19476/pydoc_r86133.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Mon Nov 15 19:24:46 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Mon, 15 Nov 2010 18:24:46 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1289845486.02.0.702888943634.issue1553375@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

I dont understand, if we use traceback.print_stack(), it's the stack at the exception handling point which will be displayed.

In my view, the interesting think was not the stack trace at the point where the exception is being handled, but where the unwinding stopped (i.e, a snapshot of the stack at the moment the exception was caught).

I agree that most of the time these stacks are quite close, but if you happen to move the traceback object all around, in misc. treatment functions (or even, if it has been returned by functions to their caller - let's be fool), it can be handy to still be able to output a full exception stack, like if the exception had flowed up to the root of the program. At least that's what'd interest me for debugging.

try:
   myfunction() #<- that's the point of which I'd likle a stack trace
except Exception, e:
   handle_my_exception(e) #<- not of that point, some recursion levels deeper

Am I the only one viewing it as this ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Mon Nov 15 19:54:26 2010
From: report at bugs.python.org (David Fraser)
Date: Mon, 15 Nov 2010 18:54:26 +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: <1289847266.36.0.555302972896.issue8863@psf.upfronthosting.co.za>


Changes by David Fraser <davidf at sjsoft.com>:


----------
nosy: +davidfraser

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Mon Nov 15 20:23:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 15 Nov 2010 19:23:28 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1289849008.33.0.821361016909.issue1553375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree with you, Pascal, but I think Nick is saying that that information is not actually available.  I don't fully understand why, but he knows vastly more about Python internals than I do so I'll take his word for it.

It might be interesting to try saving the traceback and printing out the allframes traceback elsewhere, since that should prove to you and I that it doesn't work :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Mon Nov 15 21:49:51 2010
From: report at bugs.python.org (Eli)
Date: Mon, 15 Nov 2010 20:49:51 +0000
Subject: [issue10428] IDLE Trouble shooting
In-Reply-To: <1289854191.01.0.577719650425.issue10428@psf.upfronthosting.co.za>
Message-ID: <1289854191.01.0.577719650425.issue10428@psf.upfronthosting.co.za>


New submission from Eli <eliandkatie at acsalaska.net>:

I am having trouble with python. I use python 2.5.1, and have windows 7.
I used to be able to use IDLE, but now it says its opening and it never does. I also could use recovery to fix it. but that does not work now. Any Ideas?

----------
components: Windows
messages: 121240
nosy: creat0r
priority: normal
severity: normal
status: open
title: IDLE Trouble shooting
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10428>
_______________________________________

From report at bugs.python.org  Mon Nov 15 21:55:31 2010
From: report at bugs.python.org (John J Lee)
Date: Mon, 15 Nov 2010 20:55:31 +0000
Subject: [issue1520831] urrlib2 max_redirections=0 disables redirects
Message-ID: <1289854531.87.0.504179043601.issue1520831@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

That's silly.  A justification of the need for a new feature isn't needed, because this is already-implemented feature that simply does the wrong thing at the edge case.

It's not high priority, but it is a bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1520831>
_______________________________________

From report at bugs.python.org  Mon Nov 15 22:00:01 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 15 Nov 2010 21:00:01 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1289667415.01.0.560899036562.issue3871@psf.upfronthosting.co.za>
Message-ID: <4CE19F4B.2010408@roumenpetrov.info>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

But different build system make new plaform !

Roumen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Mon Nov 15 22:09:16 2010
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 15 Nov 2010 21:09:16 +0000
Subject: [issue10319] SocketServer.TCPServer truncates responses on close (in
	some situations)
In-Reply-To: <1288935519.72.0.951711716225.issue10319@psf.upfronthosting.co.za>
Message-ID: <1289855356.19.0.00906818201032.issue10319@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10319>
_______________________________________

From report at bugs.python.org  Mon Nov 15 22:10:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 15 Nov 2010 21:10:13 +0000
Subject: [issue10428] IDLE Trouble shooting
In-Reply-To: <1289854191.01.0.577719650425.issue10428@psf.upfronthosting.co.za>
Message-ID: <1289855413.04.0.485270856855.issue10428@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I would recommend posting to the python mailing list (see mail.python.org for a list of the mailing lists and subscribe to python-list).  The bug tracker isn't a place to get help, but you might also try searching for windows idle bugs, since as I recall there are closed bugs that have some debugging suggestions in them.

----------
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/issue10428>
_______________________________________

From report at bugs.python.org  Mon Nov 15 22:14:28 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 15 Nov 2010 21:14:28 +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: <1289855668.24.0.389070144499.issue3871@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> But different build system make new plaform!
Maybe, but not a new "sys.platform".

VC6 and VS9.0 don't share any project file for the compilation; but they both build a sys.platform=='win32'.
Distutils has to use another way to make the difference and choose the right compiler (in distutils.mscvcompiler.get_build_version())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Mon Nov 15 23:36:18 2010
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Mon, 15 Nov 2010 22:36:18 +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: <1289860578.73.0.0243873714355.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

> I disagree;

 i would say that you're entitled to disagree, but i have to point
 out that unless you've actually been through the process of trying
 to port python to mingw32 you're not really in a position of ...
 how can i put this best... you're entitled to say "i disagree"
 but that doesn't actually carry any weight.

 if you said "i've tried compiling this patch, and i looked at
 it and i disagreed with the decision to create a new platform,
 so i removed that code, here's an updated patch, i found it to
 work absolutely fine" THEN i would say that you are in a position
 of authority to "disagree".

 so - question: have you actually _tried_ compiling python with
 mingw32, with the latest patch?


> programs compiled with mingw32 run on Windows, and use the MSVC 
> runtime.

 they do indeed.  this however has absolutely no relevance.

> It's the same platform as the current win32 build.
> It's even possible to use mingw32 to compile extensions
> for the VS9.0 based python.exe.
 
 it is indeed.  the patch that i did allowed you to specify
 a gcc spec file which did exactly that: i added options to
 compile not only extensions but also the entire python.exe
 to use a different MSVCRT runtime.

 _and_ it did assemblies, too.


> A different compiler does not make a new platform.

 ok.

 unfortunately, as the work that i did was well over a year ago,
 i'm going from memory - but basically, i'm very very sorry to
 have to point out that you don't know what you're talking about,
 here.

 let me try and go through it.

 look at the platform detection code: it parses the gcc version
 string.  it goes "if compiler has string gcc but also has win32
 then it must be cygwin platform".

 otherwise it goes "this must be MSVC win32 platform".

 this _simply_ doesn't work, hence the need to do further
 detection, hence the need to have a separate compiler type.
 ... but it doesn't end there: there are subtle differences
 between MSVC win32 and MINGW32 win32 (differences in the
 build .lib files that specify what functions are available
 in the DLLs. mingw32 is a reverse-engineering project,
 remember?)

 to be honest i can't remember if i actually set sys.platform to
 mingw32 - but the more time i spent getting more and more modules
 to compile, the more blindingly obvious it was that a new platform
 type was needed.

 i encountered dozens of assumptions that "if sys.platform == 'win32'
 then you MUST be building using visual studio: f*** off with your
 attempt to compile this module using gcc".
 
 over the eight to ten week period in which i focussed on this
 non-stop for about 13 hours a day, the list just went on and on
 of discrepancies that had to be solved, and if i _hadn't_ set a
 new platform type, it would have been necessary to add extra
 tests instead:

  "if sys.platform == 'win32' and not {something to detect mingw32}":

 mingw32 _really_ does fall between both worlds: not just the
 compiler type is different, but there are even features and
 functions _missing_ from mingw32 that are present in MSVC.
 i had to work with roumen to get patches to mingw32 upstream
 in some cases!

 so please _do_ stop putting road-blocks in the way.  this is
 a complex enough project, having to fit half way between
 two disparate worlds, without it being stymied by "disagreement"
 when you haven't _actually_ tried compiling this code (if you
 have, i apologise).

 btw if you'd like to try compiling it, but are adamant about
 staying away from proprietary operating systems, i _did_
 manage to get python 2.5 and 2.6 cross-compiled to run under wine.
 ironically there were long-standing bugs in wine that ended up
 getting fixed as a result of running the 25,000 python unit tests,
 but that's another story... :)

 l.

 p.s. msys runs under wine as well, but the configure stage takes
 well over an hour.  the patch i created cut out most of configure
 and replaced it with a pcconfig.h just like win32, which i had
 to create by hand.  this was quicker than waiting for configure
 to run.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Mon Nov 15 23:43:13 2010
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Mon, 15 Nov 2010 22:43:13 +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: <1289860993.83.0.0975682127817.issue3871@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

perhaps, amaury, you might like to, instead of saying "i disagree", you might like instead to say something like this:

"that sounds... interesting, and a little scary - creating an entirely new platform!  are you absolutely sure it's necessary??  could you please perhaps elaborate and give a good justification behind why that decision was taken?"

you see how radically different that is?  on the one hand you're telling three volunteers who have spent considerable time and resources - unpaid - on improving python's reach that they are, to put it bluntly, complete ignorant f*****g morons, and on the other you're engaging with them, encouraging them, and generally trusting them.

i'm really sorry: i really don't like having to be the one to point
these kinds of things out, but... you see what i'm saying?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Mon Nov 15 23:54:15 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 15 Nov 2010 22:54:15 +0000
Subject: [issue3871] cross and native build of python for mingw32 with
	distutils
In-Reply-To: <1289855668.24.0.389070144499.issue3871@psf.upfronthosting.co.za>
Message-ID: <4CE1BA12.1040209@roumenpetrov.info>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

No it is win32 for the resulting binaries.

Idea is following (issue3754) . Travial patch - move method get_platform 
global _get_platform and variable host_platform is initialized to its 
return value. Then replace all calls of sys.platform and get_platform() 
to use host_platform.

In the patch for this issue _get_platform is modiffed to return mingw32 
if ....  so host_platform will be 'minwg32'. Including compiler and etc. 
don't work well in cross-compilation environment as the build script is 
run with python from build system.

Roumen

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Mon Nov 15 23:57:02 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Nov 2010 22:57:02 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1289861822.5.0.265614938739.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Matthias,

you mean $prefix/lib/python3.2 and $prefix/lib/python3.2$abiflags, right?  The latter has just a config directory, and you'd rather see that become $prefix/lib/python3.2/config-$abiflags, right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Tue Nov 16 00:01:59 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Nov 2010 23:01:59 +0000
Subject: [issue9807] deriving configuration information for different builds
	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1289862119.06.0.849812784977.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Matthias,

When you say the python.pc change should change includedir instead of Cflags, that seems weird.  includedir does not currently include the 'pythonX.Y' subdirectory so there's no place to put the abiflags.  Or are you suggesting that we move the pythonX.Y<abiflags> subdir to includedir and remove it from Cflags?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Tue Nov 16 00:02:25 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 15 Nov 2010 23:02:25 +0000
Subject: [issue10262] Add --disable-abi-flags option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1289862145.52.0.309173019259.issue10262@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/issue10262>
_______________________________________

From report at bugs.python.org  Tue Nov 16 00:23:51 2010
From: report at bugs.python.org (G2P)
Date: Mon, 15 Nov 2010 23:23:51 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1289863431.63.0.271177942267.issue9253@psf.upfronthosting.co.za>


G2P <g2p.code+python at gmail.com> added the comment:

Trying to spec this, here is a proposed API:

    parser = argparse.ArgumentParser()
    sub = parser.add_subparsers(default='show')
    sub_show = sub.add_parser('show')
    sub_add = sub.add_parser('add')

If default isn't passed, the subcommand isn't optional.
If default is passed, and no explicit subcommand is given,
the default subcommand is picked.
Arguments are given to the top parser; passing arguments
to the subcommand requires naming it explicitly.

As far as motivation, I'd like to change a program that
uses --choice options (that can have a default) to use
more expressive subcommands. Some programs rely on implicit
subcommands a lot; the ip command on linux is a good
example.

----------
nosy: +G2P

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9253>
_______________________________________

From report at bugs.python.org  Tue Nov 16 00:36:34 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 15 Nov 2010 23:36:34 +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: <1289864194.42.0.305417278767.issue3871@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Luke,
Please please! Don't make me say what I did not say. I just said "I disagree", without any bad word. This may have been a bit terse, but I don't consider the issue tracker as a place to express one's feelings; hey, other core developers could have written "-1" instead.
I'm not trying to block this development, on the contrary, I'm getting interested in it so that we can merge it into CPython development tree. I'm here to help. Really.

I did try to port python to the mingw32 compiler some years ago, and in the proposed patch I retrieve some of the changes I did at the time.  IIRC I gave up because there were issues with the localtime function, and because of differences in the sprintf format. I'm glad that you found how to solve them.
FYI, I'm also the maintainer of pypy on Windows, and we support both MSVC (8, 9, 10) and mingw32.

> i encountered dozens of assumptions that "if sys.platform == 'win32'
> then you MUST be building using visual studio: f*** off with your
> attempt to compile this module using gcc".

There are not so many of them in distutils. Did you see them in third-party packages?
Code like this is wrong and should be changed, just like "#ifdef MS_WINDOWS" (=the platform) is not equivalent to "#ifdef _MSC_VER" (=the compiler)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________

From report at bugs.python.org  Tue Nov 16 00:57:57 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 15 Nov 2010 23:57:57 +0000
Subject: [issue10262] Add --disable-abi-flags option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1289865477.14.0.958851993059.issue10262@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

I think this is not a good idea, because then you have different names for extension modules, which will be recognized by one configuration but not the other.  This configure option should not change the sonames.  If this option is to keep pathes like /usr/local/include/python3.2 (instead of /usr/local/include/python3.2mu) or /usr/local/lib/python3.2/config (instead of /usr/local/lib/python3.2mu/config), then fine with me. Although in this case we should make sure that these pathes are available in the sysconfig module.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Tue Nov 16 00:59:16 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 15 Nov 2010 23:59:16 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1289861822.5.0.265614938739.issue9807@psf.upfronthosting.co.za>
Message-ID: <4CE1C94F.1050708@debian.org>


Matthias Klose <doko at debian.org> added the comment:

On 15.11.2010 23:57, Barry A. Warsaw wrote:
> you mean $prefix/lib/python3.2 and $prefix/lib/python3.2$abiflags, right?  The latter has just a config directory, and you'd rather see that become $prefix/lib/python3.2/config-$abiflags, right?

yes.

----------
title: deriving configuration information for different builds with the same prefix -> deriving configuration information for different builds	with the same prefix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Tue Nov 16 01:03:48 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 16 Nov 2010 00:03:48 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1289862119.06.0.849812784977.issue9807@psf.upfronthosting.co.za>
Message-ID: <4CE1CA60.2060002@debian.org>


Matthias Klose <doko at debian.org> added the comment:

On 16.11.2010 00:01, Barry A. Warsaw wrote:
> When you say the python.pc change should change includedir instead of Cflags, that seems weird.  includedir does not currently include the 'pythonX.Y' subdirectory so there's no place to put the abiflags.  Or are you suggesting that we move the pythonX.Y<abiflags>  subdir to includedir and remove it from Cflags?

sorry, I'm wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Tue Nov 16 01:09:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Nov 2010 00:09:13 +0000
Subject: [issue10429] bug in test_imaplib
In-Reply-To: <1289866153.11.0.678652692288.issue10429@psf.upfronthosting.co.za>
Message-ID: <1289866153.11.0.678652692288.issue10429@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The following warning suggests the test is wrong:

c:\buildslave-py3k\3.x.curtin-win2008-amd64\build\lib\test\test_imaplib.py:231: BytesWarning: Comparison between bytes and string
  self.assertFalse('LOGINDISABLED' in self.server.capabilities)

----------
assignee: pitrou
components: Library (Lib), Tests
messages: 121255
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: bug in test_imaplib
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10429>
_______________________________________

From report at bugs.python.org  Tue Nov 16 01:54:29 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 16 Nov 2010 00:54:29 +0000
Subject: [issue10134] test_email failures on Windows: end of line issue?
In-Reply-To: <1287373744.55.0.18095949035.issue10134@psf.upfronthosting.co.za>
Message-ID: <1289868869.65.0.997207957027.issue10134@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

> Still not sure why they were not showing up on the buildbots.  Victor was working from an svn checkout and I from the binary installer, so it's not just a difference in the svn eol handling.

I too had only been seeing this in my checkout, but now that I setup a build slave I brought the bad luck there. http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x/builds/0 (nothing new, same failures as haypo uploaded).

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10134>
_______________________________________

From report at bugs.python.org  Tue Nov 16 02:17:33 2010
From: report at bugs.python.org (Jessica McKellar)
Date: Tue, 16 Nov 2010 01:17:33 +0000
Subject: [issue2244] urllib and urllib2 decode userinfo multiple times
In-Reply-To: <1204819810.33.0.413464262118.issue2244@psf.upfronthosting.co.za>
Message-ID: <1289870253.69.0.640491734214.issue2244@psf.upfronthosting.co.za>


Jessica McKellar <jesstess at mit.edu> added the comment:

I can confirm that the combination of urllib_issue_updated.diff and urllib_ftptests_doubleencode.patch apply cleanly against py3k, that the added tests exercise the described bug, and that the full test suite passes after applying the patches.

The patches look clean and conforming to PEP 8.

----------
nosy: +jesstess

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2244>
_______________________________________

From report at bugs.python.org  Tue Nov 16 03:23:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 02:23:25 +0000
Subject: [issue716634] "build_ext" "libraries" subcommand not s
Message-ID: <1289874205.85.0.368012224848.issue716634@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: wont fix -> duplicate
superseder:  -> Letting "build_ext --libraries" take more than one lib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue716634>
_______________________________________

From report at bugs.python.org  Tue Nov 16 04:05:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 16 Nov 2010 03:05:07 +0000
Subject: [issue9116] test_capi.test_no_FatalError_infinite_loop crash on
	Windows
In-Reply-To: <1277827107.42.0.0793977492373.issue9116@psf.upfronthosting.co.za>
Message-ID: <1289876707.03.0.182433464537.issue9116@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The patch works for me.
Unfortunately my knowledge on this particular area is very low so I can't really evaluate the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9116>
_______________________________________

From report at bugs.python.org  Tue Nov 16 04:07:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 03:07:16 +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: <1289876836.49.0.0922055529635.issue9312@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can I commit doc patches like this one despite the branch freeze?

----------
assignee: docs at python -> eric.araujo
resolution:  -> accepted
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Tue Nov 16 04:08:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 03:08:32 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <1289876912.75.0.961338114717.issue1326113@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree this is a bug: it?s a broken feature, not a new one, even if it can be argued that fixing a long-standing behavior enables new usages, and is thus comparable to a new feature.

I found no mention of --libraries in the docs, so I looked at the file history, and it?s clear that the intent of the code does not match its behavior.  The fix is simple:

-        if isinstance(self.libraries, str):
-            self.libraries = [self.libraries]
+        self.ensure_string_list('libraries')

I guess Greg forgot to change that line of code when he invented the ensure_* methods.  No test is broken by this change.  Do we need a regression test for this?  It?s not strictly required IMO.

FTR, in distutils2, I want to make the types and formats clear for everything.  For example, build_ext.swig_opts is defined as ?a list? in the current docs, this time with an example that shows it?s space-separated (?--swig-opts="-modern -I../include"?).  The code does not use ensure_string_list, and hence does not support comma-separated.  IMO, any value described as list should accept space-separated and comma-separated.  This is probably out of scope for distutils, but something I definitely want to improve in distutils2.  Supporting multiple options (-lm -lfoo) is IMO feasible too.

----------
assignee: tarek -> eric.araujo
components: +Distutils2
stage:  -> unit test needed
type: feature request -> behavior
versions: +3rd party, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Tue Nov 16 04:18:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 03:18:11 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>
Message-ID: <1289877491.71.0.450835155526.issue10427@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/issue10427>
_______________________________________

From report at bugs.python.org  Tue Nov 16 04:27:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 03:27:34 +0000
Subject: [issue10425] xmlrpclib support for None isn't compliant with XMLRPC
In-Reply-To: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>
Message-ID: <1289878054.43.0.2346942592.issue10425@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report and patch.  You may find the following guidelines useful for your future contributions: http://www.python.org/dev/patches/

I have two questions about the proposed fix.  First, this line caught my eye:

  if tag.split(':')[1] == 'nil':

It seems wrong to handle a nil element from any namespace the same way.  I think namespaces should be supported properly or not at all.

Second point, can you point us to documentation about nil?  The Wikipedia article about XML-RPC and http://ontosys.com/xml-rpc/extensions.php agree that nil should not be a child of value, but say nothing about a namespace.  If it?s a band-aid for one specific server, I don?t think it?s acceptable.

----------
nosy: +eric.araujo, loewis
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10425>
_______________________________________

From report at bugs.python.org  Tue Nov 16 04:40:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 03:40:52 +0000
Subject: [issue1326113] Letting "build_ext --libraries" take more than one lib
Message-ID: <1289878852.7.0.58441172832.issue1326113@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?ve reviewed other modules for the same error and found two candidates: config.libraries, the same thing as build_ext.libraries, and install.extra_path, for which I?m not sure.

(More distutils2 thoughts: A number of options are split on os.pathsep, a new ensure_dirs_list method looks in order.  Regarding the type system, an angry comment in build_py confirmed the need :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1326113>
_______________________________________

From report at bugs.python.org  Tue Nov 16 05:57:47 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Tue, 16 Nov 2010 04:57:47 +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: <1289883467.58.0.897995103194.issue10417@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

I am not having this problem on Ubuntu 10.10 with the most recent Python 2.7:

<terminal interaction>
$ ./python unicodetest.py --verbose
test_unicode_docstring (__main__.UnicodeTest)
t?st - docstring with unicode character ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
$ ./python unicodetest.py
test_unicode_docstring (__main__.UnicodeTest)
t?st - docstring with unicode character ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
</terminal interaction>

----------
nosy: +jfinkels

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Tue Nov 16 05:59:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 04:59:52 +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: <1289883592.42.0.533091326593.issue10417@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great, thank you for the update!  Closing.

----------
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Tue Nov 16 07:36:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 06:36:45 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1289889405.49.0.0936568400944.issue8254@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have turned my branch into a clean patch for default: https://bitbucket.org/Merwok/distutils2/changeset/076b15559290

Notes:

- You can diff configure.py against build.py and install_dist.py from an earlier revision to see what code has been moved where.

- Two tests for install_dist still fail, but this could be only the tip of the iceberg.  We need more tests there.  Installation paths is a tricky business, and we have to make sure configure does not break anything.

- I have changed install to install_dist in the code, tests and docs, but only in the part of the docs I added for configure.  The rest of the file is inaccurate, but that?s outside the scope of this patch.

- Some to-do features: distribute the configure.cache file in the dist-info directory (requires adding a hook system to install_distinfo); add info about the compiler type; probably more.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Tue Nov 16 07:37:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 06:37:13 +0000
Subject: [issue8254] write a configure command
In-Reply-To: <1269787284.51.0.353047597946.issue8254@psf.upfronthosting.co.za>
Message-ID: <1289889433.61.0.746292693681.issue8254@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +needs review, patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8254>
_______________________________________

From report at bugs.python.org  Tue Nov 16 07:55:59 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 16 Nov 2010 06:55:59 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289890559.06.0.44514442899.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

If anything should be done the test that checks the output of id -G should be removed if we want the buildbot to keep running without problems when you change the buildbots account.

After reading the message about the new failures again I don't think this is the OSX issue I mentioned (an which is explain in painfull detail earlier in the message list): it's just that the buildbot account got changed (unintentionally) while buildbot was running.

BTW. I don't understand why adding a new account to an OSX machine adds existing accounts to a new group, I have never seen that behaviour before (on OSX).

I'm -1 on changing anything for now and do not consider this to be a bug in Python or its testset.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Nov 16 08:32:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Nov 2010 07:32:57 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289892777.2.0.276145425631.issue7900@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ronald, on a normal unix system if you add a user to a group, any existing process/terminal session that runs 'id -G' will return the *old* group list.  Only a new process/terminal session will see the new group.

On OSX, 'id -G' returns the new group when run in an existing process/terminal session, according to what you wrote.

You can't just remove the 'id -G' from that test, because the test is using 'id -G' to get an independent verification of the list of group numbers as a check against what getgroups returns.  On a normal unix system, these two would match.  On OSX, they don't.

At the moment I don't see any alternative to skipping the test on OSX with a message that 'id -G' and 'getgroups' do not return the same group list on OSX.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Nov 16 08:36:55 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 16 Nov 2010 07:36:55 +0000
Subject: [issue10430] _sha.sha().digest() method is endian-sensitive. and
	hexdigest()
In-Reply-To: <1289893015.01.0.604303806999.issue10430@psf.upfronthosting.co.za>
Message-ID: <1289893015.01.0.604303806999.issue10430@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

in shamodule.c, the digest() method just creates a simple bytes string of the digest.  The digest is stored as an array of 32 bit integers in the native representation.  Therefore, the digest will be different on big-  and little-endian machines.

The specification (http://en.wikipedia.org/wiki/SHA-1) suggest that the digest should actually be big endian, so the standard implementation on most home machines is actually wrong

Actually, looking at the code, hexdigest() has the same problem!

----------
components: Extension Modules
messages: 121268
nosy: krisvale
priority: normal
severity: normal
status: open
title: _sha.sha().digest() method is endian-sensitive. and hexdigest()
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10430>
_______________________________________

From report at bugs.python.org  Tue Nov 16 08:41:26 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 16 Nov 2010 07:41:26 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289893286.5.0.66394963761.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm still -1 on changing the test.  The test only fails when run from the buildbot and the buildbot account is changed without restarting buildbot. Changing the buildbot account should happen almost never, and IMO you should restart the buildbot daemon when you do so (and that's just good practice)

Disabling the test on OSX means that os.getgroups will not get tested at all on OSX, even when I run the testsuite from the command-line.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Nov 16 08:52:43 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Tue, 16 Nov 2010 07:52:43 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289893963.26.0.408541267624.issue7900@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

The test is clearly verifying a *wrong* assumption: that id -G will match posix.getgroups() which simply does not hold on OSX.

I can reproduce this reliably on a completely clean, brand new installation of 10.5: from there the only things that have been done to the box is updating to 10.5.8, and then downloading the latest XCode tools that run on Leopard.

>From here, launch Terminal: leave the console open. Run id -G; then run python and look at posix.getgroups().

Now, go into System Preferences and add a new user. Don't do anything else. Don't change anything with existing user. 

In the console that was already open, do id -G again. Now run python again, and do posix.getgroups() -- those no longer match.

Clearly IMHO the assumption that the test is declaring to be an expected result simply is not true in a OSX-Unix environment. 

Yes, if I go and *edit the actual slave user* then surely I can expect failures until I restarted the buildslave. But, if by merely adding a user causes a change to the buildslaves user by no action of my own, and that causes this test to be invalid... the test itself seems to be founded on assumptions which simply are not reliably true. 

I understand disabling the test means os.getgroups() will no longer be tested on OSX: and yet, the current situation is a specific behavior of os.getgroups() is tested which is *not* actually the guaranteed behavior of that operation. 

There is at least one very easy to reproduce situation in which id -G and posix.getgroups() do not match: I don't know if there are more. But for the test to assert the truth that its only correct when they match seems to be a mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Nov 16 09:04:39 2010
From: report at bugs.python.org (Steven Bethard)
Date: Tue, 16 Nov 2010 08:04:39 +0000
Subject: [issue9253] argparse: optional subparsers
In-Reply-To: <1279056589.03.0.566167994161.issue9253@psf.upfronthosting.co.za>
Message-ID: <1289894679.89.0.750107342159.issue9253@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I think the proposed API looks fine and should be backwards compatible since add_subparsers will currently throw an exception with a default= argument.

In case someone feels like writing a patch, you'll want to look at _SubParsersAction.__init__, which will need to grow the default= argument, and pass a different nargs= argument on. I think you'll need to define a new nargs type which means you probably also need to look at ArgumentParser._get_nargs_pattern as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9253>
_______________________________________

From report at bugs.python.org  Tue Nov 16 09:29:50 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 16 Nov 2010 08:29:50 +0000
Subject: [issue1028088] Cookies without values are silently ignored (by
	design?)
Message-ID: <1289896190.73.0.788680638423.issue1028088@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Revisiting this issue.

- Cookie: should contain name=value pairs
- Set-Cookie: header can contain a single word like 'secure'

The current design is along the same lines only.
In the original comment, the request had asked to document the behavior of Cookie class ignoring the nameless values. That should be okay.

----------
assignee:  -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028088>
_______________________________________

From report at bugs.python.org  Tue Nov 16 09:47:28 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 16 Nov 2010 08:47:28 +0000
Subject: [issue10394] subprocess Popen deadlock
In-Reply-To: <1289570708.02.0.0744739807294.issue10394@psf.upfronthosting.co.za>
Message-ID: <20101116084709.GA2103@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Did you attach the correct files? You mention about two programs in the
description, but you have attached only one file 'deadlock.py'.
Also, it does not fail on Python 2.7.1.  Please try it on the latest
codeline from release27-maint too.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10394>
_______________________________________

From report at bugs.python.org  Tue Nov 16 09:58:02 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 16 Nov 2010 08:58:02 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1289897882.55.0.651502978983.issue10399@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/issue10399>
_______________________________________

From report at bugs.python.org  Tue Nov 16 10:06:50 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 16 Nov 2010 09:06:50 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1289898410.48.0.148437208222.issue10403@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

It is 'attributes' instead of term 'members'. The term 'method' when it denotes methods can be left as such.

----------
assignee: docs at python -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Tue Nov 16 10:07:45 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 16 Nov 2010 09:07:45 +0000
Subject: [issue10403] Use "member" consistently
In-Reply-To: <1289623042.93.0.830099606418.issue10403@psf.upfronthosting.co.za>
Message-ID: <1289898465.41.0.000917586430722.issue10403@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10403>
_______________________________________

From report at bugs.python.org  Tue Nov 16 10:20:40 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 16 Nov 2010 09:20:40 +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: <1289899240.84.0.998856949456.issue8458@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

With 3.2a4, OS X 10.4 Tiger buildbot failures reported:


======================================================================
ERROR: test_run_code (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 95, in test_run_code
    assert_python_failure('-c')
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py", line 55, in assert_python_failure
    return _assert_python(False, *args, **env_vars)
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py", line 29, in _assert_python
    env=env)
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", line 683, in __init__
    self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor

======================================================================
ERROR: test_run_module (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 72, in test_run_module
    assert_python_failure('-m')
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py", line 55, in assert_python_failure
    return _assert_python(False, *args, **env_vars)
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py", line 29, in _assert_python
    env=env)
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", line 683, in __init__
    self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor

======================================================================
ERROR: test_version (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 48, in test_version
    rc, out, err = assert_python_ok('-V')
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py", line 48, 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 29, in _assert_python
    env=env)
  File "/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py", line 683, in __init__
    self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor

On my 10.4 system, it seems to be a race condition: sometimes I see all three of these failures, sometimes just one, sometimes none.  Again, only on 10.4 (Tiger), not 10.5 or 10.6.  But the 10.4 machine I'm using is by far the slowest of the three so it is possible that could be a factor.  Perhaps there is a race condition with cleaning up the p2c pipe from a previous run?

----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8458>
_______________________________________

From report at bugs.python.org  Tue Nov 16 10:38:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 09:38:00 +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: <1289900280.91.0.0171044012221.issue10417@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have read and closed too fast, Johannes still has the bug on OS X.  Can someone turn his example script into a patch adding a unit test?

----------
resolution: out of date -> 
stage: committed/rejected -> unit test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Tue Nov 16 10:45:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 09:45:19 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1289900719.31.0.940052239207.issue10070@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> That's fair enough.

:) Do you want to close this feature request then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Nov 16 10:48:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 09:48:56 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	relative dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1289900936.4.0.241045371102.issue7325@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Tue Nov 16 11:00:52 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Nov 2010 10:00:52 +0000
Subject: [issue10431] Failed issue tracker submission
In-Reply-To: <20101116095559.EA25110402E@psf.upfronthosting.co.za>
Message-ID: <1289901652.71.0.484944508469.issue10431@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10431>
_______________________________________

From report at bugs.python.org  Tue Nov 16 11:02:24 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Nov 2010 10:02:24 +0000
Subject: [issue10431] Failed issue tracker submission
Message-ID: <1289901744.83.0.152163994398.issue10431@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
Removed message: http://bugs.python.org/msg121278

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10431>
_______________________________________

From report at bugs.python.org  Tue Nov 16 11:02:20 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Tue, 16 Nov 2010 10:02:20 +0000
Subject: [issue10431] Failed issue tracker submission
In-Reply-To: <20101116095559.EA25110402E@psf.upfronthosting.co.za>
Message-ID: <1289901740.02.0.00471084099635.issue10431@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file19614/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10431>
_______________________________________

From report at bugs.python.org  Tue Nov 16 10:56:04 2010
From: report at bugs.python.org (admin)
Date: Tue, 16 Nov 2010 09:56:04 +0000
Subject: [issue10431] Failed issue tracker submission
In-Reply-To: <20101116095559.EA25110402E@psf.upfronthosting.co.za>
Message-ID: <20101116095559.EA25110402E@psf.upfronthosting.co.za>


New submission from admin <roundup-admin at psf.upfronthosting.co.za>:

You are not a registered user.

Unknown address: Order Real Pfizer <report at bugs.python.org>

----------
files: unnamed
messages: 121278
nosy: admin
priority: normal
severity: normal
status: open
title: Failed issue tracker submission
Added file: http://bugs.python.org/file19614/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10431>
_______________________________________
-------------- next part --------------
Return-Path: <report at bugs.python.org>
X-Original-To: report at bugs.python.org
Delivered-To: roundup+tracker at psf.upfronthosting.co.za
Received: from [123.26.137.99] (unknown [123.26.137.99])
	by psf.upfronthosting.co.za (Postfix) with ESMTP id F017410402D
	for <report at bugs.python.org>; Tue, 16 Nov 2010 10:55:58 +0100 (CET)
From: "Order Real Pfizer <report at bugs.python.org>
To: report at bugs.python.org
Reply-To: report at bugs.python.org
Subject: Hi report, Best Deals. one In largest In Forum
Mime-Version: 1.0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Message-Id: <20101116095558.F017410402D at psf.upfronthosting.co.za>
Date: Tue, 16 Nov 2010 10:55:58 +0100 (CET)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Newsletter</title>
</head>
<body>
<table width="650" cellspacing="0" cellpadding="0" bgcolor="#F2F2F2" align="center">
	<tr>
    	<td height="52" style="text-align:center;">
		<span style="color:#464646; font-size:10px; font-family:arial, helvetica, sans-serif;">View <a href="http://xeqiyb.medicsri.ru/?BaBed4D4FF59d198F" style="color:#0093D9;">Mobile</a> | View
		<a href="http://wuren.medicsri.ru/?5262b3319Cb9cc94" style="color:#0093D9;">Webpage</a></span></td>
    </tr>
    <tr>
    	<td>
        	<table width="600" bgcolor="#FFFFFF" cellspacing="0" cellpadding="0" align="center">
            	<tr>
                	<td style="text-align: center">
                    	<a href="http://ke.medicsri.ru/?8bb7A4a93d3eEc">
                    	<img alt="Cheapest Pills. Click here" src="http://b.medicsri.ru/osaa.jpg" style="border-width: 0px"></a></td>
                </tr>
			</table>
            <table width="600" bgcolor="#F2F2F2" cellspacing="0" cellpadding="0" align="center">
                <tr>
                	<td height="27"> </td>
                </tr>
            	<tr>
   	  				<td align="left">
                        <font color="#A2A2A2" face="arial, helvetica, sans-serif" size="1">
                        	PLEASE DO NOT REPLY TO THIS MESSAGE.<br>
                        	This is a system-generated Newsletter email. Replies will not be read or forwarded for handling.<br><br>
                        This message was sent to report at bugs.python.org.<br><br>
                            <a href="http://neaova.medicsri.ru/?B9FC632154FE73F1" style="color:#817979;">Contact Us</a> |
                            <a href="http://upejem.medicsri.ru/?40C41b61a8CB2&remove=report at bugs.python.org" style="color:#817979;">Unsubscribe</a> |
                            <a href="http://ezaha.medicsri.ru/?794148936577" style="color:#817979;">Update Email Address</a> |
                            <a href="http://kyewoc.medicsri.ru/?F1F19646a5441" style="color:#817979;">Privacy Policy</a><br><br>
                            Copyright 2010 The For. All rights reserved.
                        </font>
                    </td>
                </table>
        </td>
    </tr>
</table>
<IMG SRC="http://www.quawysuqoeg.com/07006aefAd4E8DD6f6d6C99806dC48C"></body>
</html>

From report at bugs.python.org  Tue Nov 16 11:49:51 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 16 Nov 2010 10:49:51 +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: <1289904591.72.0.120406555874.issue10417@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The issue is with a non-ascii character in a *Unicode* docstring. Python has to encode the string to write it to the terminal; the encode is implicit and so fails.

The problem doesn't happen with Python 3 unless you run on an ascii terminal.

----------
assignee:  -> michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Tue Nov 16 11:59:36 2010
From: report at bugs.python.org (Scott Dial)
Date: Tue, 16 Nov 2010 10:59:36 +0000
Subject: [issue10432] concurrent.futures.as_completed() spins waiting for
	futures to complete
In-Reply-To: <1289905176.73.0.0627045532304.issue10432@psf.upfronthosting.co.za>
Message-ID: <1289905176.73.0.0627045532304.issue10432@psf.upfronthosting.co.za>


New submission from Scott Dial <scott at scottdial.com>:

The code in as_completed() waits on a FIRST_COMPLETED event, which means that after the first future completes, it will no longer wait at all. The proposed patch adds a _AsCompletedWaiter and uses a lock to swap out the finished list and reset the event.

This is a difficult problem to create a test case for without adding intrusive code to as_completed() to count how many times it loops or create a mock Event object that counts it, so I have not proposed a test.

----------
components: Library (Lib)
files: futures-r86476.patch
keywords: patch
messages: 121280
nosy: scott.dial
priority: normal
severity: normal
status: open
title: concurrent.futures.as_completed() spins waiting for futures to complete
type: behavior
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19615/futures-r86476.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10432>
_______________________________________

From report at bugs.python.org  Tue Nov 16 12:32:03 2010
From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=)
Date: Tue, 16 Nov 2010 11:32:03 +0000
Subject: [issue10425] xmlrpclib support for None isn't compliant with XMLRPC
In-Reply-To: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>
Message-ID: <1289907123.5.0.805971314279.issue10425@psf.upfronthosting.co.za>


Adam Biela?ski <abgans at gmail.com> added the comment:

Ok, I apologize for being to hasty. Below you can find my answers:

1. SlowParser used in xmlrpclib doesn't deal with namespaces in any reasonable way. If there's a namespace prefix for tag, it's not separated from tag name, but passed as part of tag name. But I agree - this should be done better.

2. Well, I suppose that content of http://ws.apache.org/xmlrpc/extensions.html will only convince you that this patch is just for Java library and you reject it. I didn't find support for <nil/> in Perl nor Ruby. One of PHP libraries also support <nil/> (and <ex:nil/>) - http://phpxmlrpc.sourceforge.net/, but AFAIK it doesn't require/provide any namespace at all. It just treats ex:nil as a synonym for nil, probably to be compatible with Apache library.

All in all - I think that my patch should be rejected. I can send simpler patch that would work like phpxmlrpc does - just accept ex:nil as well as nil and not try to analyze namespaces at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10425>
_______________________________________

From report at bugs.python.org  Tue Nov 16 12:38:07 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 16 Nov 2010 11:38:07 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1289907487.31.0.369365670625.issue1553375@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note that my suggestion was to move the if statement out of the loop as-is: you would still be pulling the traceback to display from the caught exception rather than displaying the stack from the current point of execution. If you want the bottom most point to display where the actual exception occurred rather than the last line executed in the frame that caught it you need to be even smarter than that, though.

The information to construct the full stack trace properly is actually available, but it is necessary to be very careful as to how it is stitched together at the point where the traceback and the stack trace meet up.

For a full stack trace, this stitching actually needs to occur every time there is a jump from one exception to another. For finally clauses and reraised exceptions, the interpreter handles this internally so the traceback reflects the appropriate lines, but recreating a complete stack trace for the original exception in the face of PEP 3134 is going to require a bit of work in the traceback module.

Alternatively, you could just provide the full stack trace for the very last exception caught, leaving it to the reader to follow the traceback chain back down to the original exception.

Here's some useful code to explore this (I just spent some time playing with it to make sure I was giving the right answer here):

import sys
from traceback import print_exc, print_stack, print_tb
def f(n):
  this = "F%d" % n
  if n:
    try:
      f(n-1)
    except:
      print("*** Traceback in", this)
      print_exc(chain=False)
      print("*** Call stack in", this)
      print_stack()
      print("*** Replacing exception in", this)
      raise RuntimeError(this)
  print("*** Call stack in", this)
  print_stack()
  raise RuntimeError(this)

try:
  f(2)
except:
  etype, ex, tb = sys.exc_info()

"raise ex" will then show you the native display of that exception.

You can then use the context attributes to see what state is available to you:
>>> ex
RuntimeError('F2',)
>>> ex.__context__
RuntimeError('F1',)
>>> ex.__context__.__context__
RuntimeError('F0',)

In particular, we can see that the two inner exceptions are attached to frame objects which were used to run the nested function calls and hence have a frame that called them:
>>> ex.__traceback__.tb_frame.f_back
>>> ex.__context__.__traceback__.tb_frame.f_back
<frame object at 0x2118ff0>
>>> ex.__context__.__context__.__traceback__.tb_frame.f_back
<frame object at 0x2115b80>

The issue we have is that landing in the exception handlers means the state of those frames has been altered by the stack unwinding process. Let's compare the traceback for each exception with the current state of the corresponding frame (we skip the first traceback entry for our outermost function - it is there courtesy of the interactive loop and irrelevant to the current exploration):

>>> ex.__traceback__.tb_next.tb_lineno # Top level exception line
2
>>> ex.__traceback__.tb_next.tb_frame.f_lineno # Last executed line
4
>>> ex.__context__.__traceback__.tb_lineno # f(2) exception line
5
>>> ex.__context__.__traceback__.tb_frame.f_lineno # Last executed line
12
>>> ex.__context__.__context__.__traceback__.tb_lineno # f(1) exception line
5
>>> ex.__context__.__context__.__traceback__.tb_frame.f_lineno # Last executed line
12

f(0) avoids triggering the exception handler and we can see that the traceback line and the last executed line match in that case:

>>> ex.__context__.__context__.__traceback__.tb_next.tb_lineno
15
>>> ex.__context__.__context__.__traceback__.tb_next.tb_frame.f_lineno
15

So yes, the idea proposed is possible, but no, a simple call to print_stack isn't going to do the right thing.

----------
keywords:  -needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Tue Nov 16 12:48:51 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 16 Nov 2010 11:48:51 +0000
Subject: [issue10425] xmlrpclib support for None isn't compliant with XMLRPC
In-Reply-To: <1289907123.5.0.805971314279.issue10425@psf.upfronthosting.co.za>
Message-ID: <20101116114713.GC2103@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Tue, Nov 16, 2010 at 11:32:03AM +0000, Adam Biela?ski wrote:
>  just accept ex:nil as well as nil and not try to analyze namespaces at all.

But even that seems specific to Java/ Apache Extension.
If it is, then it might go in as part of issue8792.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10425>
_______________________________________

From report at bugs.python.org  Tue Nov 16 12:52:44 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 16 Nov 2010 11:52:44 +0000
Subject: [issue10432] concurrent.futures.as_completed() spins waiting for
	futures to complete
In-Reply-To: <1289905176.73.0.0627045532304.issue10432@psf.upfronthosting.co.za>
Message-ID: <1289908364.18.0.925585913811.issue10432@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> bquinlan
nosy: +bquinlan
stage:  -> patch review
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10432>
_______________________________________

From report at bugs.python.org  Tue Nov 16 13:08:13 2010
From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=)
Date: Tue, 16 Nov 2010 12:08:13 +0000
Subject: [issue10425] xmlrpclib support for None isn't compliant with XMLRPC
In-Reply-To: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>
Message-ID: <1289909293.47.0.394438235911.issue10425@psf.upfronthosting.co.za>


Adam Biela?ski <abgans at gmail.com> added the comment:

It is. It might go. Didn't notice issue8792 before, thanks for pointing it out.

Whole ex:nil issue is discussed there, so this issue might be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10425>
_______________________________________

From report at bugs.python.org  Tue Nov 16 13:10:51 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 16 Nov 2010 12:10:51 +0000
Subject: [issue10425] xmlrpclib support for None isn't compliant with XMLRPC
In-Reply-To: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>
Message-ID: <1289909451.93.0.763647772112.issue10425@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10425>
_______________________________________

From report at bugs.python.org  Tue Nov 16 13:33:48 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Tue, 16 Nov 2010 12:33:48 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1289910828.02.0.304366806556.issue6083@psf.upfronthosting.co.za>


Eugene Kapun <abacabadabacaba at gmail.com> added the comment:

Actually, this can't be fixed without modifying C API methods PyArg_ParseTuple and PyArg_ParseTupleAndKeywords, because it's possible to make an object deallocated before PyArg_ParseTuple returns, so Py_INCREF immediately after parsing would be already too late.

Here are my test cases:
test-resource.py - in Modules/resource.c, and python-bug-01.patch won't work against it.
test-ctypes.py - in Modules/_ctypes/_ctypes.c.
test-functools.py - in Modules/_functoolsmodule.c (py3k only).

----------
components: +Interpreter Core -Extension Modules
nosy: +abacabadabacaba
title: Reference counting bug in setrlimit -> Reference counting bug in PyArg_ParseTuple and PyArg_ParseTupleAndKeywords
Added file: http://bugs.python.org/file19616/test-resource.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Tue Nov 16 13:34:29 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Tue, 16 Nov 2010 12:34:29 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1289910869.46.0.936929195494.issue6083@psf.upfronthosting.co.za>


Changes by Eugene Kapun <abacabadabacaba at gmail.com>:


Added file: http://bugs.python.org/file19617/test-ctypes.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Tue Nov 16 13:35:15 2010
From: report at bugs.python.org (Eugene Kapun)
Date: Tue, 16 Nov 2010 12:35:15 +0000
Subject: [issue6083] Reference counting bug in PyArg_ParseTuple and
	PyArg_ParseTupleAndKeywords
In-Reply-To: <1242980336.93.0.332167282409.issue6083@psf.upfronthosting.co.za>
Message-ID: <1289910915.92.0.817366617166.issue6083@psf.upfronthosting.co.za>


Changes by Eugene Kapun <abacabadabacaba at gmail.com>:


Added file: http://bugs.python.org/file19618/test-functools.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6083>
_______________________________________

From report at bugs.python.org  Tue Nov 16 13:48:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Nov 2010 12:48:55 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1289911735.42.0.129217904453.issue10070@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/issue10070>
_______________________________________

From report at bugs.python.org  Tue Nov 16 14:05:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Nov 2010 13:05:08 +0000
Subject: [issue10134] test_email failures on Windows: end of line issue?
In-Reply-To: <1287373744.55.0.18095949035.issue10134@psf.upfronthosting.co.za>
Message-ID: <1289912708.24.0.0754432923259.issue10134@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/issue10134>
_______________________________________

From report at bugs.python.org  Tue Nov 16 14:13:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 13:13:25 +0000
Subject: [issue10425] xmlrpclib support for None isn't compliant with XMLRPC
In-Reply-To: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>
Message-ID: <1289913205.21.0.682104981968.issue10425@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
superseder:  -> Support Apache extensions to XML-RPC in xmlrpclib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10425>
_______________________________________

From report at bugs.python.org  Tue Nov 16 14:14:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 13:14:35 +0000
Subject: [issue10425] xmlrpclib support for None isn't compliant with XMLRPC
In-Reply-To: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>
Message-ID: <1289913275.44.0.882468079436.issue10425@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There's no need to apologize, we welcome contributions like your report and are open to discuss patches :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10425>
_______________________________________

From report at bugs.python.org  Tue Nov 16 14:17:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 13:17:41 +0000
Subject: [issue8792] Support Apache extensions to XML-RPC in xmlrpclib
In-Reply-To: <1274558114.05.0.260300491762.issue8792@psf.upfronthosting.co.za>
Message-ID: <1289913461.23.0.124948142632.issue8792@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

An addition: It was reported in #10425 that None values are incorrectly serialized as <value><nil/></value>, instead of just <nil/>, or maybe <{namespace prefix for extensions defined by Apache}:nil/>.

----------
nosy: +Adam.Biela?ski, eric.araujo, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8792>
_______________________________________

From report at bugs.python.org  Tue Nov 16 14:19:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 16 Nov 2010 13:19:59 +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: <1289913599.78.0.837913067674.issue10417@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Johannes, can you paste the output of the locale command?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Tue Nov 16 14:25:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Nov 2010 13:25:15 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289913915.5.0.824888998033.issue7900@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree with Stephen.  The test in question is *not a valid test* on OSX.  Therefore on OSX it should be skipped.

If you can think of a way to test the actual behavior of getgroups on OSX, that's even better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Nov 16 14:26:43 2010
From: report at bugs.python.org (Michael Foord)
Date: Tue, 16 Nov 2010 13:26:43 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289914003.59.0.218714145271.issue7900@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/issue7900>
_______________________________________

From report at bugs.python.org  Tue Nov 16 14:44:19 2010
From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=)
Date: Tue, 16 Nov 2010 13:44:19 +0000
Subject: [issue8792] Support Apache extensions to XML-RPC in xmlrpclib
In-Reply-To: <1274558114.05.0.260300491762.issue8792@psf.upfronthosting.co.za>
Message-ID: <1289915059.36.0.619380641228.issue8792@psf.upfronthosting.co.za>


Adam Biela?ski <abgans at gmail.com> added the comment:

To make example provided by Amaury complete I'll add that in order to support both ways you also need to replace xmlrpclib.dumps() with code from attached file.

Changes to original xmlrpclib.dumps() function are outlined with comments. In short - it adds namespace declarations to methodCall and methodResponse elements and also makes Marshaller produce <ex:nil/> instead of <nil/>

----------
Added file: http://bugs.python.org/file19619/dumps_with_namespace.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8792>
_______________________________________

From report at bugs.python.org  Tue Nov 16 14:44:42 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 16 Nov 2010 13:44:42 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289915082.87.0.793994847322.issue7900@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Please explain how the failure can be reproduced.


I've done some testing on my machine using Apple's copy of python 2.6.1 (on OSX 10.6), which has the same getgroups implementation as the current heads of the active branches.


>>> os.getgroups()
[20, 402, 204, 61, 12, 401]
>>> os.system("id -G")
20 402 204 61 12 401
0

(Now open the Accounts preference pane and add a new user)


>>> os.getgroups()
[20, 403, 402, 204, 61, 12, 401]
>>> os.system("id -G")
20 403 402 204 61 12 401
0

Note how the result of both os.getgroups and id -G changes, which should mean that tests shouldn't fail unless you happened to add a new account in the split-second between the "calls" to os.getgroups and "id -G" in a testrun.

Was the buildbot started using launchd (the recipe at <http://buildbot.net/trac/wiki/UsingLaunchd> seems correct)? If not, how is it started?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Nov 16 15:03:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Nov 2010 14:03:32 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289916212.1.0.597841796459.issue7900@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Having just reread this issue more carefully, my understanding is that Ronald had elected to make the results returned from os.getgroups match that returned by "system tools" (by which I understood him to mean the 'id' command).  Since Ronald reports he sees the intended behavior, Stephen's results seem to show that there is a problem with the fix in some circumstances which need to be understood.

Alexander noted that this should all be documented, and I agree, so I'm opening a new issue for the doc update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Nov 16 15:06:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Nov 2010 14:06:07 +0000
Subject: [issue10433] Document unique behavior of 'getgroups' on OSX
In-Reply-To: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za>
Message-ID: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Per issue 7900, os.getgroups on OSX does not behave the same way as on any other unix platform.  This seems worthy of a documentation note, since anyone trying to write portable code could get bit by this.

I don't really understand the relationship on OSX between what the current os.getgroups returns, what the normal unix os.getgroups returns, and what things a process can actually *do*, so I can't write that documentation.  Hopefully someone else can.

A doc note is probably also needed about the relationship between os.setgroups and os.getgroups on OSX, which again I do not understand and so cannot write.

----------
messages: 121293
nosy: r.david.murray
priority: normal
severity: normal
stage: needs patch
status: open
title: Document unique behavior of 'getgroups' on OSX
type: behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10433>
_______________________________________

From report at bugs.python.org  Tue Nov 16 15:10:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 16 Nov 2010 14:10:07 +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: <1289916607.64.0.409673641159.issue10417@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

In Python 3, sys.stderr uses the 'backslashreplace' error handler. With C locale, sys.stderr uses the ASCII encoding and so the ? unicode character is printed as \xe9.

In Python 2, sys.stderr.errors is strict by default.

It works if you specify the error handler:

$ ./python -c "import sys; sys.stderr.write(u'\xe9\n')"
?
$ PYTHONIOENCODING=ascii:backslashreplace ./python -c "import sys; sys.stderr.write(u'\xe9\n')"
\xe9

But with ASCII encoding, and the default error handler (strict), it fails:

$ PYTHONIOENCODING=ascii ./python -c "import sys; sys.stderr.write(u'\xe9\n')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 0: ordinal not in range(128)
$ LANG= ./python -c "import sys; sys.stderr.write(u'\xe9\n')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 0: ordinal not in range(128)

Change the default error handler in a minor release is not a good idea. But we can emulate the backslashreplace error handler. distutils.log does that in Python3:

class Log:

    def __init__(self, threshold=WARN):
        self.threshold = threshold

    def _log(self, level, msg, args):
        if level not in (DEBUG, INFO, WARN, ERROR, FATAL):
            raise ValueError('%s wrong log level' % str(level))

        if level >= self.threshold:
            if args:
                msg = msg % args
            if level in (WARN, ERROR, FATAL):
                stream = sys.stderr
            else:
                stream = sys.stdout
            if stream.errors == 'strict':
                # emulate backslashreplace error handler
                encoding = stream.encoding
                msg = msg.encode(encoding, "backslashreplace").decode(encoding)
            stream.write('%s\n' % msg)
            stream.flush()
    (...)

_WritelnDecorator() of unittest.runner should maybe use the same code.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10417>
_______________________________________

From report at bugs.python.org  Tue Nov 16 15:24:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Nov 2010 14:24:37 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289917477.72.0.3994530215.issue7900@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

And it's entirely possible (even likely) that what Stephen is seeing here is a platform bug in OSX's quirky implementation of group management.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Nov 16 15:34:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 14:34:42 +0000
Subject: [issue10413] Comments in unicode.h are out of date
In-Reply-To: <1289694856.74.0.857329002017.issue10413@psf.upfronthosting.co.za>
Message-ID: <1289918082.05.0.387480525022.issue10413@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 86478.  Should this go in 3.1?  This is a comments-only change, so it is fairly safe and merging may help future maintenance.  On the other hand, it is very unlikely that the header file will need to be changed in maintenance releases.  I'll close this in a few days if no one speaks up.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10413>
_______________________________________

From report at bugs.python.org  Tue Nov 16 15:55:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 14:55:38 +0000
Subject: [issue10434] Document the rules for "public names"
In-Reply-To: <1289919338.9.0.394057770971.issue10434@psf.upfronthosting.co.za>
Message-ID: <1289919338.9.0.394057770971.issue10434@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

As discussed in "Breaking undocumented API" thread [1] on python-dev,  a definition of "public names" is buried deep in the language reference manual:

"""
The public names defined by a module are determined by checking the
module?s namespace for a variable named __all__; if defined, it must
be a sequence of strings which are names defined or imported by that
module. The names given in __all__ are all considered public and are
required to exist. If __all__ is not defined, the set of public names
includes all names found in the module?s namespace which do not begin
with an underscore character ('_'). __all__ should contain the entire
public API. It is intended to avoid accidentally exporting items that
are not part of the API (such as library modules which were imported
and used within the module).
"""  [2]

It has been argued that this is not the authoritative definition and alternatives have been suggested such as "any name that does not begin with an underscore except imported modules."
mportant for the users and developers of cpython and other python implementations to know what names they can rely upon to stay defined between releases, the rules for "public names" should be documented.

I agree that the library manual is a more appropriate place for such documentation.  The definition should include the naming conventions and the set of promises that Python makes about public name availability in the future releases.


[1] http://mail.python.org/pipermail/python-dev/2010-November/105490.html
[2] http://docs.python.org/reference/simple_stmts.html

----------
assignee: docs at python
components: Documentation
messages: 121297
nosy: belopolsky, docs at python
priority: normal
severity: normal
stage: needs patch
status: open
title: Document the rules for "public names"
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10434>
_______________________________________

From report at bugs.python.org  Tue Nov 16 16:18:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 15:18:17 +0000
Subject: [issue10433] Document unique behavior of 'getgroups' on OSX
In-Reply-To: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za>
Message-ID: <1289920697.09.0.709124894788.issue10433@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/issue10433>
_______________________________________

From report at bugs.python.org  Tue Nov 16 16:19:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 15:19:11 +0000
Subject: [issue10433] Document unique behavior of 'getgroups' on OSX
In-Reply-To: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za>
Message-ID: <1289920751.49.0.89205316805.issue10433@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> docs at python
components: +Documentation, Macintosh
nosy: +docs at python
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10433>
_______________________________________

From report at bugs.python.org  Tue Nov 16 16:39:22 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Nov 2010 15:39:22 +0000
Subject: [issue10413] Comments in unicode.h are out of date
In-Reply-To: <1289918082.05.0.387480525022.issue10413@psf.upfronthosting.co.za>
Message-ID: <4CE2A5A6.1000106@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:
> 
> Committed in revision 86478.  Should this go in 3.1?  This is a comments-only change, so it is fairly safe and merging may help future maintenance.  On the other hand, it is very unlikely that the header file will need to be changed in maintenance releases.  I'll close this in a few days if no one speaks up.

It's essentially a documentation bug that you fixed. So yes, it should
go in 3.1 as well.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10413>
_______________________________________

From report at bugs.python.org  Tue Nov 16 16:40:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Nov 2010 15:40:47 +0000
Subject: [issue10413] Comments in unicode.h are out of date
In-Reply-To: <1289694856.74.0.857329002017.issue10413@psf.upfronthosting.co.za>
Message-ID: <1289922047.83.0.0412968750371.issue10413@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10413>
_______________________________________

From report at bugs.python.org  Tue Nov 16 16:48:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 15:48:42 +0000
Subject: [issue10434] Document the rules for "public names"
In-Reply-To: <1289919338.9.0.394057770971.issue10434@psf.upfronthosting.co.za>
Message-ID: <1289922522.48.0.834984663548.issue10434@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Michael Foord suggested adding the following to developer documentation such as PEP 8. [1] I am not sure PEP 8 is the right place for it.  In my opinion, PEP 8 is mostly about stylistic choices that don't have a major impact on the users.  In other words, unless you are developing python itself, you are unlikely to consult PEP 8.  The API stability rules, however affect every user who programmed in python long enough to see a major release.  I don't have objections to Michael's definitions below, but if included in the library manual, they should be reworded to address the user rather than the developer of the API.

"""
How about making this explicit (either pep 8 or our developer docs):

If a module or package defines __all__ that authoritatively defines the 
public interface. Modules with __all__ SHOULD still respect the naming 
conventions (leading underscore for private members) to avoid confusing 
users. Modules SHOULD NOT export private members in __all__.

Names imported into a module a never considered part of its public API 
unless documented to be so or included in __all__.

Methods / functions / classes and module attributes whose names begin 
with a leading underscore are private.

If a class name begins with a leading underscore none of its members are 
public, whether or not they begin with a leading underscore.

If a module name in a package begins with a leading underscore none of 
its members are public, whether or not they begin with a leading underscore.

If a module or package doesn't define __all__ then all names that don't 
start with a leading underscore are public.

All public members MUST be documented. Public functions, methods and 
classes SHOULD have docstrings. Private members may have docstrings.
""" [1]

[1] http://mail.python.org/pipermail/python-dev/2010-November/105476.html

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10434>
_______________________________________

From report at bugs.python.org  Tue Nov 16 17:11:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 16:11:47 +0000
Subject: [issue10413] Comments in unicode.h are out of date
In-Reply-To: <1289694856.74.0.857329002017.issue10413@psf.upfronthosting.co.za>
Message-ID: <1289923907.8.0.804354879942.issue10413@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed to 3.1 branch in revision 86481.

----------
status: pending -> closed
type:  -> behavior
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10413>
_______________________________________

From report at bugs.python.org  Tue Nov 16 17:12:20 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Nov 2010 16:12:20 +0000
Subject: [issue10413] Comments in unicode.h are out of date
In-Reply-To: <1289923907.8.0.804354879942.issue10413@psf.upfronthosting.co.za>
Message-ID: <4CE2AD61.3060700@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:
> 
> Committed to 3.1 branch in revision 86481.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10413>
_______________________________________

From report at bugs.python.org  Tue Nov 16 17:16:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 16:16:46 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The following C-APIs are only documented in comments inside unicode.h:

PyUnicode_GetMax
PyUnicode_Resize
PyUnicode_InternImmortal
PyUnicode_FromOrdinal
PyUnicode_GetDefaultEncoding
PyUnicode_AsDecodedObject
PyUnicode_AsDecodedUnicode
PyUnicode_AsEncodedObject
PyUnicode_AsEncodedUnicode
PyUnicode_BuildEncodingMap
PyUnicode_EncodeDecimal
PyUnicode_Append
PyUnicode_AppendAndDel
PyUnicode_Partition
PyUnicode_RPartition
PyUnicode_RSplit
PyUnicode_IsIdentifier
Py_UNICODE_strlen
Py_UNICODE_strcpy
Py_UNICODE_strcat
Py_UNICODE_strncpy
Py_UNICODE_strcmp
Py_UNICODE_strncmp
Py_UNICODE_strchr
Py_UNICODE_strrchr

----------
assignee: belopolsky
components: Documentation
messages: 121302
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Document unicode C-API in reST
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Tue Nov 16 17:18:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Nov 2010 16:18:41 +0000
Subject: [issue10433] Document unique behavior of 'getgroups' on OSX
In-Reply-To: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za>
Message-ID: <1289924321.75.0.980620976353.issue10433@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +ned.deily, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10433>
_______________________________________

From report at bugs.python.org  Tue Nov 16 17:23:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 16:23:21 +0000
Subject: [issue8649] Py_UNICODE_* functions are undocumented
In-Reply-To: <1273250921.26.0.330435554177.issue8649@psf.upfronthosting.co.za>
Message-ID: <1289924601.7.0.763490990035.issue8649@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

There are more undocumented functions in unicode.h.  It makes sense to fix all of them in one patch.  Closing this as superseded by #10435.

----------
nosy: +belopolsky
resolution:  -> duplicate
status: open -> closed
superseder:  -> Document unicode C-API in reST

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8649>
_______________________________________

From report at bugs.python.org  Tue Nov 16 17:29:44 2010
From: report at bugs.python.org (Ron Adam)
Date: Tue, 16 Nov 2010 16:29:44 +0000
Subject: [issue10434] Document the rules for "public names"
In-Reply-To: <1289919338.9.0.394057770971.issue10434@psf.upfronthosting.co.za>
Message-ID: <1289924984.42.0.499259802885.issue10434@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

You may also want to update help topics.

help("PRIVATENAMES").

Identifiers (Names)
*******************

An identifier occurring as an atom is a name.  See section
*Identifiers and keywords* for lexical definition and section *Naming
and binding* for documentation of naming and binding.

When the name is bound to an object, evaluation of the atom yields
that object. When a name is not bound, an attempt to evaluate it
raises a ``NameError`` exception.

**Private name mangling:** When an identifier that textually occurs in
a class definition begins with two or more underscore characters and
does not end in two or more underscores, it is considered a *private
name* of that class. Private names are transformed to a longer form
before code is generated for them.  The transformation inserts the
class name in front of the name, with leading underscores removed, and
a single underscore inserted in front of the class name.  For example,
the identifier ``__spam`` occurring in a class named ``Ham`` will be
transformed to ``_Ham__spam``.  This transformation is independent of
the syntactical context in which the identifier is used.  If the
transformed name is extremely long (longer than 255 characters),
implementation defined truncation may happen.  If the class name
consists only of underscores, no transformation is done.


Other topics that may be of interest.

IDENTIFIERS
NAMESPACES
PACKAGES
PRIVATENAMES
SPECIALATTRIBUTES
SPECIALIDENTIFIERS
SPECIALMETHODS

----------
nosy: +ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10434>
_______________________________________

From report at bugs.python.org  Tue Nov 16 17:31:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 16 Nov 2010 16:31:43 +0000
Subject: [issue9076] Add C-API documentation for
	PyUnicode_AsDecodedObject/Unicode and
	PyUnicode_AsEncodedObject/Unicode
In-Reply-To: <1277422131.02.0.354002642954.issue9076@psf.upfronthosting.co.za>
Message-ID: <1289925103.58.0.349233842849.issue9076@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Documenting Unicode C APIs is now tracked in #10435.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed
superseder:  -> Document unicode C-API in reST

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9076>
_______________________________________

From report at bugs.python.org  Tue Nov 16 17:45:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 16:45:18 +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: <1289925918.77.0.940151779105.issue2799@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: +Interpreter Core
stage:  -> needs patch
versions: +Python 3.3 -Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2799>
_______________________________________

From report at bugs.python.org  Tue Nov 16 18:32:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Nov 2010 17:32:47 +0000
Subject: [issue10433] Document unique behavior of 'getgroups' on OSX
In-Reply-To: <1289916367.38.0.763799196023.issue10433@psf.upfronthosting.co.za>
Message-ID: <1289928767.33.0.810111268188.issue10433@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/issue10433>
_______________________________________

From report at bugs.python.org  Tue Nov 16 18:49:36 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 16 Nov 2010 17:49:36 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1289929776.13.0.214235819065.issue10318@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Tue Nov 16 18:55:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Nov 2010 17:55:54 +0000
Subject: [issue10429] bug in test_imaplib
In-Reply-To: <1289866153.11.0.678652692288.issue10429@psf.upfronthosting.co.za>
Message-ID: <1289930154.81.0.743771499457.issue10429@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This was a real bug in IMAP.starttls() actually. Fixed in r86485.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10429>
_______________________________________

From report at bugs.python.org  Tue Nov 16 18:59:01 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 16 Nov 2010 17:59:01 +0000
Subject: [issue2901] "error: can't allocate region" from mmap() when receiving
	big chunk of data
In-Reply-To: <1211069816.05.0.311102248623.issue2901@psf.upfronthosting.co.za>
Message-ID: <1289930341.09.0.605298022999.issue2901@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I'm not sure whether it's related but on psutil we have a similar error message by using Python 2.6.1 64-bit:
http://code.google.com/p/psutil/issues/detail?id=135

----------
nosy: +giampaolo.rodola
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2901>
_______________________________________

From report at bugs.python.org  Tue Nov 16 18:59:32 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 16 Nov 2010 17:59:32 +0000
Subject: [issue2901] "error: can't allocate region" from mmap() when receiving
	big chunk of data
In-Reply-To: <1211069816.05.0.311102248623.issue2901@psf.upfronthosting.co.za>
Message-ID: <1289930372.17.0.900232115643.issue2901@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <g.rodola at gmail.com>:


----------
nosy: +ixokai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2901>
_______________________________________

From report at bugs.python.org  Tue Nov 16 19:17:44 2010
From: report at bugs.python.org (David Nesting)
Date: Tue, 16 Nov 2010 18:17:44 +0000
Subject: [issue10436] tarfile.extractfile in "r|" stream mode fails with
	filenames or members from getmembers()
In-Reply-To: <1289931464.79.0.618120236196.issue10436@psf.upfronthosting.co.za>
Message-ID: <1289931464.79.0.618120236196.issue10436@psf.upfronthosting.co.za>


New submission from David Nesting <david at fastolfe.net>:

When opening a tarfile with mode "r|" (streaming mode), extractfile("filename") and extractfile(mytarfile.getmembers()[0]) raise "tarfile.StreamError: seeking backwards is not allowed".  extractfile(mytarfile.next()) succeeds.  A more complete test case:

"""
import tarfile
import StringIO

# Create a simple tar file in memory.  This could easily be a real tar file
# though.
data = StringIO.StringIO()
tf = tarfile.open(fileobj=data, mode="w")
tarinfo = tarfile.TarInfo(name="testfile")
filedata = StringIO.StringIO("test data")
tarinfo.size = len(filedata.getvalue())
tf.addfile(tarinfo, fileobj=filedata)
tf.close()
data.seek(0)

# Open as an uncompressed stream
tf = tarfile.open(fileobj=data, mode="r|")

#f = tf.extractfile("testfile")
#print "%s: %s" % (f.name, f.read())
#
#Traceback (most recent call last):
#  File "./bug.py", line 19, in <module>
#    print "%s: %s" % (f.name, f.read())
#  File "/usr/lib/python2.7/tarfile.py", line 815, in read
#    buf += self.fileobj.read()
#  File "/usr/lib/python2.7/tarfile.py", line 735, in read
#    return self.readnormal(size)
#  File "/usr/lib/python2.7/tarfile.py", line 742, in readnormal
#    self.fileobj.seek(self.offset + self.position)
#  File "/usr/lib/python2.7/tarfile.py", line 554, in seek
#    raise StreamError("seeking backwards is not allowed")
#tarfile.StreamError: seeking backwards is not allowed

#for member in tf.getmembers():
#  f = tf.extractfile(member)
#  print "%s: %s" % (f.name, f.read())
#
# Same traceback

while True:
  member = tf.next()
  if member is None:
    break
  f = tf.extractfile(member)
  print "%s: %s" % (f.name, f.read())

# This works.
"""

It appears that extractfile("filename") invokes getmember("filename"), which invokes getmembers().  getmembers() scans the entire file before returning results, and by doing so, it's read past and discarded the actual file data, which makes it impossible for us to actually extract it.

If this is accurate, this seems tricky to completely fix.  You could make getmembers() a generator that doesn't read too far ahead so that the file's contents are still available if someone wants to retrieve them for each file yielded.  getmember("filename") could just scan forward through the file until it hits a match, but you'd still lose the ability to do a getmember("filename") on a file that we skipped over.

If nothing else, document that extractfile("filename"), getmember() and getmembers() won't work reliably in streaming mode, and possibly raise an exception whenever someone tries just to make behavior consistent.

----------
components: Library (Lib)
messages: 121308
nosy: David.Nesting
priority: normal
severity: normal
status: open
title: tarfile.extractfile in "r|" stream mode fails with filenames or members from getmembers()
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10436>
_______________________________________

From report at bugs.python.org  Tue Nov 16 19:45:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 16 Nov 2010 18:45:25 +0000
Subject: [issue2901] "error: can't allocate region" from mmap() when receiving
	big chunk of data
In-Reply-To: <1211069816.05.0.311102248623.issue2901@psf.upfronthosting.co.za>
Message-ID: <1289933125.0.0.653567800217.issue2901@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This still needs to be verified that there is a problem with a *current* release. That means 2.7.1 (rc just out) or 3.2 (a4 just out).

If this would be considered a security issue (I do not know) then 'current' includes 2.5.5, 2.6.6, and 3.1.3 (rc or final).

Without such verification, this should be closed until the problem appears again.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2901>
_______________________________________

From report at bugs.python.org  Tue Nov 16 20:27:24 2010
From: report at bugs.python.org (Christoph Mathys)
Date: Tue, 16 Nov 2010 19:27:24 +0000
Subject: [issue10394] subprocess Popen deadlock
In-Reply-To: <1289570708.02.0.0744739807294.issue10394@psf.upfronthosting.co.za>
Message-ID: <1289935644.4.0.192402689663.issue10394@psf.upfronthosting.co.za>


Christoph Mathys <eraserix at gmail.com> added the comment:

Yes, it's the correct file. Sorry, I'm making quite a mess in my description about program: The "attached program" is deadlock.py. Program One and Two are python scripts executed using "python -c", the code is inside deadlock.py.

I installed python 2.7 (2.7.0+) and 3.1 (3.1.2, had to fix a print statement) and could reproduce the error on both versions. Checking the code in subprocess.py confirmed that the bug is still there. However, I had to increase the number of threads (deadlock.py, line 38) to provoke the error, but I used different hardware and OS release than in the first test ((but still multi core on Linux).

What do you expect on fail? I'm a noob when it comes to python, the script just prints "command took too long: <time>", nothing else...

----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10394>
_______________________________________

From report at bugs.python.org  Tue Nov 16 20:36:14 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 16 Nov 2010 19:36:14 +0000
Subject: [issue10437] ThreadPoolExecutor should accept max_workers=None
In-Reply-To: <1289936174.35.0.332227808259.issue10437@psf.upfronthosting.co.za>
Message-ID: <1289936174.35.0.332227808259.issue10437@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <stutzbach at google.com>:

ProcessPoolExecutor allows the max_workers parameter to the constructor to be omitted or None, in which case it will set the max_workers based on the number of CPUs.

It would be nice if ThreadPoolExecutor's constructor worked the same way; having the same interface is one of the wonderful things about this pair of classes.

I have a patch pretty much ready (with tests and a doc update), but it causes concurrent/futures/thread.py to import multiprocessing.  Were you trying to avoid that?

----------
assignee: stutzbach
components: Library (Lib)
messages: 121311
nosy: bquinlan, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: ThreadPoolExecutor should accept max_workers=None
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10437>
_______________________________________

From report at bugs.python.org  Tue Nov 16 21:04:47 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Tue, 16 Nov 2010 20:04:47 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289937887.46.0.147635429346.issue7900@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

On 11/16/10 5:44 AM, Ronald Oussoren wrote:
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
> Please explain how the failure can be reproduced.

I have. But to do so more directly:

1. Launch Terminal.app; leave the window console open.
2. Run: id -G
3. Run: python
4. Type: import posix; posix.getgroups()
5. Go into System Preferences, add a user.
6. Type again, posix.getgroups(): notice, the values have not changed.
7. Either os.system("id -G") or ^D and type id -G: in either case, these
values *have* changed. Tested both.

> I've done some testing on my machine using Apple's copy of python 2.6.1 (on OSX 10.6), which has the same getgroups implementation as the current heads of the active branches.

As I said, the slave is running the latest on 10.5. Perhaps its a
platform bug which is fixed in 10.6: either way, the test is declaring
behavior is true that it shouldn't, I think.

Perhaps the test should only be skipped on 10.5? I am happy to provide a
patch which tests sys.platform == "darwin" and then runs sw_vars to make
only skip < 10.6.

I verified posix.getgroups() on 10.6 does not appear to exhibit this
behavior on my SL slave. However, that box does a LOT, so I can't vouch
for its 'purity' like the 10.5 box.

> Was the buildbot started using launchd (the recipe at <http://buildbot.net/trac/wiki/UsingLaunchd> seems correct)? If not, how is it started?

It was started with launchd, yes: with a variation of that recipe.
However as I stated, the behavior can be readily reproduced directly in
Terminal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Tue Nov 16 21:08:09 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Tue, 16 Nov 2010 20:08:09 +0000
Subject: [issue2901] "error: can't allocate region" from mmap() when receiving
	big chunk of data
In-Reply-To: <1211069816.05.0.311102248623.issue2901@psf.upfronthosting.co.za>
Message-ID: <1289938089.54.0.205532796424.issue2901@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

I can try to do some testing to reproduce w/ 2.7: 2.5 was IIRC 32-bit on leopard by default though, so should I force a non-64-bit build to test this? I'm not entirely sure if that'll change things, but want to make sure. I can test with both 2.5 and 2.7 on leopard.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2901>
_______________________________________

From report at bugs.python.org  Tue Nov 16 21:23:32 2010
From: report at bugs.python.org (Ian)
Date: Tue, 16 Nov 2010 20:23:32 +0000
Subject: [issue10438] list an example for calling static methods from WITHIN
	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>


New submission from Ian <ifreecarve at gmail.com>:

Concerning this section of the docs:
http://docs.python.org/library/functions.html#staticmethod

There is no example for calling a static method from another static method within the same class.

As I discovered later, it's simple: C.f() -- from inside the class or outside it.

A total newbie will accept this and move on... but in other programming languages, it's frowned upon to the class name from within the class.  For example, in PHP you use the "self::" prefix and Java you don't need a prefix at all.  

So, even though I had it right the first time, it didn't SEEM right... so I went on a wild goose chase, for nothing.  Googling "java call static method" will get you java documentation that lists both cases, as does "c++ call static method" and "php call static method".  

I feel that by adding "Note: you must also use the C.f() syntax when calling from within the class", the documentation will be more complete.

----------
assignee: docs at python
components: Documentation
messages: 121314
nosy: docs at python, ifreecarve
priority: normal
severity: normal
status: open
title: list an example for calling static methods from WITHIN classes
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10438>
_______________________________________

From report at bugs.python.org  Tue Nov 16 22:02:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Nov 2010 21:02:36 +0000
Subject: [issue10438] list an example for calling static methods from WITHIN
	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1289941356.8.0.949981355561.issue10438@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

IMO this follows logically from Python's self-consistent rules.  I'm not convinced that the amount of extra verbiage required to detail this particular case would make the docs clearer, but you are welcome to suggest a wording for us to consider.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10438>
_______________________________________

From report at bugs.python.org  Tue Nov 16 22:04:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Nov 2010 21:04:02 +0000
Subject: [issue10438] list an example for calling static methods from WITHIN
	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1289941442.59.0.973669100063.issue10438@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Woops, I see you did suggest a wording.  However, what you wrote is imprecise and confused me when I first read it (I thought you meant that self.f() didn't work!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10438>
_______________________________________

From report at bugs.python.org  Tue Nov 16 22:04:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 16 Nov 2010 21:04:59 +0000
Subject: [issue10438] list an example for calling static methods from WITHIN
	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1289941499.2.0.299370522329.issue10438@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I tend to agree with David.  Especially since calling base class methods also uses the explicit class name.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10438>
_______________________________________

From report at bugs.python.org  Tue Nov 16 22:05:48 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Tue, 16 Nov 2010 21:05:48 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1289941548.86.0.956143365816.issue6745@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

We'll try to solve this for 3.2.

----------
assignee:  -> lukasz.langa
nosy: +lukasz.langa
priority: normal -> high
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Tue Nov 16 22:06:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 16 Nov 2010 21:06:20 +0000
Subject: [issue10438] list an example for calling static methods from WITHIN
	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1289941580.81.0.214232295335.issue10438@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> However, what you wrote is imprecise and confused me when I first read
> it (I thought you meant that self.f() didn't work!).

Well, it doesn't work in the specific case he mentioned of calling from another static method :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10438>
_______________________________________

From report at bugs.python.org  Tue Nov 16 22:08:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 16 Nov 2010 21:08:09 +0000
Subject: [issue10438] list an example for calling static methods from WITHIN
	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1289941689.55.0.821097511999.issue10438@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Only because you don't *have* self.  Which is why I said "imprecise" and not "incorrect" :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10438>
_______________________________________

From report at bugs.python.org  Tue Nov 16 23:17:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 22:17:59 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1289945879.38.0.0118044311053.issue10435@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg <mal at egenix.com> wrote:
> Alexander Belopolsky wrote:
..
>> I also have a similar question about C API. ?Here, in absence of
>> __all__, the answer should be clear: all symbols in public header
>> files should start with either _Py_ or Py_ and those that start with
>> Py_ are public. ? The question is what should be done with names that
>> start with Py_, but are not documented? ?Can we add an underscore to
>> those names? ?If so, should a (deprecated) alias be made available?
>> Should they be documented as deprecated?
>>
>> I think these questions can only be answered on a case by case bases
>> which choices being:
>>
>> 1. Document.
>> 2. Document as deprecated.
>> 3. Document as deprecated, add underscore prefix and retain a deprecated alias.
>> 4. Add an underscore prefix.
>>
>> The specific set of names that I would like to consider is the
>> following from unicode.h. ?I am marking with (*) the names that I
>> think should be documented and with (D) those that should be
>> deprecated:
>>
>> PyUnicode_GetMax
>> PyUnicode_Resize (*)
>> PyUnicode_InternImmortal
>> PyUnicode_FromOrdinal (*)
>> PyUnicode_GetDefaultEncoding (D)
>> PyUnicode_AsDecodedObject
>> PyUnicode_AsDecodedUnicode
>> PyUnicode_AsEncodedObject
>> PyUnicode_AsEncodedUnicode
>> PyUnicode_BuildEncodingMap
>> PyUnicode_EncodeDecimal (*)
>> PyUnicode_Append (*)
>> PyUnicode_AppendAndDel (*)
>> PyUnicode_Partition (*)
>> PyUnicode_RPartition (*)
>> PyUnicode_RSplit (*)
>> PyUnicode_IsIdentifier (*)
>> Py_UNICODE_strlen
>> Py_UNICODE_strcpy
>> Py_UNICODE_strcat
>> Py_UNICODE_strncpy
>> Py_UNICODE_strcmp
>> Py_UNICODE_strncmp
>> Py_UNICODE_strchr
>> Py_UNICODE_strrchr
>
> For Unicode, unicodeobject.h defines which APIs are private or not.
> APIs which don't appear in the header file are either private or
> need to be added to the header file (but I don't think there are
> any in this category).
>
> All APIs in the header that do not appear in the documentation,
> should be added there as well. unicodeobject.h already provides
> documentation for most of the APIs you've listed above (except some
> new ones that were added later on).
>
> One API I'm not sure about is PyUnicode_AppendAndDel(). It's somewhat
> obscure and given that we already have PyUnicode_Concat(), I think
> it should be made private and eventually dropped.
>

I would also like to nominate PyUnicode_AsEncodedObject and PyUnicode_AsEncodedUnicode.  The later is a particularly attractive candidate for removal because it appears to be broken:

    v = PyCodec_Encode(unicode, encoding, errors);
    if (v == NULL)
        goto onError;
    if (!PyUnicode_Check(v)) {
        PyErr_Format(PyExc_TypeError,
                     "encoder did not return an str object (type=%.400s)",
                     Py_TYPE(v)->tp_name);

Since PyCodec_Encode() returns bytes in 3.x, the code above will always raise an error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Tue Nov 16 23:21:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 22:21:43 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1289946103.7.0.187570362524.issue10435@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +haypo, lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Tue Nov 16 23:32:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 16 Nov 2010 22:32:50 +0000
Subject: [issue10430] _sha.sha().digest() method is endian-sensitive. and
	hexdigest()
In-Reply-To: <1289893015.01.0.604303806999.issue10430@psf.upfronthosting.co.za>
Message-ID: <1289946770.41.0.468612479708.issue10430@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/issue10430>
_______________________________________

From report at bugs.python.org  Tue Nov 16 23:44:25 2010
From: report at bugs.python.org (Ian)
Date: Tue, 16 Nov 2010 22:44:25 +0000
Subject: [issue10438] list an example for calling static methods from WITHIN
	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1289947465.09.0.0488812610041.issue10438@psf.upfronthosting.co.za>


Ian <ifreecarve at gmail.com> added the comment:

Am I to understand that self.f() is a valid way to call a static method?  Can you see how that would run counter to intuition for someone who is familiar with other languages?

Given that, I would make the following (more precise) change:

< It can be called either on the class (such as C.f()) or on an instance (such as C().f()). 
---
> It can be called either on the class (such as C.f()) or on an instance (such as C().f() or self.f()).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10438>
_______________________________________

From report at bugs.python.org  Tue Nov 16 23:45:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 22:45:34 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1289947534.32.0.0748629327808.issue10435@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

PyUnicode_AsDecodedObject() and PyUnicode_AsDecodedUnicode() appear to be broken as well: both start with a PyUnicode_Check(unicode) and then pass unicode to PyCodec_Decode() which expects bytes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Tue Nov 16 23:49:57 2010
From: report at bugs.python.org (Ian)
Date: Tue, 16 Nov 2010 22:49:57 +0000
Subject: [issue10438] list an example for calling static methods from WITHIN
	classes
In-Reply-To: <1289939012.34.0.0666500494472.issue10438@psf.upfronthosting.co.za>
Message-ID: <1289947797.97.0.216405282845.issue10438@psf.upfronthosting.co.za>


Ian <ifreecarve at gmail.com> added the comment:

Disregard my previous comment; calling self.f() does not work from a static method.

I stand by my previous suggestion, but I'll clarify it like this:

"Note: you must also use the C.f() syntax when calling from a static method within the C class"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10438>
_______________________________________

From report at bugs.python.org  Tue Nov 16 23:54:45 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 16 Nov 2010 22:54:45 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1289948085.02.0.450866318383.issue10435@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Please note that PyCodec_Encode()/PyCodec_Decode() will return whatever the codec returns for these operations.

The codec system is not limited to converting between Unicode and bytes only.

A typical example is a same-type codec such as rot13 that only transforms Unicode data.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Wed Nov 17 00:14:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 23:14:57 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289948085.02.0.450866318383.issue10435@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=y2uaFa1DRinJp__bHdjJskyO6foYJ2DHqF5D0@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Nov 16, 2010 at 5:54 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> Please note that PyCodec_Encode()/PyCodec_Decode() will return whatever the codec returns for these operations.
>
> The codec system is not limited to converting between Unicode and bytes only.

Not according to the latest reST documentation:

"""
* Encoding converts a string object to a bytes object using a
particular character set encoding (e.g., cp1252 or iso-8859-1).

* Decoding converts a bytes object encoded using a particular
character set encoding to a string object.
""" http://docs.python.org/dev/library/codecs.html?highlight=codecs#codecs.Codec.encode

> A typical example is a same-type codec such as rot13 that only transforms Unicode data.

I thought rot13 would only transform English (or Latin) alphabet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Wed Nov 17 00:18:53 2010
From: report at bugs.python.org (v_peter)
Date: Tue, 16 Nov 2010 23:18:53 +0000
Subject: [issue9173] logger statement not guarded in shutil._make_tarball
In-Reply-To: <1278374700.0.0.888108186461.issue9173@psf.upfronthosting.co.za>
Message-ID: <1289949533.34.0.513614329168.issue9173@psf.upfronthosting.co.za>


v_peter <leanmeandonothingmachine at gmail.com> added the comment:

Added a test to the patch

----------
nosy: +v_peter
Added file: http://bugs.python.org/file19620/shutil_logger_with_test.py27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9173>
_______________________________________

From report at bugs.python.org  Wed Nov 17 00:58:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 16 Nov 2010 23:58:08 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1289951888.3.0.800508628216.issue10435@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch documents all previously undocumented unicode C API functions.  Note that for the PyUnicode_As{En,De}codedObject() and PyUnicode_As{En,De}DecodedUnicode() functions I attempted to capture what they are supposed to do rather than what the current implementation does.

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19621/issue10435.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Wed Nov 17 01:08:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 00:08:56 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Python Codec Registry and support functions are well documented in codecs.h header file.  It should be easy to convert that to reST.

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 121329
nosy: belopolsky, docs at python, haypo, lemburg, loewis
priority: normal
severity: normal
stage: needs patch
status: open
title: PyCodec C API is not documented in reST
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10439>
_______________________________________

From report at bugs.python.org  Wed Nov 17 01:19:09 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 17 Nov 2010 00:19:09 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <AANLkTi=y2uaFa1DRinJp__bHdjJskyO6foYJ2DHqF5D0@mail.gmail.com>
Message-ID: <4CE31F78.4010705@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, Nov 16, 2010 at 5:54 PM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
>>
>> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>>
>> Please note that PyCodec_Encode()/PyCodec_Decode() will return whatever the codec returns for these operations.
>>
>> The codec system is not limited to converting between Unicode and bytes only.
> 
> Not according to the latest reST documentation:
> 
> """
> * Encoding converts a string object to a bytes object using a
> particular character set encoding (e.g., cp1252 or iso-8859-1).
> 
> * Decoding converts a bytes object encoded using a particular
> character set encoding to a string object.
> """ http://docs.python.org/dev/library/codecs.html?highlight=codecs#codecs.Codec.encode

That's another documentation bug, then. The codec system has always
supported other type combinations for encoding/decoding as well.

Only certain methods on str and bytes objects in 3.x limit the possible
types to either str or bytes - which probably results in the
idea that Python codecs don't support anything else.

The text from the 2.7 documentation is correct, also for 3.x:

http://docs.python.org/library/codecs.html#codec-objects

>> A typical example is a same-type codec such as rot13 that only transforms Unicode data.
> 
> I thought rot13 would only transform English (or Latin) alphabet.

Right, everything else passes through as-is.

Other examples are codecs that escape certain code points using e.g.
XML entity sequences, backslash notations or other such techniques.

For bytes, you have the zip, base64 and hex codecs which work in
a similar way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Wed Nov 17 01:25:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 00:25:13 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <4CE31F78.4010705@egenix.com>
Message-ID: <AANLkTikdsCVXFGLBMg9BCa8wJLt1jQ8Zw9r=4nBFj_1_@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Nov 16, 2010 at 7:19 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
>> * Decoding converts a bytes object encoded using a particular
>> character set encoding to a string object.
>> """ http://docs.python.org/dev/library/codecs.html?highlight=codecs#codecs.Codec.encode
>
> That's another documentation bug, then. The codec system has always
> supported other type combinations for encoding/decoding as well.
>
> Only certain methods on str and bytes objects in 3.x limit the possible
> types to either str or bytes - which probably results in the
> idea that Python codecs don't support anything else.
>
> The text from the 2.7 documentation is correct, also for 3.x:
>
> http://docs.python.org/library/codecs.html#codec-objects
>

I agree and will handle this in #10435 because codecs.h
(unsurprisingly) supports your POV and we don't want C-API docs to be
in conflict with Py-API docs.

If you have time, please take a look at
PyUnicode_As{En,De}codedObject() and
PyUnicode_As{En,De}DecodedUnicode() documentation in the attached
patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Wed Nov 17 02:04:03 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 17 Nov 2010 01:04:03 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1289955843.22.0.760467000396.issue10435@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/issue10435>
_______________________________________

From report at bugs.python.org  Wed Nov 17 02:04:27 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 17 Nov 2010 01:04:27 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1289955867.8.0.682567480441.issue10439@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/issue10439>
_______________________________________

From report at bugs.python.org  Wed Nov 17 02:11:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 01:11:55 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1289956315.55.0.328124510249.issue10435@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> I agree and will handle this in #10435 because codecs.h

s/#10435/#10439/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Wed Nov 17 03:11:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 17 Nov 2010 02:11:57 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289959917.43.0.291501727246.issue7900@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The problem Stephen is seeing with the buildbot machine is ABI-dependent; the behavior of getgroups(2) changed in 10.6.  You can demonstrate this all on a 10.6 system.  Open a terminal session and verify the process's groups:

$ id -G
20 40200 401 204 100 98 80 61 12 403 40100 103
$ /usr/local/bin/python3.2 -c 'import posix; print(posix.getgroups())'
[20, 40200, 401, 204, 100, 98, 80, 61, 12, 403, 40100, 103]

Now create a new user with System Preferences.  One of the quirks here is that OS X 10.5 and 10.6 create a new group for that user and assign other existing users to that group.  (The new group is one of the somewhat mysteriously named com.apple.sharepoint.group.n groups.)

Still in the same terminal session after the new user/group was created and the existing user name we are running under was automatically added to the new group:
$ id -G
20 40200 401 204 100 98 80 61 12 403 40100 402 103
$ # note: new group membership 402 = com.apple.sharepoint.group.1
$ now test with 3 Pythons built from the same source, py3k tip:
$ cd ../../sdk10-4/py3k/
$ ./python -c 'import posix; print(posix.getgroups())'
[20, 40200, 401, 204, 100, 98, 80, 61, 12, 403, 40100, 103]
$ cd ../../sdk10-5/py3k/
$ ./python -c 'import posix; print(posix.getgroups())'
[20, 40200, 401, 204, 100, 98, 80, 61, 12, 403, 40100, 103]
$ cd ../../sdk10-6/py3k/
$ ./python -c 'import posix; print(posix.getgroups())'
[20, 40200, 401, 204, 100, 98, 80, 61, 12, 403, 40100, 402, 103]

Only the version built with a deployment target of 10.6 - that is, using the 10.6 SDK and the 10.6 ABI - reflects the updated grouplist.  And that difference can be seen, as Alexander noted earlier, in the symbols referenced.  An nm ./python | grep getgroups for each shows:
    U _getgroups$DARWIN_EXTSN
for the 10.6 deployment target version but
    U _getgroups
for the 10.5 and 10.4 targeted versions.

So unless building for a deployment target of 10.6 (or higher), it is to be expected that the output of /usr/bin/id will not match the results of getgroups(2) if the user's group membership changes during the run (as can happen when another user is created or deleted).

This particular problem should only be an issue when running on 10.5 and higher and using a 10.5 or earlier ABI.  On 10.4, neither getgroups(2) (as expected) nor /usr/bin/id see updates to group memberships made during the lifetime of the parent terminal session; starting a new login terminal session does see the updates.

Also note that this issue would be observable with all existing current python.org OS X installers running on 10.5 or 10.6 as most have been built with a 10.3 deployment target while 2.7 also provides an additional 32-/64-bit one with a 10.5 deployment target.  (I believe Ronald intends to build future 32-/64-bit installers with a 10.6 deployment target so they would be the first to not be subject to this issue.)

FTR, here are the configure options I used for each build:

./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk --with-universal-archs=32-bit MACOSX_DEPLOYMENT_TARGET=10.4

./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.5.sdk --with-universal-archs=intel MACOSX_DEPLOYMENT_TARGET=10.5

./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk --with-universal-archs=intel MACOSX_DEPLOYMENT_TARGET=10.6

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Wed Nov 17 03:16:27 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 17 Nov 2010 02:16:27 +0000
Subject: [issue7900] posix.getgroups() failure on Mac OS X
In-Reply-To: <1265814298.66.0.86998714187.issue7900@psf.upfronthosting.co.za>
Message-ID: <1289960187.11.0.543037011883.issue7900@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Argh! Just to be very clear, those ./configure commands are all one line, including the MACOSX_DEPLOYMENT_TARGET as an argument to the configure script.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7900>
_______________________________________

From report at bugs.python.org  Wed Nov 17 03:58:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 02:58:16 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1289962696.48.0.357775950685.issue10435@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like I misunderstood what PyUnicode_As{En,De}codedObject() and
PyUnicode_As{En,De}codedUnicode() functions are designed to do.  Attaching a corrected patch, issue10435a.diff.

----------
Added file: http://bugs.python.org/file19622/issue10435a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Wed Nov 17 05:59:49 2010
From: report at bugs.python.org (Robert Collins)
Date: Wed, 17 Nov 2010 04:59:49 +0000
Subject: [issue10440] support RUSAGE_THREAD as a constant in the resource
	module
In-Reply-To: <1289969988.98.0.873243302667.issue10440@psf.upfronthosting.co.za>
Message-ID: <1289969988.98.0.873243302667.issue10440@psf.upfronthosting.co.za>


New submission from Robert Collins <robertc at robertcollins.net>:

RUSAGE_THREAD (since Linux 2.6.26)
              Return resource usage statistics for the calling thread.

This is very handy for multi threaded apps in determining runtime in a thread, page faults from the thread etc.

----------
messages: 121336
nosy: rbcollins
priority: normal
severity: normal
status: open
title: support RUSAGE_THREAD as a constant in the resource module
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10440>
_______________________________________

From report at bugs.python.org  Wed Nov 17 10:26:35 2010
From: report at bugs.python.org (david)
Date: Wed, 17 Nov 2010 09:26:35 +0000
Subject: [issue10442] Please by default enforce ssl certificate checking in
	modules that can have user's which *depend* on the security of
	the ssl connection.
In-Reply-To: <1289985995.18.0.175353839662.issue10442@psf.upfronthosting.co.za>
Message-ID: <1289985995.18.0.175353839662.issue10442@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

Please by default enforce ssl certificate checking in modules that can have user's which *depend* on the security of the ssl connection.

See https://bugs.launchpad.net/ubuntu/+source/offlineimap/+bug/675120
http://bugs.python.org/issue10274
http://bugs.python.org/issue1589

and http://seclists.org/oss-sec/2010/q4/33

So I will name the following modules(as a  starting point):
1. httplib http://docs.python.org/library/httplib.html
2. urllib http://docs.python.org/library/urllib.html
3. urllib2 http://docs.python.org/library/urllib2.html
4. imaplib http://docs.python.org/library/imaplib.html

----------
messages: 121338
nosy: db
priority: normal
severity: normal
status: open
title: Please by default enforce ssl certificate checking in modules that can have user's which *depend* on the security of the ssl connection.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10442>
_______________________________________

From report at bugs.python.org  Wed Nov 17 10:26:32 2010
From: report at bugs.python.org (david)
Date: Wed, 17 Nov 2010 09:26:32 +0000
Subject: [issue10441] Please by default enforce ssl certificate checking in
	modules that can have user's which *depend* on the security of
	the ssl connection.
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>


New submission from david <db.pub.mail at gmail.com>:

Please by default enforce ssl certificate checking in modules that can have user's which *depend* on the security of the ssl connection.

See https://bugs.launchpad.net/ubuntu/+source/offlineimap/+bug/675120
http://bugs.python.org/issue10274
http://bugs.python.org/issue1589

and http://seclists.org/oss-sec/2010/q4/33

So I will name the following modules(as starting point):
1. httplib http://docs.python.org/library/httplib.html
2. urllib http://docs.python.org/library/urllib.html
3. urllib2 http://docs.python.org/library/urllib2.html
4. imaplib http://docs.python.org/library/imaplib.html

----------
messages: 121337
nosy: db
priority: normal
severity: normal
status: open
title: Please by default enforce ssl certificate checking in modules that can have user's which *depend* on the security of the ssl connection.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov 17 10:32:27 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 17 Nov 2010 09:32:27 +0000
Subject: [issue10442] Please by default enforce ssl certificate checking in
	modules that can have user's which *depend* on the security of
	the ssl connection.
In-Reply-To: <1289985995.18.0.175353839662.issue10442@psf.upfronthosting.co.za>
Message-ID: <1289986347.73.0.314734990582.issue10442@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Please by default enforce ssl certificate checking in modules that can have user's which *depend* on the security of the ssl connection.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10442>
_______________________________________

From report at bugs.python.org  Wed Nov 17 10:32:31 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Wed, 17 Nov 2010 09:32:31 +0000
Subject: [issue10436] tarfile.extractfile in "r|" stream mode fails with
	filenames or members from getmembers()
In-Reply-To: <1289931464.79.0.618120236196.issue10436@psf.upfronthosting.co.za>
Message-ID: <1289986351.0.0.334148036449.issue10436@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

This behaviour is intentional. A tar archive does not contain a central directory structure, it is just a chain of files. As a side-effect it is possible to have multiple files with the same name in one archive, e.g. when append mode was used. That's why the archive must be scanned from the beginning to the end as soon as you reference an archive member by its name.
The best way to deal with this issue in my opinion is to improve the documentation for the stream interface.

----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel
priority: normal -> low
versions: +Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10436>
_______________________________________

From report at bugs.python.org  Wed Nov 17 10:37:10 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 17 Nov 2010 09:37:10 +0000
Subject: [issue10441] Please by default enforce ssl certificate checking in
	modules that can have user's which *depend* on the security of
	the ssl connection.
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1289986630.35.0.445525577236.issue10441@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +pitrou
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov 17 10:47:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Nov 2010 09:47:51 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1197387663.32.0.0598513497038.issue1589@psf.upfronthosting.co.za>
Message-ID: <1289987271.92.0.171410613361.issue1589@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/issue1589>
_______________________________________

From report at bugs.python.org  Wed Nov 17 10:48:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 09:48:19 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1289987299.19.0.624834242016.issue10441@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

http.client and urllib.request are already done (*), and imaplib is covered in issue10274.

(*) http://docs.python.org/dev/library/http.client.html
http://docs.python.org/dev/library/urllib.request.html

Do you have other modules in mind or should I close this issue?

----------
stage:  -> needs patch
title: Please by default enforce ssl certificate checking in modules that can have user's which *depend* on the security of the ssl connection. -> some stdlib modules need to be updated to handle SSL certificate validation
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov 17 10:50:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Nov 2010 09:50:13 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1289987413.54.0.369860566456.issue10441@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/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov 17 10:50:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Nov 2010 09:50:26 +0000
Subject: [issue10274] imaplib should provide a means to validate a remote
	server ssl certificate(s)
In-Reply-To: <1288583733.85.0.123923377362.issue10274@psf.upfronthosting.co.za>
Message-ID: <1289987426.33.0.605135329684.issue10274@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/issue10274>
_______________________________________

From report at bugs.python.org  Wed Nov 17 11:12:39 2010
From: report at bugs.python.org (david)
Date: Wed, 17 Nov 2010 10:12:39 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1289988759.56.0.409392693403.issue10441@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

Sorry, I don't remember seeing the change-set /commit showing that is now on by default. (for those modules).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov 17 11:24:25 2010
From: report at bugs.python.org (david)
Date: Wed, 17 Nov 2010 10:24:25 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1289989465.27.0.72395203909.issue10441@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

Are you referring to
http://code.python.org/hg/branches/py3k/rev/86f97255bfc8

where there is now 
"
    2.29 +   .. warning::
    2.30 +      If neither *cafile* nor *capath* is specified, an HTTPS request
    2.31 +      will not do any verification of the server's certificate.
"
This doesnt' by default check the certificate does it ? 
IMHO it should use a sane system capath by default and do the checking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov 17 11:31:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 10:31:30 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289989465.27.0.72395203909.issue10441@psf.upfronthosting.co.za>
Message-ID: <1289989877.3772.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Are you referring to
> http://code.python.org/hg/branches/py3k/rev/86f97255bfc8
> 
> where there is now 
> "
>     2.29 +   .. warning::
>     2.30 +      If neither *cafile* nor *capath* is specified, an HTTPS request
>     2.31 +      will not do any verification of the server's certificate.
> "
> This doesnt' by default check the certificate does it ? 
> IMHO it should use a sane system capath by default and do the checking.

I'm afraid Python has no business validating and distributing CA
certificates. You have to use what is provided by your system libraries,
if possible, and otherwise bundle your own.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov 17 12:08:14 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Wed, 17 Nov 2010 11:08:14 +0000
Subject: [issue10432] concurrent.futures.as_completed() spins waiting for
	futures to complete
In-Reply-To: <1289905176.73.0.0627045532304.issue10432@psf.upfronthosting.co.za>
Message-ID: <1289992094.31.0.426288367603.issue10432@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Looks good but you forgot to actually use your new Waiter ;-)

Committed as r86491.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10432>
_______________________________________

From report at bugs.python.org  Wed Nov 17 12:09:37 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 17 Nov 2010 11:09:37 +0000
Subject: [issue10432] concurrent.futures.as_completed() spins waiting for
	futures to complete
In-Reply-To: <1289905176.73.0.0627045532304.issue10432@psf.upfronthosting.co.za>
Message-ID: <1289992177.69.0.643283496232.issue10432@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please mention the issue number in the commit message when applying patches or bugfixes.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10432>
_______________________________________

From report at bugs.python.org  Wed Nov 17 12:27:33 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Wed, 17 Nov 2010 11:27:33 +0000
Subject: [issue6745] (curses) addstr() takes str in Python 3
In-Reply-To: <1250805293.93.0.390407784339.issue6745@psf.upfronthosting.co.za>
Message-ID: <1289993253.81.0.783658322255.issue6745@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

Note that getkey() is broken, too. I attached a simple script to demonstrate that. If you run it and enter some non-ascii input, you can see that getkey() returns an utf-8 encoded str (in my utf-8 environment at least, I haven't check if it's always utf-8 or if it depends on the locale).

----------
Added file: http://bugs.python.org/file19623/getkey_sample.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6745>
_______________________________________

From report at bugs.python.org  Wed Nov 17 12:29:54 2010
From: report at bugs.python.org (Scott Dial)
Date: Wed, 17 Nov 2010 11:29:54 +0000
Subject: [issue10432] concurrent.futures.as_completed() spins waiting for
	futures to complete
In-Reply-To: <1289905176.73.0.0627045532304.issue10432@psf.upfronthosting.co.za>
Message-ID: <1289993394.75.0.561463416736.issue10432@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

Good catch. I suppose it was inevitable when I transferred my changes into a SVN checkout that I missed something. Nevertheless, your changeset in r86491 matches my own. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10432>
_______________________________________

From report at bugs.python.org  Wed Nov 17 12:30:41 2010
From: report at bugs.python.org (david)
Date: Wed, 17 Nov 2010 11:30:41 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289989877.3772.2.camel@localhost.localdomain>
Message-ID: <AANLkTingY-m3sqBK7OMawxTxPDXJP7UjW7qF8e7s9Ts-@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

Well, what are the usual paths for windows and linux?
Just try those(by default) and if this fails (no ca's paths work) then
raise an exception and have a parameter to disable this behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov 17 12:31:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 11:31:49 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <AANLkTingY-m3sqBK7OMawxTxPDXJP7UjW7qF8e7s9Ts-@mail.gmail.com>
Message-ID: <1289993504.3772.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Well, what are the usual paths for windows and linux?
> Just try those(by default) and if this fails (no ca's paths work) then
> raise an exception and have a parameter to disable this behaviour.

That's a possible resolution, but it needs a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov 17 12:43:57 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 17 Nov 2010 11:43:57 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1289994237.6.0.823781033993.issue10356@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Fixed the hash in r86492, excluding the TypeError fix.


Should I fix the TypeError in both 2.7 and 3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Wed Nov 17 13:04:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 12:04:48 +0000
Subject: [issue10443] add wrapper for SSL_CTX_set_default_verify_paths
In-Reply-To: <1289995488.37.0.849519588112.issue10443@psf.upfronthosting.co.za>
Message-ID: <1289995488.37.0.849519588112.issue10443@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

SSL_CTX_set_default_verify_paths allows to select the system-wide CA certificates on an SSL context, if OpenSSL was built with the right options.

We could also try to expose those default paths by calling X509_get_default_cert_file() / X509_get_default_cert_dir(), but these seem even less documented (private?).

----------
components: Library (Lib)
messages: 121351
nosy: pitrou
priority: normal
severity: normal
status: open
title: add wrapper for SSL_CTX_set_default_verify_paths
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10443>
_______________________________________

From report at bugs.python.org  Wed Nov 17 13:05:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 12:05:26 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1289995526.62.0.672892645753.issue10441@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, it seems OpenSSL is often built with the paths to system certificates, which can be enabled by an undocumented function. See issue10443.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov 17 13:25:27 2010
From: report at bugs.python.org (david)
Date: Wed, 17 Nov 2010 12:25:27 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1289996727.69.0.0821649494546.issue10441@psf.upfronthosting.co.za>


david <db.pub.mail at gmail.com> added the comment:

Interesting but you may want to ask the openssl developers about this first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Wed Nov 17 14:39:22 2010
From: report at bugs.python.org (Robert Collins)
Date: Wed, 17 Nov 2010 13:39:22 +0000
Subject: [issue10440] support RUSAGE_THREAD as a constant in the resource
	module
In-Reply-To: <1289969988.98.0.873243302667.issue10440@psf.upfronthosting.co.za>
Message-ID: <1290001162.4.0.581333868189.issue10440@psf.upfronthosting.co.za>


Changes by Robert Collins <robertc at robertcollins.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19624/rusage-thread.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10440>
_______________________________________

From report at bugs.python.org  Wed Nov 17 15:04:21 2010
From: report at bugs.python.org (Michael Hughes)
Date: Wed, 17 Nov 2010 14:04:21 +0000
Subject: [issue10444] A mechanism is needed to override waiting for Python
	threads to finish
In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>
Message-ID: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>


New submission from Michael Hughes <michaelahughes at gmail.com>:

We use the Python interpreter embedded in our application, and would prefer to not block an exit of our application waiting for non-daemon threads to finish.

I would like a mechanism exposed that queries for whether or not to wait.

----------
components: Library (Lib)
messages: 121354
nosy: michaelahughes
priority: normal
severity: normal
status: open
title: A mechanism is needed to override waiting for Python threads to finish
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10444>
_______________________________________

From report at bugs.python.org  Wed Nov 17 15:11:13 2010
From: report at bugs.python.org (Michael Hughes)
Date: Wed, 17 Nov 2010 14:11:13 +0000
Subject: [issue10444] A mechanism is needed to override waiting for Python
	threads to finish
In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>
Message-ID: <1290003073.02.0.41043239318.issue10444@psf.upfronthosting.co.za>


Michael Hughes <michaelahughes at gmail.com> added the comment:

I have a patch here.
It is to allow for a callback to be set on the main thread which gets called when there are non-daemon threads still alive on exit.
The callback returns True or False indicating whether or not it wants to block. By default, the whole thing blocks.

----------
keywords: +patch
Added file: http://bugs.python.org/file19625/threadingchange.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10444>
_______________________________________

From report at bugs.python.org  Wed Nov 17 15:13:59 2010
From: report at bugs.python.org (Michael Hughes)
Date: Wed, 17 Nov 2010 14:13:59 +0000
Subject: [issue10444] A mechanism is needed to override waiting for Python
	threads to finish
In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>
Message-ID: <1290003239.48.0.92482783487.issue10444@psf.upfronthosting.co.za>


Michael Hughes <michaelahughes at gmail.com> added the comment:

Scratch that last patch. It was missing part of the fix.
I've removed the old patch now, and submitted the proper one.

----------
Added file: http://bugs.python.org/file19626/real.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10444>
_______________________________________

From report at bugs.python.org  Wed Nov 17 15:14:04 2010
From: report at bugs.python.org (Michael Hughes)
Date: Wed, 17 Nov 2010 14:14:04 +0000
Subject: [issue10444] A mechanism is needed to override waiting for Python
	threads to finish
In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>
Message-ID: <1290003244.12.0.562869869609.issue10444@psf.upfronthosting.co.za>


Changes by Michael Hughes <michaelahughes at gmail.com>:


Removed file: http://bugs.python.org/file19625/threadingchange.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10444>
_______________________________________

From report at bugs.python.org  Wed Nov 17 15:15:28 2010
From: report at bugs.python.org (Emile Anclin)
Date: Wed, 17 Nov 2010 14:15:28 +0000
Subject: [issue10445] _ast py3k : add lineno back to "args" node
In-Reply-To: <1290003328.01.0.315649649266.issue10445@psf.upfronthosting.co.za>
Message-ID: <1290003328.01.0.315649649266.issue10445@psf.upfronthosting.co.za>


New submission from Emile Anclin <emile.anclin at logilab.fr>:

For Python3x, in the tree generated by _ast, for the "args" node (representing an argument of a function), the "lineno" (and the "col_offset") information disappeared from those nodes.

It would be nice to have them back (for instance for Pylint)

----------
components: None
messages: 121357
nosy: emile.anclin
priority: normal
severity: normal
status: open
title: _ast py3k : add lineno back to "args" node
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10445>
_______________________________________

From report at bugs.python.org  Wed Nov 17 15:20:17 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 17 Nov 2010 14:20:17 +0000
Subject: [issue10444] A mechanism is needed to override waiting for Python
	threads to finish
In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>
Message-ID: <1290003617.05.0.72545629023.issue10444@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

How do you use it?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10444>
_______________________________________

From report at bugs.python.org  Wed Nov 17 15:25:04 2010
From: report at bugs.python.org (Michael Hughes)
Date: Wed, 17 Nov 2010 14:25:04 +0000
Subject: [issue10444] A mechanism is needed to override waiting for Python
	threads to finish
In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>
Message-ID: <1290003904.93.0.674588726391.issue10444@psf.upfronthosting.co.za>


Michael Hughes <michaelahughes at gmail.com> added the comment:

To use the callback, you can do this:

import threading

def threadendcallback():
  # return False to indicate that we don't
  # want to wait for any threads before exiting
  return False

threading.currentThread().waitForThreadsOnExitFunc = threadendcallback

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10444>
_______________________________________

From report at bugs.python.org  Wed Nov 17 15:27:52 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 17 Nov 2010 14:27:52 +0000
Subject: [issue10444] A mechanism is needed to override waiting for Python
	threads to finish
In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>
Message-ID: <1290004072.89.0.330352348156.issue10444@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Why is setting your threads as daemons not an option?

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10444>
_______________________________________

From report at bugs.python.org  Wed Nov 17 16:32:05 2010
From: report at bugs.python.org (Jeff Hull)
Date: Wed, 17 Nov 2010 15:32:05 +0000
Subject: [issue6327] [mimetext] long lines get cut with exclamation mark and
	newline
In-Reply-To: <1245767587.65.0.844328731918.issue6327@psf.upfronthosting.co.za>
Message-ID: <1290007925.3.0.941598640021.issue6327@psf.upfronthosting.co.za>


Jeff Hull <jsh2134 at gmail.com> added the comment:

I also have this problem with text getting replaced with the exclamation point.

I am using this class.
from email.MIMEText import MIMEText

Perhaps it didn't work for you because you didn't send it via email. 

try this code

	msgAlternative = MIMEMultipart('alternative')
	msgText = MIMEText(text, 'html')
	msgAlternative.attach(msgText)
	msg.attach(msgAlternative)	

	mailServer = smtplib.SMTP()
	mailServer.connect(serverURL)
	mailServer.login(user, pass)
	mailServer.sendmail(sender,to, msg.as_string())
	mailServer.quit()

----------
nosy: +Jeff.Hull

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6327>
_______________________________________

From report at bugs.python.org  Wed Nov 17 17:03:16 2010
From: report at bugs.python.org (David Nesting)
Date: Wed, 17 Nov 2010 16:03:16 +0000
Subject: [issue10436] tarfile.extractfile in "r|" stream mode fails with
	filenames or members from getmembers()
In-Reply-To: <1289931464.79.0.618120236196.issue10436@psf.upfronthosting.co.za>
Message-ID: <1290009796.36.0.737343492638.issue10436@psf.upfronthosting.co.za>


David Nesting <david at fastolfe.net> added the comment:

Thanks, Lars.  And this does make complete sense to me in retrospect.

Better documentation here would help a lot.  I'm happy to take a stab at this.  Short of labeling methods as "safe for streaming" versus "unsafe for streaming", it occurs to me that it would be a lot cleaner if TarFile were actually broken up into two classes: one streaming-safe, and the other layering random access convenience methods on top of that.  For compatibility's sake the open method should probably still return an instance of the composite class, but at least it keeps these logically separate internally and makes it easier to document.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10436>
_______________________________________

From report at bugs.python.org  Wed Nov 17 17:18:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 17 Nov 2010 16:18:28 +0000
Subject: [issue6327] [mimetext] long lines get cut with exclamation mark and
	newline
In-Reply-To: <1245767587.65.0.844328731918.issue6327@psf.upfronthosting.co.za>
Message-ID: <1290010708.01.0.867941988626.issue6327@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Perhaps.

You can help narrow this down by doing the following:  In your program do a 'print msg.as_string()' and see if you see the ! problem there.

If not, try using several different SMTP servers to send your email.  If the ! problem shows up with all of them, then perhaps the problem is with smtplib.  In that case, please post a full working program including all needed input data so that I can test it myself against my own mail server.

Also please confirm that the problem still exists if you use 2.7, since that is the only 2.x release that gets bug fixes at this time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6327>
_______________________________________

From report at bugs.python.org  Wed Nov 17 17:20:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 16:20:06 +0000
Subject: [issue10440] support RUSAGE_THREAD as a constant in the resource
	module
In-Reply-To: <1289969988.98.0.873243302667.issue10440@psf.upfronthosting.co.za>
Message-ID: <1290010806.6.0.0604150521063.issue10440@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you! I've committed the patch in r86493.

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10440>
_______________________________________

From report at bugs.python.org  Wed Nov 17 18:32:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 17:32:23 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

$ pydoc3.1 pydoc

Help on module pydoc:

NAME
    pydoc - Generate Python documentation in HTML or text for interactive use.

FILE
    /opt/local/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/pydoc.py

MODULE DOCS
    http://docs.python.org/library/pydoc

I suggest changing the default base URL to

http://docs.python.org/release/X.Y.Z

I would also like to take this opportunity and make some other improvements:

1. Clarify that the linked document is the authoritative reference and that generated documentation may expose functions that are considered internal and subject to change or removal.  (Suggestions for an exact wording are welcome.)

2. Move the FILE section to the end.  This will free up some screen space for an expanded "AUTHORITATIVE REFERENCE" section.  (Yes, I think the section title "MODULE DOCS" can be improved, but my mind is not set on any particular alternative.)

3. Do not include __special__ names in the DATA section.  At the very least, exclude __author__, __version__, and other special names that cause generation of document sections:

DATA
    __author__ = 'Ka-Ping Yee <ping at lfw.org>'
    __credits__ = 'Guido van Rossum, for an excellent programming l...erla...
    __date__ = '26 February 2001'
    __version__ = '$Revision: 78210 $'

VERSION
    78210

DATE
    26 February 2001
..

----------
assignee: belopolsky
components: Documentation, Library (Lib)
messages: 121365
nosy: belopolsky
priority: normal
severity: normal
status: open
title: pydoc3 links to 2.x library reference
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Wed Nov 17 18:34:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 17:34:30 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290015270.49.0.421129919957.issue10446@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Wed Nov 17 18:44:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 17:44:55 +0000
Subject: [issue10443] add wrapper for SSL_CTX_set_default_verify_paths
In-Reply-To: <1289995488.37.0.849519588112.issue10443@psf.upfronthosting.co.za>
Message-ID: <1290015895.38.0.689495503281.issue10443@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file19627/default_verify_paths.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10443>
_______________________________________

From report at bugs.python.org  Wed Nov 17 18:56:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 17:56:51 +0000
Subject: [issue10411] Pickle benchmark fails after converting Benchmark Suite
	to py3k
In-Reply-To: <1289689237.0.0.348719210289.issue10411@psf.upfronthosting.co.za>
Message-ID: <1290016611.93.0.796523681607.issue10411@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Pushed in 2c5c6d3f399b, thanks.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10411>
_______________________________________

From report at bugs.python.org  Wed Nov 17 18:57:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 17:57:11 +0000
Subject: [issue10411] Pickle benchmark fails after converting Benchmark Suite
	to py3k
In-Reply-To: <1289689237.0.0.348719210289.issue10411@psf.upfronthosting.co.za>
Message-ID: <1290016631.15.0.638270095471.issue10411@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Woops, sorry, wrong issue.

----------
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10411>
_______________________________________

From report at bugs.python.org  Wed Nov 17 18:57:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 17:57:26 +0000
Subject: [issue10412] Add py3k support for "slow" pickle benchmark in
	Benchmark Suite
In-Reply-To: <1289692538.69.0.952593194282.issue10412@psf.upfronthosting.co.za>
Message-ID: <1290016646.7.0.348990141161.issue10412@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Pushed in 2c5c6d3f399b, thanks.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10412>
_______________________________________

From report at bugs.python.org  Wed Nov 17 19:02:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 18:02:10 +0000
Subject: [issue10411] Pickle benchmark fails after converting Benchmark Suite
	to py3k
In-Reply-To: <1289689237.0.0.348719210289.issue10411@psf.upfronthosting.co.za>
Message-ID: <1290016930.74.0.47079720371.issue10411@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Pushed in 92088733aade and 8dd7a860a2fa, thanks.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10411>
_______________________________________

From report at bugs.python.org  Wed Nov 17 19:04:57 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 17 Nov 2010 18:04:57 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <AANLkTikdsCVXFGLBMg9BCa8wJLt1jQ8Zw9r=4nBFj_1_@mail.gmail.com>
Message-ID: <4CE41944.5000700@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> If you have time, please take a look at
> PyUnicode_As{En,De}codedObject() and
> PyUnicode_As{En,De}DecodedUnicode() documentation in the attached
> patch.

Thanks. I'll try to have a look later tonight.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Wed Nov 17 19:17:31 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Wed, 17 Nov 2010 18:17:31 +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: <1290017851.29.0.740919468961.issue9518@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

I agree that this is annoying, we get the same thing in Cython's test suite all over the place. Any foreign warning that doesn't get triggered helps in debugging your own code. And this one is easy to avoid.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9518>
_______________________________________

From report at bugs.python.org  Wed Nov 17 19:20:17 2010
From: report at bugs.python.org (Kapil Thangavelu)
Date: Wed, 17 Nov 2010 18:20:17 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1290018017.38.0.764231020332.issue4111@psf.upfronthosting.co.za>


Changes by Kapil Thangavelu <kapil.foss at gmail.com>:


----------
nosy: +hazmat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Nov 17 19:31:47 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 17 Nov 2010 18:31:47 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290018707.09.0.233165494924.issue10446@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1 to all.  What about the best of both worlds: "MODULE REFERENCE"?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Wed Nov 17 19:37:11 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 17 Nov 2010 18:37:11 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1290019031.98.0.63122359216.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Dave, we need some kind of documentation, if we expect to ship this in Python 3.2. The deadline is only 10-15 days away.

Could you write something able to be in the standard documentation?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Nov 17 19:38:27 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 17 Nov 2010 18:38:27 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290019107.31.0.244447336574.issue10356@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I presume you mean this:
         if self._is_special:
             if self.is_snan():
-                raise TypeError('Cannot hash a signaling NaN value.')
+                raise ValueError('Cannot hash a signaling NaN value.')

My understanding is that while exception messages are not part of the API, the class is, even if not documented. If the decimal spec or doc says the above should be ValueError, then TypeError might be fixable in a bug release. Otherwise, I think I would change it only in 3.2 with a version-changed note in the doc. But Raymond is the decider on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Wed Nov 17 20:14:13 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 17 Nov 2010 19:14:13 +0000
Subject: [issue10447] zipfile: IOError for long directory paths on Windows
In-Reply-To: <1290021253.83.0.149273656602.issue10447@psf.upfronthosting.co.za>
Message-ID: <1290021253.83.0.149273656602.issue10447@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

When extracting a zip file containing deep hierarchy files, `extractall` throws IOError on Windows - perhaps due to limitation in Windows max path length. Ideally it should be throwing an instance of zipfile.ZipError - so that application can handle it reliably. An IOError can mean a wide range of errors, so it is pointless to catch IOError and ignore it.

To reproduce, run extractall over http://pypi.python.org/packages/source/c/collective.generic.skel/collective.generic.skel-0.1.0.zip using Python 2.6.6 or Python 2.7

> python -c "import zipfile
; f=zipfile.ZipFile('collective.generic.skel-0.1.0.zip'); f.extractall()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Python27\lib\zipfile.py", line 923, in extractall
    self.extract(zipinfo, path, pwd)
  File "C:\Python27\lib\zipfile.py", line 911, in extract
    return self._extract_member(member, path, pwd)
  File "C:\Python27\lib\zipfile.py", line 955, in _extract_member
    target = file(targetpath, "wb")
IOError: [Errno 2] No such file or directory: 'C:\\Documents and Settings\\apy\\
My Documents\\Downloads\\collective.generic.skel-0.1.0\\src\\collective\\generic
\\skel\\skin\\tmpl\\+namespace++ndot++nested_namespace+.+project_name+\\src\\+na
mespace+\\+nested_namespace+\\+project_name+\\profiles\\default\\+namespace++ndo
t++nested_namespace+.+project_name+_various.txt_tmpl'

----------
components: Library (Lib), Windows
messages: 121376
nosy: srid
priority: normal
severity: normal
status: open
title: zipfile: IOError for long directory paths on Windows
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10447>
_______________________________________

From report at bugs.python.org  Wed Nov 17 20:16:51 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 17 Nov 2010 19:16:51 +0000
Subject: [issue10447] zipfile: IOError for long directory paths on Windows
In-Reply-To: <1290021253.83.0.149273656602.issue10447@psf.upfronthosting.co.za>
Message-ID: <1290021411.01.0.745718910126.issue10447@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

It appears that there is no base class (zipfile.ZipError) for zipfile errors. Maybe there should be? At the moment, I do:

try:
   [...]
except zipfile.BadZipFile, zipfile.LargeZipFile:
   [...]

.. which is of course unreliable. There is no guarantee that a new exception class will not be added to zipfile (thus necessitating me to change my code). Better to have a single base class - zipfile.ZipError similar to TarError http://docs.python.org/library/tarfile.html#tarfile.TarError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10447>
_______________________________________

From report at bugs.python.org  Wed Nov 17 20:23:11 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Wed, 17 Nov 2010 19:23:11 +0000
Subject: [issue10448] Add Mako template benchmark to Python Benchmark Suite
In-Reply-To: <1290021787.45.0.410966544451.issue10448@psf.upfronthosting.co.za>
Message-ID: <1290021787.45.0.410966544451.issue10448@psf.upfronthosting.co.za>


New submission from Bobby Impollonia <bobbyi at gmail.com>:

The Benchmark Suite currently contains two template benchmarks (Django and Spitfire) for Python 2.x, but none that support 3.x.

The attached patch adds a benchmark using Mako (http://www.makotemplates.org/), a popular, pure-Python, performance-oriented template system that supports both 2.x and 3.x via 2to3 conversion.

Mako is added to the "py3k" benchmark group and a new group called "template" with all three template benchmarks is added (that will only work on 2.x since it uses Django and Spitfire).

I added the Mako benchmark and lib to the lists in the README file and also updated the descriptions of the pickle benchmarks there since I had missed that before. Also fixed a path in there that was referring to perf.py as unladen-benchmarks/perf.py.

----------
assignee: collinwinter
components: Benchmarks
files: mako.patch
keywords: patch
messages: 121378
nosy: bobbyi, collinwinter, pitrou
priority: normal
severity: normal
status: open
title: Add Mako template benchmark to Python Benchmark Suite
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19628/mako.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10448>
_______________________________________

From report at bugs.python.org  Wed Nov 17 20:55:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 19:55:29 +0000
Subject: [issue10448] Add Mako template benchmark to Python Benchmark Suite
In-Reply-To: <1290021787.45.0.410966544451.issue10448@psf.upfronthosting.co.za>
Message-ID: <1290023729.65.0.495184948931.issue10448@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Uh, after translation I get a SystemError when trying to run the Mako bench under the current py3k SVN:

$ PYTHONPATH=lib/mako/ /home/antoine/py3k/py3k/python ./performance/bm_mako.py -n 25
Traceback (most recent call last):
  File "./performance/bm_mako.py", line 26, in <module>
    """)
  File "/home/antoine/py3k/benchmarks/3/lib/mako/mako/template.py", line 183, in __init__
    (code, module) = _compile_text(self, text, filename)
  File "/home/antoine/py3k/benchmarks/3/lib/mako/mako/template.py", line 463, in _compile_text
    strict_undefined=template.strict_undefined)
  File "/home/antoine/py3k/benchmarks/3/lib/mako/mako/codegen.py", line 51, in compile
    node)
  File "/home/antoine/py3k/benchmarks/3/lib/mako/mako/codegen.py", line 98, in __init__
    defs = self.write_toplevel()
  File "/home/antoine/py3k/benchmarks/3/lib/mako/mako/codegen.py", line 196, in write_toplevel
    main_identifiers = module_identifiers.branch(self.node)
  File "/home/antoine/py3k/benchmarks/3/lib/mako/mako/codegen.py", line 866, in branch
    return _Identifiers(node, self, **kwargs)
  File "/home/antoine/py3k/benchmarks/3/lib/mako/mako/codegen.py", line 831, in __init__
    self.topleveldefs = util.SetLikeDict(**parent.topleveldefs)
SystemError: Python/getargs.c:1398: bad argument to internal function

----------
assignee: collinwinter -> 
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10448>
_______________________________________

From report at bugs.python.org  Wed Nov 17 21:29:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 20:29:58 +0000
Subject: [issue10443] add wrapper for SSL_CTX_set_default_verify_paths
In-Reply-To: <1289995488.37.0.849519588112.issue10443@psf.upfronthosting.co.za>
Message-ID: <1290025798.85.0.945602441241.issue10443@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r86498.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10443>
_______________________________________

From report at bugs.python.org  Wed Nov 17 21:41:56 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Wed, 17 Nov 2010 20:41:56 +0000
Subject: [issue10448] Add Mako template benchmark to Python Benchmark Suite
In-Reply-To: <1290021787.45.0.410966544451.issue10448@psf.upfronthosting.co.za>
Message-ID: <1290026516.5.0.309891891811.issue10448@psf.upfronthosting.co.za>


Bobby Impollonia <bobbyi at gmail.com> added the comment:

Did you convert the project using make_perf3.sh? This benchmark is in the 2to3 group and not the 2n3 group because it won't work without conversion.

Using the attached patch, the following sequence of commands works for me to run the benchmark with python 3.1:

hg clone http://hg.python.org/benchmarks/ py2benchmarks
cd py2benchmarks/
hg import mako.patch 
mkdir ../py3benchmarks
cd ../py3benchmarks
../py2benchmarks/make_perf3.sh ../py2benchmarks
python3.1 perf.py -f -b mako python3.1 python3.1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10448>
_______________________________________

From report at bugs.python.org  Wed Nov 17 21:42:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 20:42:11 +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: <1290026531.56.0.872357235461.issue9518@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This looks ok to me.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9518>
_______________________________________

From report at bugs.python.org  Wed Nov 17 21:43:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 20:43:11 +0000
Subject: [issue10448] Add Mako template benchmark to Python Benchmark Suite
In-Reply-To: <1290026516.5.0.309891891811.issue10448@psf.upfronthosting.co.za>
Message-ID: <1290026582.3772.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Did you convert the project using make_perf3.sh?

Yes. But given the error (SystemError) I guess this is a regression in
py3k. I'll apply your patch and open a separate issue to try and make
sense of the regression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10448>
_______________________________________

From report at bugs.python.org  Wed Nov 17 22:03:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Nov 2010 21:03:44 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290027824.23.0.191630959975.issue10446@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 to Georg.  Note that there are people that feel uncomfortable with calling packages modules, but not me.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Wed Nov 17 22:20:43 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 17 Nov 2010 21:20:43 +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: <1290028843.06.0.88337699711.issue9518@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Fix committed to py3k as r86499

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9518>
_______________________________________

From report at bugs.python.org  Wed Nov 17 23:20:14 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 17 Nov 2010 22:20:14 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1290032414.97.0.560643505576.issue10435@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Thanks for your work on this.

Please see my comments below:

--- Include/unicodeobject.h	(revision 86478)
+++ Include/unicodeobject.h	(working copy)
@@ -737,7 +737,7 @@
     const char *errors          /* error handling */
     );
 
-/* Encodes a Unicode object and returns the result as Python string
+/* Encodes a Unicode object and returns the result as Python bytes
    object. */
 

PyUnicode_AsEncodedObject() encodes the Unicode object to
whatever the codec returns, so the "bytes" is wrong in the
above line.


--- Doc/c-api/unicode.rst	(revision 86477)
+++ Doc/c-api/unicode.rst	(working copy)
@@ -528,7 +567,22 @@
    using the Python codec registry.  Return *NULL* if an exception was raised by
    the codec.
 
+.. c:function:: PyObject* PyUnicode_AsDecodedObject(PyObject *unicode, const char *encoding, const char *errors)
 
+   Create a Unicode object by decoding the encoded Unicode object
+   *unicode*.

The function does not guarantee that a Unicode object will be
returned. It merely passes a Unicode object to a codec's
decode function and returns whatever the codec returns.

+   *encoding* and *errors* have the same meaning as the
+   parameters of the same name in the :func:`unicode` built-in
+   function.  The codec to be used is looked up using the Python codec
+   registry.  Return *NULL* if an exception was raised by the codec.
+   Note that Python codecs do not accept Unicode objects for decoding,
+   so this method is only useful with user or 3rd party codecs.

Please strike the last sentence. The codecs that were wrongly removed
from Python3 will get added back and provide such functionality.

+.. c:function:: PyObject* PyUnicode_AsEncodedObject(PyObject *unicode, const char *encoding, const char *errors)
+
+   Use c:func:`PyUnicode_AsEncodedString` instead.

That's not a useful hint as PyUnicode_AsEncodedString() does something
different than PyUnicode_AsEncodedObject().

+   Same as c:func:`PyUnicode_AsEncodedString`, but without shortcuts
+   for common built-in encodings and without checking the type of the
+   object returned by encoding via the codec registry.  This method is
+   only useful with user or 3rd party codec that encodes string into
+   something other than bytes.

This should read:

   Decodes a Unicode object by passing the given Unicode object
   *unicode* to the codec for *encoding*.
   *encoding* and *errors* have the same meaning as the
   parameters of the same name in the :func:`unicode` built-in
   function.  The codec to be used is looked up using the Python codec
   registry.  Return *NULL* if an exception was raised by the codec.

+.. c:function:: PyObject* PyUnicode_AsEncodedUnicode(PyObject *unicode, const char *encoding, const char *errors)
+   
+   Use c:func:`PyUnicode_AsEncodedString` instead.

Please remove this as well.

+   Same as c:func:`PyUnicode_AsEncodedObject`, but raises
+   :exc:`TypeError` is encoding via the codec registry returns an
+   object other than string.  This method is only useful with user or
+   3rd party codec that encodes string into string.

Please remove the last sentence.

+.. c:function: int PyUnicode_EncodeDecimal(Py_UNICODE *s, Py_ssize_t length,
+                                           char *output,  const char *errors)
+
+   Takes a Unicode string holding a decimal value and writes it into
+   an output buffer using standard ASCII digit codes.
+
+   The output buffer has to provide at least length+1 bytes of storage
+   area. The output string is 0-terminated.
+
+   The encoder converts whitespace to ' ', decimal characters to their
+   corresponding ASCII digit and all other Latin-1 characters except
+   \0 as-is. Characters outside this range (Unicode ordinals 1-256)
+   are treated as errors. This includes embedded NULL bytes.
+
+   Error handling is defined by the errors argument:
+
+      NULL or "strict": raise a ValueError
+      "ignore": ignore the wrong characters (these are not copied to the
+                output buffer)
+      "replace": replaces illegal characters with '?'
+
+   Returns 0 on success, -1 on failure.
+   

+.. c:function:: void PyUnicode_Append(PyObject **pleft, PyObject *right)
+
+   Concat two strings and put the result in *pleft. Sets *pleft to
+   NULL on error.
+
+.. c:function:: void PyUnicode_AppendAndDel(PyObject **pleft, PyObject *right)
+
+   Concat two strings and put the result in *pleft and drop the right
+   object. Sets *pleft to NULL on error.
+
+

Please don't document these two obscure APIs. Instead we should
make them private functions by prepending them with an underscore.
If you look at the implementations of those two APIs, they
are little more than a macros around PyUnicode_Concat().

3rd party extensions should use PyUnicode_Concat() to achieve
the same effect.


+.. c:function:: void PyUnicode_InternImmortal(PyObject **string)
+ 
+   Use :c:func:`PyUnicode_InternInPlace` instead.
+
+   Same as :c:func:`PyUnicode_InternInPlace`, but the interned string
+   will never be released.
+

I don't think it's a good idea to make this a public API.
3rd party extensions should not need to make use of such
APIs.

Instead, we should make this a private API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Wed Nov 17 23:31:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Nov 2010 22:31:24 +0000
Subject: [issue5831] Doc mistake : threading.Timer is *not* a class
In-Reply-To: <1240580557.82.0.551397939271.issue5831@psf.upfronthosting.co.za>
Message-ID: <1290033084.59.0.794634601251.issue5831@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nearly all classes in threading uses this function/class indirection, which I don?t understand (except for RLock, which is a factory function).

----------
assignee: docs at python -> 
nosy: +eric.araujo
versions: +Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5831>
_______________________________________

From report at bugs.python.org  Wed Nov 17 23:40:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Nov 2010 22:40:07 +0000
Subject: [issue9173] logger statement not guarded in shutil._make_tarball
In-Reply-To: <1278374700.0.0.888108186461.issue9173@psf.upfronthosting.co.za>
Message-ID: <1290033607.36.0.0992334443295.issue9173@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good.

By the way, the logger argument is not documented in shutil.rst.

----------
nosy: +eric.araujo
stage:  -> patch review
versions:  -Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9173>
_______________________________________

From report at bugs.python.org  Wed Nov 17 23:41:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Nov 2010 22:41:57 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	relative dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1290033717.78.0.415166758225.issue7325@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Wed Nov 17 23:42:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Nov 2010 22:42:29 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	relative dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1290033749.46.0.968768538542.issue7325@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Wed Nov 17 23:47:06 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 17 Nov 2010 22:47:06 +0000
Subject: [issue10447] zipfile: IOError for long directory paths on Windows
In-Reply-To: <1290021253.83.0.149273656602.issue10447@psf.upfronthosting.co.za>
Message-ID: <1290034026.71.0.259147765905.issue10447@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

How would you implement this? And would you turn a "disk full" error, for example, into a ZipError as well?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10447>
_______________________________________

From report at bugs.python.org  Wed Nov 17 23:48:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Nov 2010 22:48:57 +0000
Subject: [issue10447] zipfile: IOError for long directory paths on Windows
In-Reply-To: <1290021253.83.0.149273656602.issue10447@psf.upfronthosting.co.za>
Message-ID: <1290034137.64.0.521138753558.issue10447@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10447>
_______________________________________

From report at bugs.python.org  Wed Nov 17 23:56:44 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Wed, 17 Nov 2010 22:56:44 +0000
Subject: [issue10447] zipfile: IOError for long directory paths on Windows
In-Reply-To: <1290021253.83.0.149273656602.issue10447@psf.upfronthosting.co.za>
Message-ID: <1290034604.73.0.727072569706.issue10447@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

> How would you implement this? And would you turn a "disk full" error, for example, into a ZipError as well?

I see your point. I am not sure what a reliable way to do this would be. For the record, this is how I workaround it:
https://github.com/ActiveState/applib/blob/master/applib/_compression.py#L78
(I cannot find any other reason for an IOError/errno=2 during extraction)

And I, personally, wouldn't turn the disk full error into a ZipError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10447>
_______________________________________

From report at bugs.python.org  Thu Nov 18 00:00:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 23:00:14 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290034814.55.0.0407984399823.issue10446@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The attached patch, issue10446.diff, makes help(sys) look as follows:


NAME
    sys

MODULE REFERENCE
    http://docs.python.org/release/3.2/library/sys
    
    The following documentation is automatically generated from the Python source
    files.  It may be incomplete, incorrect or include features that are considered
    implementation detail and may vary between Python implementations.  When in
    doubt, consult the module reference at the location listed above.

DESCRIPTION
    This module provides access to some objects used or maintained by the
    interpreter and to functions that interact strongly with the interpreter.  
..

Georg, I noticed that there is no http://docs.python.org/release/3.2 link yet, but I don't want to complicate the URL generation logic unnecessarily to accommodate pre-release versions. If you can suggest some simple test for pointing to 'dev' instead of 'release/X.Y', I'll add it, but I don't see it as a priority.

If you test the patch from the source tree, please note that pydoc has some strange logic that excludes uninstalled modules except ones in a hardcoded list.  This should be changed at some point.

----------
keywords: +patch
Added file: http://bugs.python.org/file19629/issue10446.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 00:00:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 23:00:30 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290034830.53.0.970555953025.issue10446@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 00:41:13 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 17 Nov 2010 23:41:13 +0000
Subject: [issue10447] zipfile: IOError for long directory paths on Windows
In-Reply-To: <1290021253.83.0.149273656602.issue10447@psf.upfronthosting.co.za>
Message-ID: <1290037273.18.0.0819707930817.issue10447@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think you did the right thing already.  The choice of which errors to catch and which ones to let throw really depends on the usage
(what about permission or lock errors? other limitations due to a USB stick? why is "disk full" different? and so on)

It's not the Zip module which raises the error here. It's the OS, that's why IMO it should not be a ZipError.

----------
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10447>
_______________________________________

From report at bugs.python.org  Thu Nov 18 00:41:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 17 Nov 2010 23:41:52 +0000
Subject: =?utf-8?q?=5Bissue10449=5D_=E2=80=9Cos=2Eenviron_was_modified_by_test=5Fh?=
	=?utf-8?q?ttpservers=E2=80=9D?=
In-Reply-To: <1290037312.36.0.429543986762.issue10449@psf.upfronthosting.co.za>
Message-ID: <1290037312.36.0.429543986762.issue10449@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Bug title is a warning I get when running test_httpservers under regrtest with 3.1.

----------
components: Tests
messages: 121393
nosy: eric.araujo, orsenthil
priority: low
severity: normal
stage: needs patch
status: open
title: ?os.environ was modified by test_httpservers?
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10449>
_______________________________________

From report at bugs.python.org  Thu Nov 18 00:52:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 17 Nov 2010 23:52:02 +0000
Subject: [issue10384] SyntaxError should contain exact location of the invalid
	character in identifier
In-Reply-To: <1289439285.11.0.506002899946.issue10384@psf.upfronthosting.co.za>
Message-ID: <1290037922.82.0.235659604738.issue10384@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10384>
_______________________________________

From report at bugs.python.org  Thu Nov 18 00:53:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 23:53:38 +0000
Subject: [issue7828] chr() and ord() documentation for wide characters
In-Reply-To: <1264999918.27.0.407460194608.issue7828@psf.upfronthosting.co.za>
Message-ID: <1290038018.52.0.802017965769.issue7828@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee: docs at python -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7828>
_______________________________________

From report at bugs.python.org  Thu Nov 18 00:54:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 17 Nov 2010 23:54:56 +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: <1290038096.36.0.382198998146.issue9738@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/issue9738>
_______________________________________

From report at bugs.python.org  Thu Nov 18 01:28:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 00:28:03 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290040083.28.0.103275818691.issue10446@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.  Some remarks:

1) I assume you have checked that this code does not produce two newlines (one in the string, one from the print function or write method):
+[snip], consult the module reference at the location listed above.
+""")

2) ?If you can suggest some simple test for pointing to 'dev' instead of 'release/X.Y'? ? sys.version_info[3] != 'final'

3) People seem to go the the most recent version of the docs, not the release-specific version (I haven?t found the python-dev thread about that, maybe you remember it).  The version{add,chang}ed directives help adjust the doc for older versions.  So, are you sure it?s useful to make the links release-specific?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 01:35:51 2010
From: report at bugs.python.org (Ron Adam)
Date: Thu, 18 Nov 2010 00:35:51 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290040551.1.0.783776785851.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

I just noticed I used "depreciated" in place of "deprecated" in one of the doc strings.  I can upload a new patch with that fixed.

Before I do that, is there any thing else I can do?

Do you agree that the browse function should be public?  
If not, what do we tell people to use instead of gui(), sense that will be deprecated?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Thu Nov 18 01:36:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 00:36:24 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1290040584.52.0.269807461094.issue2775@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords:  -easy
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Thu Nov 18 01:42:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 00:42:04 +0000
Subject: [issue5717] os.defpath includes unix /bin on windows
In-Reply-To: <1239116630.78.0.64068842306.issue5717@psf.upfronthosting.co.za>
Message-ID: <1290040924.36.0.694961116407.issue5717@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adding our esteemed Windows experts for review.

----------
components: +Windows
nosy: +brian.curtin, eric.araujo, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5717>
_______________________________________

From report at bugs.python.org  Thu Nov 18 01:55:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 00:55:56 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1290041756.24.0.143311028959.issue4010@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The reversed call was added by Brett in r60537.  Brett, can you comment?

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Thu Nov 18 01:57:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 00:57:25 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1290041845.62.0.851231648124.issue4010@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/issue4010>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:00:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:00:24 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1290042024.33.0.255648265654.issue444582@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello Jan.  Can you give us a status update on this one?

Iztok: There is a lot of code out there, written in anything from Python to awk to shell, that splits on ?:?.  Perhaps it?s okay to just not support ?:? in directory names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:01:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 01:01:10 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290040083.28.0.103275818691.issue10446@psf.upfronthosting.co.za>
Message-ID: <AANLkTikMxJm3LrEUtqHLEEq3WU8yLSLdKa=T4CBeThfV@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Nov 17, 2010 at 7:28 PM, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Looks good. ?Some remarks:
>
> 1) I assume you have checked that this code does not produce two newlines (one in the string,
> one from the print function or write method):

Yes, it should be clear from the output that I presented above.  I
think TextDoc.indent() takes care of the trailing '\n'.

That won't work for maintenance branches. (I am not even sure docs are
built for maintenance branches.)

> 3) People seem to go the the most recent version of the docs, not the release-specific version
> (I haven?t found the python-dev thread about that, maybe you remember it).
> ?The version{add,chang}ed directives help adjust the doc for older versions.
> ?So, are you sure it?s useful to make the links release-specific?

Certainly. If we are talking about the most authoritative source.  I
don't think versionadded/changed tags are reliable enough and you
don't want to send users to wrong docs when APIs change between
releases.   I am not so sure about micro-version, but there is no easy
way to construct the latest micro-version link without changes on
python.org.  If there was say latest/X.Y, I would use that.  Wait -
there is: docs.python.org/X.Y.  Would you prefer that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:04:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:04:51 +0000
Subject: [issue1509798] replace dist/src/Tools/scripts/which.py with tmick's
	which
Message-ID: <1290042291.39.0.617818429898.issue1509798@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think Tools/scripts/which.py is obsoleted by the upcoming shutil.which function.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
status: open -> closed
superseder:  -> Finding programs in PATH, adding shutil.which

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1509798>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:15:44 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Nov 2010 01:15:44 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1290042944.43.0.38889931619.issue4010@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

When I did the patch they were coming in reversed, so I reversed the reversal. Obviously something changed so now the manual reversal is not necessary anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:18:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:18:08 +0000
Subject: [issue8384] Better error message for executables not found
In-Reply-To: <1271121338.06.0.379239271673.issue8384@psf.upfronthosting.co.za>
Message-ID: <1290043088.78.0.651756062494.issue8384@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Anatoly: Please open a feature request for distutils2.  Thanks in advance.

Craig: This seems to have fallen out of the radar, sorry.  Someone may propose a patch during the upcoming bug week-end, or we?ll do it.

----------
nosy: +eric.araujo
title: Distutils C extension build with MinGW on Windows fails -> Better error message for executables not found
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8384>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:19:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:19:34 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1222879433.22.0.765704464081.issue4010@psf.upfronthosting.co.za>
Message-ID: <1290043174.08.0.699633947607.issue4010@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t think there can be a unit test for that, so do we agree on just removing the reversed call?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:25:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:25:28 +0000
Subject: [issue1109602] Need some setup.py sanity
Message-ID: <1290043528.74.0.716417880448.issue1109602@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The bug reported by Skip looks like something to be done with ./configure.  When this is solved, I think this bug with its original title should be kept open.  Let?s refactor setup.py into something manageable and testable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1109602>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:31:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:31:53 +0000
Subject: [issue10374] setup.py caches outdated scripts in the build tree
In-Reply-To: <1289308289.62.0.579780588392.issue10374@psf.upfronthosting.co.za>
Message-ID: <1290043913.6.0.901340011966.issue10374@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For this particular bug, we could add a check for the shebang line in distutils1? build_scripts, so that a second run can detect it should rebuild the scripts even though the source has not changed.  Or is there a rule that says build_* command only look at timetamps to decide that?

I agree about the larger problem that cannot be solved entirely and nicely in distutils2.

----------
versions: +3rd party -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10374>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:37:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:37:08 +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: <1290044228.95.0.689184241172.issue6731@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(Side note: Specifying optional/required extensions from the command line may be an interesting new feature in distutils2.)

----------
nosy: +eric.araujo
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6731>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:41:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:41:54 +0000
Subject: [issue1479255] Fix building with SWIG's -c++ option set in setup.py
Message-ID: <1290044514.5.0.0735047061087.issue1479255@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We need to add a test for this behavior, to make sure it is fixed and to prevent regressions.

----------
components: +Distutils2
nosy: +eric.araujo
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1479255>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:46:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:46:34 +0000
Subject: [issue4655] during Python installation,
	setup.py should not use .pydistutils.cfg
In-Reply-To: <1229218265.16.0.0523897864618.issue4655@psf.upfronthosting.co.za>
Message-ID: <1290044794.67.0.435867403465.issue4655@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Not reading .pydistutils.cfg during CPython?s build seems a good idea to me.  I would like confirming opinions.

----------
components: +Build
nosy: +barry, eric.araujo, loewis
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4655>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:49:21 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Nov 2010 01:49:21 +0000
Subject: [issue4010] configure options don't trickle down to distutils
In-Reply-To: <1290043174.08.0.699633947607.issue4010@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=tGu9=V5N9sBFWPH9ZXiEfe92POd_BtC0ha99H@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Wed, Nov 17, 2010 at 17:19, ?ric Araujo <report at bugs.python.org> wrote:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> I don?t think there can be a unit test for that, so do we agree on just removing the reversed call?

As long as the person removing it verifies it and keeps an eye on the
buildbots, sure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4010>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:51:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:51:08 +0000
Subject: [issue7202] "python setup.py cmd --verbose" does not set verbosity
In-Reply-To: <1256481428.97.0.691214379627.issue7202@psf.upfronthosting.co.za>
Message-ID: <1290045068.92.0.355695719178.issue7202@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils2
keywords: +easy
resolution: accepted -> 
title: "python setup.py MYCOMMAND --verbose" does not yield an unrecognized option error but also does not set the verbosity -> "python setup.py cmd --verbose" does not set verbosity
type:  -> behavior
versions: +3rd party, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7202>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:52:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:52:51 +0000
Subject: [issue6166] encoding error for 'setup.py --author' when read via
	subprocess pipe
In-Reply-To: <1243881147.82.0.337721955444.issue6166@psf.upfronthosting.co.za>
Message-ID: <1290045171.55.0.517238370718.issue6166@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sridhar, can you test with the envvar PYTHONIOENCODING set to UTF-8?

----------
nosy: +eric.araujo
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6166>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:54:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:54:21 +0000
Subject: [issue8406] Make some setup.py paths exclude-able
In-Reply-To: <1271301152.77.0.297402624492.issue8406@psf.upfronthosting.co.za>
Message-ID: <1290045261.43.0.0614076661214.issue8406@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8406>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:55:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:55:30 +0000
Subject: [issue7713] implement ability to disable automatic search path
	additions
In-Reply-To: <1263654090.34.0.366231914993.issue7713@psf.upfronthosting.co.za>
Message-ID: <1290045330.49.0.520649708958.issue7713@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
stage: unit test needed -> needs patch
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7713>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:56:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:56:56 +0000
Subject: [issue7677] improve error message for setup.py upload --sign without
	--identity
In-Reply-To: <1263223354.89.0.290474495181.issue7677@psf.upfronthosting.co.za>
Message-ID: <1290045416.59.0.970435208827.issue7677@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils2
keywords: +easy
title: distutils, better error message for setup.py upload -sign without identity. -> improve error message for setup.py upload --sign without --identity
versions: +3rd party -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7677>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:58:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 01:58:46 +0000
Subject: [issue6138] './configure;
	make install' fails in setup.py step if .pydistutils.cfg specifies
	'home'
In-Reply-To: <1243544515.37.0.19833579137.issue6138@psf.upfronthosting.co.za>
Message-ID: <1290045526.17.0.904544275667.issue6138@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

See #4655.  (Not sure which one is the superseder.)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6138>
_______________________________________

From report at bugs.python.org  Thu Nov 18 02:59:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 01:59:14 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290045554.69.0.604166898808.issue10446@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r86504 (3.2) and r86504 (3.1).

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:02:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:02:29 +0000
Subject: [issue5033] setup.py crashes if sqlite version contains 'beta'
In-Reply-To: <1232641406.0.0.500689225697.issue5033@psf.upfronthosting.co.za>
Message-ID: <1290045749.23.0.143489759791.issue5033@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The regex is still the same.  I?ll try changing the version string in sqlite and trigger the bug.

----------
assignee: ghaering -> 
nosy: +eric.araujo, tarek
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5033>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:08:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 02:08:03 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290046083.63.0.441066550024.issue10446@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

s/r86504 (3.1)/r86505 (3.1)/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:08:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:08:51 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1290046131.26.0.599149290413.issue8754@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A question about process: Should every import bug be reported against core and library, so that importlib gets patched too?

----------
nosy: +eric.araujo
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:09:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 02:09:06 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290046146.6.0.142815261927.issue10446@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r86504 (3.2) and r86505 (3.1).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:09:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 02:09:13 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290046153.15.0.714434939122.issue10446@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg121414

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:09:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 02:09:14 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290046154.25.0.349294134636.issue10446@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg121412

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:12:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:12:53 +0000
Subject: [issue4113] Add custom __repr__ to functools.partial
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1290046373.53.0.628644785703.issue4113@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

One function in inspect can do everything we want, only not in C.  How hard/inefficient would it be to have 99% of partial coded in C and one stub in functools.py?

----------
nosy: +eric.araujo, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4113>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:14:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:14:28 +0000
Subject: [issue834840] Unhelpful error message from cgi module
Message-ID: <1290046468.86.0.159984014133.issue834840@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/issue834840>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:15:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 02:15:25 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290046525.01.0.672464508099.issue2001@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Ron,

I added a header to the text documentation clarifying that pydoc-generated documentation is not authoritative. See issue 10446.  I did add it to the HTML page because it was not obvious where to put it and I knew that you are changing layout anyways.  Please consider including the same text somewhere in HTML pages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:16:32 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Nov 2010 02:16:32 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1290046592.34.0.830029628138.issue8754@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I think everyone knows that importlib is there and might need to be patched. Plus I run importlib against the entire test suite already on occasion so changes which has a proper test will eventually get caught.

So just file it against core.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:18:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:18:33 +0000
Subject: [issue832159] Bad value for Mingw32Compiler.compiler_cxx
Message-ID: <1290046713.09.0.913874758447.issue832159@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The suggestion in the first message has to be turned into a patch.  A test has to be written too.

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +eric.araujo
title: C++ extensions using SWIG and MinGW -> Bad value for Mingw32Compiler.compiler_cxx
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue832159>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:21:00 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 18 Nov 2010 02:21:00 +0000
Subject: [issue8886] zipfile.ZipExtFile is a context manager,
	but that is not documented
In-Reply-To: <1275565167.77.0.94387257463.issue8886@psf.upfronthosting.co.za>
Message-ID: <1290046860.83.0.0892427840477.issue8886@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in r86506 for py3k. The maintenance branches recently had an RC in preparation for a release -- I'll backport once they go out.

----------
assignee:  -> brian.curtin
nosy: +brian.curtin
resolution:  -> accepted
type: feature request -> resource usage
versions: +Python 3.1, Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8886>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:22:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:22:24 +0000
Subject: [issue1353344] python.desktop
Message-ID: <1290046944.63.0.274139241617.issue1353344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Don?t we expect beginners to start IDLE from their menu, and middle to advanced users to type ?python? in their terminal?  +0.

IDLE does have a .desktop file in my Debian, so +1 on integrating that in our source tree.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1353344>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:24:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 02:24:38 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290047078.19.0.96743866471.issue10446@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Reopening to consider changing just the link (not other changes) in 2.7.  At some point http://docs.python.org/library will point to 3.x and we get a bug in 2.7.

----------
status: closed -> open
versions: +Python 2.7 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:26:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:26:19 +0000
Subject: [issue1599329] urllib(2) should allow automatic decoding by charset
Message-ID: <1290047179.33.0.707473817004.issue1599329@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies:  -Add a "decode to declared encoding" version of urlopen to urllib
nosy: +eric.araujo
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
status: open -> closed
superseder:  -> Add a "decode to declared encoding" version of urlopen to urllib
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1599329>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:30:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:30:32 +0000
Subject: [issue444582] Finding programs in PATH, adding shutil.which
Message-ID: <1290047432.1.0.110408438217.issue444582@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adding people from the duplicate bug to nosy.

Alternate implementation, which looks more thorough: http://code.google.com/p/which/ (from Trent Mick, added to nosy, who?s already agreed to contribute his code).

----------
dependencies:  -replace dist/src/Tools/scripts/which.py with tmick's which
nosy: +loewis, schmir, tmick, wrstlprmpft

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue444582>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:33:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:33:12 +0000
Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to
	urllib
In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za>
Message-ID: <1290047592.12.0.529873508475.issue4733@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the patch should be updated to benefit from new facilities in the io module instead of monkey-patching methods. The doc and tests are still good.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4733>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:33:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:33:31 +0000
Subject: [issue4733] Add a "decode to declared encoding" version of urlopen to
	urllib
In-Reply-To: <1230068654.82.0.881542673607.issue4733@psf.upfronthosting.co.za>
Message-ID: <1290047611.23.0.806752984811.issue4733@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies:  -urllib(2) should allow automatic decoding by charset

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4733>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:40:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:40:46 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1290048046.65.0.345494018645.issue8754@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the reply.

Funny thing, grep revealed a small inconsistency in this error message:

Python/pythonrun.c:415:     * XXX     Exception exceptions.ImportError: 'No module named sha'
Python/import.c:1821:                     "No module named %.200s", name);
Python/import.c:2722:                     "No module named %.200s", name);
Lib/test/test_multiprocessing.py:27:# message: "No module named _multiprocessing". _multiprocessing is not compiled
Lib/test/test_concurrent_futures.py:8:# message: "No module named _multiprocessing". _multiprocessing is not compiled
Lib/test/test_pydoc.py:194:badimport_pattern = "problem in %s - ImportError: No module named %s"
Lib/runpy.py:104:        raise ImportError("No module named %s" % mod_name)
Lib/xml/etree/ElementTree.py:1492:                    "No module named expat; use SimpleXMLTreeBuilder instead"
Lib/modulefinder.py:189:        self.msgout(4, "raise ImportError: No module named", qname)
Lib/modulefinder.py:190:        raise ImportError("No module named " + qname)
Lib/modulefinder.py:202:                self.msgout(4, "raise ImportError: No module named", mname)
Lib/modulefinder.py:203:                raise ImportError("No module named " + mname)
Lib/modulefinder.py:219:                    raise ImportError("No module named " + subname)
Lib/importlib/_bootstrap.py:811:                raise ImportError("no module named {}; "
Lib/importlib/_bootstrap.py:820:            raise ImportError("No module named {0}".format(name))
Lib/unittest/test/test_loader.py:242:            self.assertEqual(str(e), "No module named sdasfasfasdf")
Lib/unittest/test/test_loader.py:622:            self.assertEqual(str(e), "No module named sdasfasfasdf")

Fixing the Python modules is easy, but I don?t know how to change PyErr_Format (or how to write C, for that matter :)  Do you make offers like Alexandre, who has proposed to write the C part if someone provides a diff for the Python version?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:42:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:42: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: <1290048136.26.0.697446652013.issue8754@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I should have included only the one line that?s different:
Lib/importlib/_bootstrap.py:811:                raise ImportError("no
(lower-case n)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:51:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 02:51:15 +0000
Subject: [issue10450] Fix markup in Misc/NEWS
In-Reply-To: <1290048675.36.0.613944727318.issue10450@psf.upfronthosting.co.za>
Message-ID: <1290048675.36.0.613944727318.issue10450@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

Misc/NEWS is supposed to be in reST, but there are at present markup errors.  Not sure if 3.1 and 2.7 should be fixed too.

----------
keywords: easy
messages: 121428
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix markup in Misc/NEWS
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10450>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:56:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 18 Nov 2010 02:56:28 +0000
Subject: [issue1353344] python.desktop
Message-ID: <1290048988.0.0.702009472632.issue1353344@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am past beginner stage and I still open with the Start mene ;-)
If/when I install Ubuntu or other Linux, I would like to still be able to do whatever is the equivalent, as with other stuff, rather than have to open a command window and type a command.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1353344>
_______________________________________

From report at bugs.python.org  Thu Nov 18 03:56:28 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 18 Nov 2010 02:56:28 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1290048988.65.0.666028201805.issue8754@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

PyErr_Format doesn't need to change, just it's argument. A call to PyObject_Repr() (w/ proper error checking) should be all that is needed.

And no, I don't make any "you do the Python, I'll do the C" deals because the Python part is the fun part. =)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Thu Nov 18 04:09:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 03:09:20 +0000
Subject: [issue1353344] python.desktop
Message-ID: <1290049760.71.0.966323989567.issue1353344@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let me change my +0 to a +1 then :)

For reference, the file used in Debuntu for Pythonx.y.desktop: http://bazaar.launchpad.net/~doko/python/pkg3.1-debian/annotate/head%3A/PVER.desktop.in
idle.desktop: http://bazaar.launchpad.net/~doko/python/pkg3.1-debian/annotate/head%3A/idle.desktop.in

License unclear, author apparently doko, so I guess we?re good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1353344>
_______________________________________

From report at bugs.python.org  Thu Nov 18 04:13:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 03:13:51 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1290050031.67.0.761960068573.issue8754@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> A call to PyObject_Repr() (w/ proper error checking) should be all
> that is needed.
Sadly out of reach for me.

> And no, I don't make any "you do the Python, I'll do the C" deals
> because the Python part is the fun part. =)
I understand :)

FTR, case inconsistency fixed by Brett in r86507.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8754>
_______________________________________

From report at bugs.python.org  Thu Nov 18 04:25:27 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Thu, 18 Nov 2010 03:25:27 +0000
Subject: [issue10448] Add Mako template benchmark to Python Benchmark Suite
In-Reply-To: <1290021787.45.0.410966544451.issue10448@psf.upfronthosting.co.za>
Message-ID: <1290050727.57.0.670374096069.issue10448@psf.upfronthosting.co.za>


Bobby Impollonia <bobbyi at gmail.com> added the comment:

It's working okay for me using a python binary that I just built off the the py3k branch on 64-bit linux.

FWIW, in the crashing line
util.SetLikeDict(**parent.topleveldefs)
, util.SetLikeDict is a subclass of dict defined in python that just adds an extra method (union) and parent.topleveldefs is an instance of the same class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10448>
_______________________________________

From report at bugs.python.org  Thu Nov 18 04:32:18 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 18 Nov 2010 03:32:18 +0000
Subject: [issue9173] logger statement not guarded in shutil._make_tarball
In-Reply-To: <1278374700.0.0.888108186461.issue9173@psf.upfronthosting.co.za>
Message-ID: <1290051138.13.0.658725718135.issue9173@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

> By the way, the logger argument is not documented in shutil.rst.

This documentation issue is distinct from this; this bug affects applications that *don't* use the logger argument.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9173>
_______________________________________

From report at bugs.python.org  Thu Nov 18 05:04:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 04:04:31 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290053071.99.0.624073176454.issue2001@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Review time!  Please use rietveld for big patches in the future.

I had started with a list of remarks in same order than the code and minor remarks grouped at the end, but I see now that all my remarks are minor, since I have found no real code problem (I don?t know pydoc as well as you :)  If my message is hard to follow, I?ll redo it on rietveld or directly update your patch (I?m nitpicky, so I can volunteer to share the work).  Thanks for your continued effort and high-quality result!

* Misc/NEWS: Your entry has to be proper reST.

* pydoc.rst:
+documentation pages.  (The :option:`-g` option is depreciated.)
:option: marks an option for python itself.  Use ```` instead.  See #9312 for more info.  (Also fix the typo, which appears twice in the diff.)

+:program:`pydoc` ``-b``
:program:`pydoc -b` works.

?Each served page has a navigation bar at the top where you can 'get' help on an individual item, 'search' all modules with a keyword in their synopsis line, and goto indexes for 'modules', 'topics' and 'keywords'.?
What do the apostrophes mean?

* urllib/parse.py, test_urlparse.py: Unrelated changes?

* pydoc.py
+import sys, imp, os, re, inspect, builtins, pkgutil, time, warnings
Why not take the opportunity to put each import on its own line, for source and diff readability?

+            return 'no documentation found for %s' % repr(topic), ''
You can simplify that to ?'... %r' % topic?.  (I?m assuming topic is never a tuple.)

+        if type(target) is type(''):
I see you?re following the style of the rest of the file.  Modernizing that to isinstance is probably out of scope for this patch.  (Have I said that the HTML is horrible too?)

+    msg = """The pydoc.serve() function is deprecated."""
Such messages usually don?t start with a capital nor end with a period.

+    msg = """The pydoc.gui() function and "pydoc -g" option are depreciated,
+    use "pydoc.browse() function and "pydoc -b" option instead."""
Won?t this have strange leading indentation on the second line?  I?d recommend printing two lines that wrap under 80 characters:

    msg = ('the pydoc.gui() function and "pydoc -g" option are deprecated,'
           'use pydoc.browse() and "pydoc -b" instead')


+            #...    webbrowser.open(serverthread.url)
+            #True
I don?t like commented-out example code.  I prefer it to work or not be there :)

?it's? is not a possessive, you want ?its?.

+    import http.server
Aren?t function-level imports frowned upon?

+            if self.path.endswith('.css'):
+                content_type = 'text/css'
+            else:
+                content_type = 'text/html'
It?s good practice to add the ?charset??parameter to specify the character encoding.

+        if url[-5:] == '.html': url = url[:-5]
Please always put two statements on two lines.

+            except IOError as value:
You don?t need to get the instance if you don?t use it in the following block (IOW, remove ? as value?).

+            fp.close()
Please use the with statement.

+        server_help_msg = """Python Version: %s
?version? need not be capitalized IMO.

-""" % (cmd, os.sep, cmd, cmd, cmd, cmd, os.sep))
+""" % (cmd, os.sep, cmd, cmd, cmd, cmd, cmd, os.sep))
Feel free to replace all those %s by %(cmd)s or {cmd} for readability.


* Assorted nitpicks, which are not blocking:
- ?command line? needs an hyphen when used as an adjective (in whatsnew/3.2.rst)
- a?an in ?a HTTP server? (pydoc.py)
- Use two spaces: ?local machine. Port? (twice); ?page. Use?.
- ?To determine what the client is asking for check the URL?: I?d add a comma after ?for?.
- You can remove the parentheses around ?The "-g" option is deprecated? and put it on the preceding line.
- Feel free to sprinkle a few more blanklines here and there, especially before class and function definition.

> Do you agree that the browse function should be public?
I?ll leave that to Nick.

----------
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Thu Nov 18 05:05:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 04:05:25 +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: <1290053125.98.0.075323448456.issue9312@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: pending -> open
Removed message: http://bugs.python.org/msg121259

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Thu Nov 18 05:05:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 04:05:37 +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: <1290053137.36.0.0619282478829.issue9312@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Thu Nov 18 05:21:20 2010
From: report at bugs.python.org (Ron Adam)
Date: Thu, 18 Nov 2010 04:21:20 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290054080.09.0.453976305121.issue10446@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

I noticed in your patch, the disclaimer only prints when pydoc can find a doc location (docloc is not None).  So it may not get displayed at all depending on how python is installed.  I also think having it on every page may be a bit overly cautious. (IMHO)

I'm also not sure it is correct to have that when viewing third party modules as the doc location in those cases will be broken anyway.

The obvious places to put it are:
   * top of the pydoc html module index.  (first page displayed)
   * in the welcome message for interactive help()
   * help(help)
   * help(pydoc)

It can still be defined in one location and then use "+ pydoc_disclaimer" in the desired locations.

----------
nosy: +ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 05:26:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 04:26:45 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290054405.25.0.390821249675.issue10446@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>> 1) I assume you have checked that this code does not produce two newlines (one in the string,
>> one from the print function or write method):

> Yes, it should be clear from the output that I presented above.
Okay, I had missed that.

> I think TextDoc.indent() takes care of the trailing '\n'.
What is take care?  Removing it?

> That won't work for maintenance branches. (I am not even sure docs are
> built for maintenance branches.)
3.1 and 2.7 docs are rebuilt.

> I am not so sure about micro-version
There is only one version* directive which uses a micro number.  It?s a bit unfortunate.

> If there was say latest/X.Y, I would use that.  Wait -
> there is: docs.python.org/X.Y.  Would you prefer that?
My point was that people used 2.7 docs even when developing for 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 06:03:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 05:03:20 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290054405.25.0.390821249675.issue10446@psf.upfronthosting.co.za>
Message-ID: <AANLkTim6Hg5aXZ-UG=SQRizU_rZxHiDWLcFe-r5dF9Yj@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Nov 17, 2010 at 11:26 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
>> If there was say latest/X.Y, I would use that. ?Wait -
>> there is: docs.python.org/X.Y. ?Would you prefer that?
> My point was that people used 2.7 docs even when developing for 2.6.

The point of this bug report was that 3.x pydoc was sending users to
2.7, which is clearly unacceptable. As long as documentation bug fixes
are backported to maintenance branches, I don't see an advantage in
consulting 3.2 when developing for 3.1.

Now, I keep this issue open to decide if we should backport this to
2.7 where this is not a bug (yet), but will be when default docs
switch to 3.x.  What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 06:06:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 05:06:42 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290056802.56.0.308564936698.issue10446@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> The point of this bug report was that 3.x pydoc was sending users to
> 2.7, which is clearly unacceptable.
Agreed.  My reply about x.y vs. x.y+1 was a reaction to your patch, not a misunderstanding of the point of this bug.

> As long as documentation bug fixes are backported to maintenance
> branches, I don't see an advantage in consulting 3.2 when developing for 3.1.
I prefer version-specific docs too, but the thread on python-dev seemed to show I was not in the majority.

> Now, I keep this issue open to decide if we should backport this to
> 2.7 where this is not a bug (yet), but will be when default docs
> switch to 3.x.  What do you think?
+1 for backporting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 06:19:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 05:19:58 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290054080.09.0.453976305121.issue10446@psf.upfronthosting.co.za>
Message-ID: <AANLkTikcVs1i1LgMmudXyM6BnHBmh=YMUwdnmBu5xmj6@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Nov 17, 2010 at 11:21 PM, Ron Adam <report at bugs.python.org> wrote:
..
> I noticed in your patch, the disclaimer only prints when pydoc can find a doc location (docloc is not None).

This is not a disclaimer, but an explanation of the relationship
between pydoc pages and the reference manual.

>?So it may not get displayed at all depending on how python is installed.

docloc should not be None for standard library modules.  This is a
separate issue.

> ?I also think having it on every page may be a bit overly cautious. (IMHO)

In text viewer you only see one page at a time.  In HTML you may put
it on the index or start page.

docloc is None for 3rd party modules (pydocs checks for site-packages
component in path).  The logic is not very robust, but that is a
separate issue.

That's fine.

No, these places are almost never seen.  Also, one should not think of
this as a disclaimer, but as an explanation of why she is shown a link
to a reference page when full documentation is already displayed.

> It can still be defined in one location and then use "+ pydoc_disclaimer" in the desired locations.

Sure.   Just don't call it "disclaimer".  Maybe Doc.REFTEXT constant
next to Doc.PYTHONDOCS?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 06:25:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 05:25:06 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290057906.13.0.370730628049.issue10446@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Nov 17, 2010 at 11:21 PM, Ron Adam <report at bugs.python.org> wrote:
..
> I noticed in your patch, the disclaimer only prints when pydoc can find a doc location (docloc is not None).

This is not a disclaimer, but an explanation of the relationship
between pydoc pages and the reference manual.

> So it may not get displayed at all depending on how python is installed.

docloc should not be None for standard library modules.  This is a
separate issue.

>  I also think having it on every page may be a bit overly cautious. (IMHO)

In text viewer you only see one page at a time.  In HTML you may put
it on the index or start page.

> I'm also not sure it is correct to have that when viewing third party modules as the doc location
> in those cases will be broken anyway.
>
docloc is None for 3rd party modules (pydocs checks for site-packages
component in path).  The logic is not very robust, but that is a
separate issue.

> The obvious places to put it are:
>   * top of the pydoc html module index.  (first page displayed)
That's fine.

>   * in the welcome message for interactive help()
>   * help(help)
>   * help(pydoc)
>
No, these places are almost never seen.  Also, one should not think of
this as a disclaimer, but as an explanation of why she is shown a link
to a reference page when full documentation is already displayed.

> It can still be defined in one location and then use "+ pydoc_disclaimer" in the desired locations.

Sure.   Just don't call it "disclaimer".  Maybe Doc.REFTEXT constant
next to Doc.PYTHONDOCS?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 06:25:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 05:25:14 +0000
Subject: [issue10446] pydoc3 links to 2.x library reference
In-Reply-To: <1290015143.43.0.140543543356.issue10446@psf.upfronthosting.co.za>
Message-ID: <1290057914.63.0.846388648027.issue10446@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg121440

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10446>
_______________________________________

From report at bugs.python.org  Thu Nov 18 06:44:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 05:44:52 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290059092.05.0.107444821332.issue2001@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching pydoc.png screenshot that shows how the new navigation bar is rendered in my browser.  It looks a little bit busy and I don't like (get)/(search) buttons jumping below the text boxes when the browser window is is not wide enough.

----------
Added file: http://bugs.python.org/file19630/pydoc.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Thu Nov 18 06:45:32 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 18 Nov 2010 05:45:32 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290059132.92.0.567412441833.issue2001@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/issue2001>
_______________________________________

From report at bugs.python.org  Thu Nov 18 06:56:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 05:56:11 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290059771.36.0.500301972698.issue2001@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Shouldn't tests for new features added to Lib/test/test_pydoc.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Thu Nov 18 07:13:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 06:13:00 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290060780.16.0.787796573056.issue4153@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Reopening because it looks like the fix was reverted in r82301.

"""
This HOWTO discusses Python 2.x?s support for Unicode, and explains various problems that people commonly encounter when trying to work with Unicode. (This HOWTO has not yet been updated to cover the 3.x versions of Python.)
""" http://docs.python.org/dev/howto/unicode.html

----------
nosy: +belopolsky
status: closed -> open
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 07:54:16 2010
From: report at bugs.python.org (Ron Adam)
Date: Thu, 18 Nov 2010 06:54:16 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290063256.16.0.382515838112.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Thanks for the review ?ric!  The more eyes on this the better it will be.

I'm not familiar with rietveld yet.  But no time like the present to get started.  Here's the link.

   http://codereview.appspot.com/3151042/


I didn't play around with the html too much. Mostly I just wanted to get it to work for now.  I plan on adding support for style sheets, so a lot of the html code will be updated at that time.

Alex, the version info is just what sys.version returns, that was just easy to do, we can probably trim that down a bit.

The "Index of Modules" can be shortened to "Index" or "Modules".

I can have the get, and search box's always be two lines.  Something like...

Python 3.2a4/rev#     Get    [________]    Index
Platform              Search [________]    Topics : Keywords

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Thu Nov 18 08:18:17 2010
From: report at bugs.python.org (Evgeny Kapun)
Date: Thu, 18 Nov 2010 07:18:17 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>


New submission from Evgeny Kapun <abacabadabacaba at gmail.com>:

This code crashes Python:

import io, mmap
io.BytesIO(b' ').readinto(memoryview(mmap.mmap(-1, 1, prot=mmap.PROT_READ)))

----------
components: Interpreter Core
messages: 121446
nosy: abacabadabacaba
priority: normal
severity: normal
status: open
title: memoryview can be used to write into readonly buffer
type: crash
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10451>
_______________________________________

From report at bugs.python.org  Thu Nov 18 08:37:29 2010
From: report at bugs.python.org (Ron Adam)
Date: Thu, 18 Nov 2010 07:37:29 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290065849.46.0.393272046055.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Sense these features reuse other parts of pydoc, they are are covered to some degree by the existing tests.  

An easy test would be to just start the server and then shut it down after a short timeout.  Better than nothing.

I'll try reading and writing directly to the socket and working up some tests from that.  I don't suppose there's something like that already in the test suite I can copy?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Thu Nov 18 09:57:15 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Thu, 18 Nov 2010 08:57:15 +0000
Subject: [issue10183] test_concurrent_futures failure on Windows
In-Reply-To: <1287860051.06.0.49357269827.issue10183@psf.upfronthosting.co.za>
Message-ID: <1290070635.18.0.54663451469.issue10183@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Would you include the entire output of the test run?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10183>
_______________________________________

From report at bugs.python.org  Thu Nov 18 10:54:59 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Nov 2010 09:54:59 +0000
Subject: [issue4113] Add custom __repr__ to functools.partial
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1290074099.12.0.562739923979.issue4113@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> Looks like a reasonable proposal, but coding this in C is a chore. 

It's not that bad.  Most C code is a bit of a chore compared to Python but it really doesn't take much to write a C equivalent of: "functools.partial(%r, %s)" % (self.func, ', '.join(repr(a) for a in self.args)

>  How hard/inefficient would it be to have 99% of partial 
> coded in C and one stub in functools.py?

Let's not do this.  There is too little benefit to warrant going down the path of splitting the code across two langauges.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4113>
_______________________________________

From report at bugs.python.org  Thu Nov 18 11:15:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Nov 2010 10:15:40 +0000
Subject: [issue10183] test_concurrent_futures failure on Windows
In-Reply-To: <1287860051.06.0.49357269827.issue10183@psf.upfronthosting.co.za>
Message-ID: <1290075340.4.0.765058061085.issue10183@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Y:\>py3k\__svn__\PCbuild\amd64\python_d.exe -m test.regrtest -v test_concurrent_futures
== CPython 3.2a4+ (py3k, Nov 18 2010, 11:12:09) [MSC v.1500 64 bit (AMD64)]
==   Windows-7-6.1.7600 little-endian
==   Y:\py3k\__svn__\build\test_python_2016
[1/1] test_concurrent_futures
test_map (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ok
test_map_exception (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ok

test_map_timeout (test.test_concurrent_futures.ProcessPoolExecutorTest) ... FAIL

test_submit (test.test_concurrent_futures.ProcessPoolExecutorTest) ... ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolExecutorTest) ... o
k
test_map (test.test_concurrent_futures.ThreadPoolExecutorTest) ... ok
test_map_exception (test.test_concurrent_futures.ThreadPoolExecutorTest) ... ok
test_map_timeout (test.test_concurrent_futures.ThreadPoolExecutorTest) ... ok
test_submit (test.test_concurrent_futures.ThreadPoolExecutorTest) ... ok
test_submit_keyword (test.test_concurrent_futures.ThreadPoolExecutorTest) ... ok

test_all_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ... ok
test_all_completed_some_already_completed (test.test_concurrent_futures.ProcessP
oolWaitTests) ... ok
test_first_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ... ok
test_first_completed_one_already_completed (test.test_concurrent_futures.Process
PoolWaitTests) ... ok
test_first_exception (test.test_concurrent_futures.ProcessPoolWaitTests) ... ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ProcessPoo
lWaitTests) ... ok
test_first_exception_some_already_complete (test.test_concurrent_futures.Process
PoolWaitTests) ... ok
test_timeout (test.test_concurrent_futures.ProcessPoolWaitTests) ... FAIL
test_all_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... ok
test_all_completed_some_already_completed (test.test_concurrent_futures.ThreadPo
olWaitTests) ... ok
test_first_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... ok
test_first_completed_one_already_completed (test.test_concurrent_futures.ThreadP
oolWaitTests) ... ok
test_first_exception (test.test_concurrent_futures.ThreadPoolWaitTests) ... ok
test_first_exception_one_already_failed (test.test_concurrent_futures.ThreadPool
WaitTests) ... ok
test_first_exception_some_already_complete (test.test_concurrent_futures.ThreadP
oolWaitTests) ... ok
test_timeout (test.test_concurrent_futures.ThreadPoolWaitTests) ... ok
test_no_timeout (test.test_concurrent_futures.ProcessPoolAsCompletedTests) ... o
k
test_zero_timeout (test.test_concurrent_futures.ProcessPoolAsCompletedTests) ...
 ok
test_no_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTests) ... ok

test_zero_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTests) ...
ok
test_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_cancelled (test.test_concurrent_futures.FutureTests) ... ok
test_done (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_cancelled (test.test_concurrent_futures.FutureTests)
... ok
test_done_callback_already_failed (test.test_concurrent_futures.FutureTests) ...
 ok
test_done_callback_already_successful (test.test_concurrent_futures.FutureTests)
 ... ok
test_done_callback_raises (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_cancel (test.test_concurrent_futures.FutureTests) ... ok

test_done_callback_with_exception (test.test_concurrent_futures.FutureTests) ...
 ok
test_done_callback_with_result (test.test_concurrent_futures.FutureTests) ... ok

test_exception_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_repr (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_running (test.test_concurrent_futures.FutureTests) ... ok
test_context_manager_shutdown (test.test_concurrent_futures.ProcessPoolShutdownT
est) ... ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) ... ok
test_processes_terminate (test.test_concurrent_futures.ProcessPoolShutdownTest)
... ok
test_run_after_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) .
.. ok
test_context_manager_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTe
st) ... ok
test_del_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... ok
test_run_after_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ..
. ok
test_threads_terminate (test.test_concurrent_futures.ThreadPoolShutdownTest) ...
 ok

======================================================================
FAIL: test_map_timeout (test.test_concurrent_futures.ProcessPoolExecutorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_concurrent_futures.py", line 572, in test_
map_timeout
    self.assertEquals([42, 42], results)
AssertionError: Lists differ: [42, 42] != []

First list contains 2 additional elements.
First extra element 0:
42

- [42, 42]
+ []

======================================================================
FAIL: test_timeout (test.test_concurrent_futures.ProcessPoolWaitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_concurrent_futures.py", line 442, in test_
timeout
    future1]), finished)
AssertionError: Items in the first set but not the second:
<Future at 0x2e7e330 state=running>

----------------------------------------------------------------------
Ran 55 tests in 48.469s

FAILED (failures=2)
test test_concurrent_futures failed -- multiple errors occurred
1 test failed:
    test_concurrent_futures
[106578 refs]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10183>
_______________________________________

From report at bugs.python.org  Thu Nov 18 11:21:53 2010
From: report at bugs.python.org (Valery Khamenya)
Date: Thu, 18 Nov 2010 10:21:53 +0000
Subject: [issue10351] Add autocompletion for keys in dictionaries
In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>
Message-ID: <1290075713.86.0.72983466193.issue10351@psf.upfronthosting.co.za>


Valery Khamenya <khamenya at gmail.com> added the comment:

Guys, do you expect anythig else from me in respect to this issue? Let me know it before my non-stopable garbage collector wipes all the details from my brain away :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10351>
_______________________________________

From report at bugs.python.org  Thu Nov 18 11:40:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Nov 2010 10:40:18 +0000
Subject: [issue10351] Add autocompletion for keys in dictionaries
In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>
Message-ID: <1290076818.8.0.728688423689.issue10351@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +facundobatista, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10351>
_______________________________________

From report at bugs.python.org  Thu Nov 18 13:08:30 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 18 Nov 2010 12:08:30 +0000
Subject: [issue7652] Merge C version of decimal into py3k.
In-Reply-To: <1262860972.65.0.690079130991.issue7652@psf.upfronthosting.co.za>
Message-ID: <1290082110.42.0.195886911812.issue7652@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

An update on the progress:

All development currently happens in my private mpdecimal repository. The
next version of mpdecimal (2.0) is finished, stable and will be released
once all tests have completed successfully. Running the whole test suite
can take several weeks, since Valgrind is involved and all Python versions
from 2.5 to 3.2 are tested.


In py3k-cdecimal, r86497 is an exact copy of mpdecimal-2.0. All buildbots
pass the short tests.


Major improvements:

   o Full compatibility with decimal.py 3.2, including the new hash
     functions and float operations.

   o With the new FloatOperation signal, accidental float operations
     can be detected.

   o The underlying library - libmpdec - now has 100% code coverage
     together with Makefile targets for creating coverage reports.
     In particular, every possible allocation failure during an
     operation can be tested in brute force style.

   o The module has 85% code coverage. All lines except failures
     of Python C-API functions are tested.

   o Several minor bug fixes, most of them deal with allocation
     failures under extreme bignum conditions.



Potential reviewers:

I'll be happy to answer questions here or privately. IMO the best way to
get acquainted with the module is to do the regular build and tests first,
then explore Lib/test/mpdecimal, reading LIBTEST.txt and PYTEST.txt.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7652>
_______________________________________

From report at bugs.python.org  Thu Nov 18 13:30:12 2010
From: report at bugs.python.org (Raphael Mankin)
Date: Thu, 18 Nov 2010 12:30:12 +0000
Subject: [issue10452] Unhelpful diagnostic 'cannot find the path specified'
In-Reply-To: <1290083412.79.0.787041165854.issue10452@psf.upfronthosting.co.za>
Message-ID: <1290083412.79.0.787041165854.issue10452@psf.upfronthosting.co.za>


New submission from Raphael Mankin <raph at mankin.org.uk>:

Something somewhere in the library issues the diagnostic 'The system cannot find the path specified' with no indication of what path it was looking for nor where the error was detected.

The relevant routine needs modification to print at least the path and preferably also a back-trace.

----------
components: Library (Lib)
messages: 121453
nosy: raph at mankin.org.uk
priority: normal
severity: normal
status: open
title: Unhelpful diagnostic 'cannot find the path specified'
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10452>
_______________________________________

From report at bugs.python.org  Thu Nov 18 13:47:15 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 18 Nov 2010 12:47:15 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>
Message-ID: <1290084435.97.0.2405910391.issue10260@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Committed as revision 86510

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10260>
_______________________________________

From report at bugs.python.org  Thu Nov 18 14:31:10 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 18 Nov 2010 13:31:10 +0000
Subject: [issue10452] Unhelpful diagnostic 'cannot find the path specified'
In-Reply-To: <1290083412.79.0.787041165854.issue10452@psf.upfronthosting.co.za>
Message-ID: <1290087070.98.0.206602416452.issue10452@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

What code were you executing when this message was printed? What platform are you running on? What's the exact version of Python this happens with? (If you're running 2.6.x, what's "x" equal to?)

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10452>
_______________________________________

From report at bugs.python.org  Thu Nov 18 14:33:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 13:33:11 +0000
Subject: [issue10444] A mechanism is needed to override waiting for Python
	threads to finish
In-Reply-To: <1290002661.34.0.535369286873.issue10444@psf.upfronthosting.co.za>
Message-ID: <1290087191.82.0.791262200864.issue10444@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -Python 2.6, Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10444>
_______________________________________

From report at bugs.python.org  Thu Nov 18 14:38:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 13:38:29 +0000
Subject: [issue10452] Unhelpful diagnostic 'cannot find the path specified'
In-Reply-To: <1290083412.79.0.787041165854.issue10452@psf.upfronthosting.co.za>
Message-ID: <1290087509.1.0.797778058511.issue10452@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/issue10452>
_______________________________________

From report at bugs.python.org  Thu Nov 18 14:38:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 13:38:51 +0000
Subject: [issue10451] memoryview can be used to write into readonly buffer
In-Reply-To: <1290064697.49.0.308725501485.issue10451@psf.upfronthosting.co.za>
Message-ID: <1290087531.88.0.778469648261.issue10451@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10451>
_______________________________________

From report at bugs.python.org  Thu Nov 18 15:18:17 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 18 Nov 2010 14:18:17 +0000
Subject: [issue10452] Unhelpful diagnostic 'cannot find the path specified'
In-Reply-To: <1290083412.79.0.787041165854.issue10452@psf.upfronthosting.co.za>
Message-ID: <1290089897.4.0.231410064612.issue10452@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I ask about the specific version and platform because the string "cannot find the path specified" doesn't appear anywhere in release26-maint. And indeed "cannot find the" doesn't appear anywhere except comments. I'm going to close this issue, assuming it's a problem in something other than the standard library. If you have a repeatable case, please let us know and reopen the issue (or I can reopen it for you).

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10452>
_______________________________________

From report at bugs.python.org  Thu Nov 18 15:27:43 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 18 Nov 2010 14:27:43 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290090463.16.0.565411071884.issue10356@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I wouldn't risk changing the exception type in 2.7.  It's fine for 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Thu Nov 18 16:05:07 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 18 Nov 2010 15:05:07 +0000
Subject: [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>
Message-ID: <1290092707.73.0.691816824208.issue9991@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r86514 (py3k) and r86515 (release31-maint).

----------
assignee:  -> orsenthil
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9991>
_______________________________________

From report at bugs.python.org  Thu Nov 18 16:05:40 2010
From: report at bugs.python.org (Tim Golden)
Date: Thu, 18 Nov 2010 15:05:40 +0000
Subject: [issue10452] Unhelpful diagnostic 'cannot find the path specified'
In-Reply-To: <1290089897.4.0.231410064612.issue10452@psf.upfronthosting.co.za>
Message-ID: <4CE540BF.6030605@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

It's almost certainly coming straight back from the O/S,
where Python is doing its usual thing of channelling
an O/S error directly. Obviously we could special-case
this or any other specific error; but we usually don't

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10452>
_______________________________________

From report at bugs.python.org  Thu Nov 18 16:07:23 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 18 Nov 2010 15:07:23 +0000
Subject: [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>
Message-ID: <1290092843.89.0.871695043091.issue9991@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9991>
_______________________________________

From report at bugs.python.org  Thu Nov 18 16:11:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Nov 2010 15:11:43 +0000
Subject: [issue10447] zipfile: IOError for long directory paths on Windows
In-Reply-To: <1290021253.83.0.149273656602.issue10447@psf.upfronthosting.co.za>
Message-ID: <1290093103.96.0.326053614815.issue10447@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree with Amaury.  IMO the IOError is the correct error, since it is bubbling up unexpectedly (from zipfile's viewpoint) from a lower layer and is not an error specific to the zip protocol implementation. (CF the discussion surrounding PEP 3151).

Probably there should indeed be a common base class for the existing zipfile errors, but that's a feature request.

----------
nosy: +r.david.murray
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10447>
_______________________________________

From report at bugs.python.org  Thu Nov 18 16:24:13 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 18 Nov 2010 15:24:13 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290093853.74.0.53526416992.issue10356@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Thanks for all the comments! I agree that a change in 2.7 might cause
trouble. 

Committed the ValueError in r86517 (py3k).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Thu Nov 18 16:35:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Nov 2010 15:35:13 +0000
Subject: [issue10425] xmlrpclib support for None isn't compliant with XMLRPC
In-Reply-To: <1289824037.0.0.671749345837.issue10425@psf.upfronthosting.co.za>
Message-ID: <1290094513.6.0.847491090755.issue10425@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In case it isn't clear from the discussion in issue8792: I'd be in favor of supporting extensions as long as their usage is an opt-in feature. The current nil support is already an opt-in feature. If alternative spellings of nil need to be supported, or other extensions, it might be necessary to refactor this extension support a bit, so that extensions can be independently be developed and activated.

As for Python's usage of nil: it is specified in

http://ontosys.com/xml-rpc/extensions.php

and also referenced in the Wikipedia. IMO, it would have been better if Apache had used the pre-existing extension, instead of coming up with its own (supposedly only because the pre-existing one wasn't namespace-based).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10425>
_______________________________________

From report at bugs.python.org  Thu Nov 18 16:37:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Nov 2010 15:37:57 +0000
Subject: [issue8792] Support Apache extensions to XML-RPC in xmlrpclib
In-Reply-To: <1289913461.23.0.124948142632.issue8792@psf.upfronthosting.co.za>
Message-ID: <4CE5484F.6070702@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> An addition: It was reported in #10425 that None values are
> incorrectly serialized as <value><nil/></value>, instead of just
> <nil/>, or maybe <{namespace prefix for extensions defined by
> Apache}:nil/>.

This is not incorrect, but follows the specification of the nil
element, see, for example

http://en.wikipedia.org/wiki/XML-RPC

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8792>
_______________________________________

From report at bugs.python.org  Thu Nov 18 16:50:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Nov 2010 15:50:29 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1290095429.21.0.425417403637.issue10441@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

db: there *is* no "sane system ca path", or Python would have done that long ago. On Windows, it may be possible to drop OpenSSL, and use the system certificate store. However, that would be a major rewrite, and it may not be possible to provide the entire API anymore.

The best that could be done is to provide a configuration option (e.g. global variable) that should be treated as a default value, and then leave it to people distributing Python to fill out this variable in a sensible way.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From mail at timgolden.me.uk  Thu Nov 18 16:05:35 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Thu, 18 Nov 2010 15:05:35 +0000
Subject: [issue10452] Unhelpful diagnostic 'cannot find the path specified'
In-Reply-To: <1290089897.4.0.231410064612.issue10452@psf.upfronthosting.co.za>
References: <1290089897.4.0.231410064612.issue10452@psf.upfronthosting.co.za>
Message-ID: <4CE540BF.6030605@timgolden.me.uk>

It's almost certainly coming straight back from the O/S,
where Python is doing its usual thing of channelling
an O/S error directly. Obviously we could special-case
this or any other specific error; but we usually don't

From report at bugs.python.org  Thu Nov 18 17:01:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Nov 2010 16:01:49 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1290095429.21.0.425417403637.issue10441@psf.upfronthosting.co.za>
Message-ID: <1290096103.3522.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The best that could be done is to provide a configuration option (e.g.
> global variable) that should be treated as a default value, and then
> leave it to people distributing Python to fill out this variable in a
> sensible way.

Actually, OpenSSL already does a similar thing (see issue10443).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:03:48 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 16:03:48 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290096228.91.0.0902191622746.issue4153@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The changes added in r82301 are misleading because code examples in this HOWTO have been converted to 3.x.  I am attaching a patch that removes "has not yet been updated to cover the 3.x" warning and makes some minor stylistic changes.

I have bumped the release version to 1.12, but I would like to remove the revision history which is largely irrelevant.

----------
keywords: +patch
Added file: http://bugs.python.org/file19631/issue4153.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:04:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 16:04:34 +0000
Subject: [issue4476] compileall.py fails if current dir has a "types" subdir
	with 3.0 (ok with 2.5)
In-Reply-To: <1228107974.27.0.161282978705.issue4476@psf.upfronthosting.co.za>
Message-ID: <1290096274.13.0.488961315915.issue4476@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.1, Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4476>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:07:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 16:07:07 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

It would be useful if ?python -m compileall -h? was possible.  Right now it fails with ?option -h not recognized? and prints its help text, which is a bit silly :)

Bug week-end candidate!

----------
assignee: eric.araujo
components: Library (Lib)
keywords: easy
messages: 121467
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Add -h/--help option to compileall
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:08:52 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 18 Nov 2010 16:08:52 +0000
Subject: [issue10450] Fix markup in Misc/NEWS
In-Reply-To: <1290048675.36.0.613944727318.issue10450@psf.upfronthosting.co.za>
Message-ID: <1290096532.94.0.0681481435093.issue10450@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Perhaps "make patchcheck" (a.k.a Tools/scripts/patchcheck.py ) should verify the markup of Misc/NEWS?  Not sure what the easiest way to do that is, though, without bringing in lots of deps.

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10450>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:11:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 16:11:31 +0000
Subject: [issue10454] Clarify compileall options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

This is the help text of compileall:

 usage: python compileall.py [-l] [-f] [-q] [-d destdir] [-x regexp] [-i list] [directory|file ...]
 -l: don't recurse down
 -f: force rebuild even if timestamps are up-to-date
 -q: quiet operation
 -d destdir: purported directory name for error messages
    if no directory arguments, -l sys.path is assumed
 -x regexp: skip files matching the regular expression regexp
    the regexp is searched for in the full path of the file
 -i list: expand list with its content (file and directory names)
 -b: Produce legacy byte-compile file paths

1) I do not understand the help of -d and -i.  Experimenting with the script, reading the code and eventually looking at the file history would certainly clear that.

2) The short usage line at the top also lacks mention of ?-b?.

3) (minor) I want to rephrase -x, -d and -b.

Bug week-end candidate!

----------
assignee: docs at python
components: Documentation
keywords: easy
messages: 121469
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Clarify compileall options
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10454>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:11:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 16:11:54 +0000
Subject: [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1290096714.45.0.591557952278.issue10454@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: Clarify compileall options -> Clarify compileall command-line options

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10454>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:12:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 16:12:30 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290096750.21.0.96904721317.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

One neat way to solve this is to make compileall use argparse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:12:47 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 18 Nov 2010 16:12:47 +0000
Subject: [issue1353344] python.desktop
Message-ID: <1290096767.69.0.159389854394.issue1353344@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/issue1353344>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:18:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 16:18:00 +0000
Subject: [issue10454] Clarify compileall command-line options
In-Reply-To: <1290096691.96.0.508340552683.issue10454@psf.upfronthosting.co.za>
Message-ID: <1290097080.59.0.835515749391.issue10454@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In addition, the line ?if no directory arguments, -l sys.path is assumed? seems misplaced.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10454>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:18:10 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Nov 2010 16:18:10 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle
	SSL	certificate validation
In-Reply-To: <1290096103.3522.3.camel@localhost.localdomain>
Message-ID: <4CE551C0.5030600@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> The best that could be done is to provide a configuration option (e.g.
>> global variable) that should be treated as a default value, and then
>> leave it to people distributing Python to fill out this variable in a
>> sensible way.
> 
> Actually, OpenSSL already does a similar thing (see issue10443).

This may not be satisfying to users. For example, our Windows
distribution doesn't ship with any certicates (AFAIK); I have no
clue where exactly OpenSSL would be looking for them, either.
People worried about this problem probably would want a way to
fill the list of trusted CA certificates.

Regards,
Martin

----------
title: some stdlib modules need to be updated to handle SSL certificate validation -> some stdlib modules need to be updated to handle SSL	certificate validation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:34:22 2010
From: report at bugs.python.org (david)
Date: Thu, 18 Nov 2010 16:34:22 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <4CE551C0.5030600@v.loewis.de>
Message-ID: <AANLkTikrc5FVsJAGMUiLpJSoYRVEY8xtJNNGYVXFg1Qw@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

On 19 November 2010 03:18, Martin v. L?wis <report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>>> The best that could be done is to provide a configuration option (e.g.
>>> global variable) that should be treated as a default value, and then
>>> leave it to people distributing Python to fill out this variable in a
>>> sensible way.
>>
>> Actually, OpenSSL already does a similar thing (see issue10443).
>
> This may not be satisfying to users. For example, our Windows
> distribution doesn't ship with any certicates (AFAIK); I have no
> clue where exactly OpenSSL would be looking for them, either.
> People worried about this problem probably would want a way to
> fill the list of trusted CA certificates.
>

Martin does it matter?
To be honest I don't know about that many client side python windows
applications for which this is a problem for. Maybe I am mistaken. If
this is the case, then how do these projects work at the moment? (or
do they just not care about this...) . However, they could bundle
their own certificates, so I don't see this as an issue.

However, you seem confused here:
" I have no
> clue where exactly OpenSSL would be looking for them, either.
> People worried about this problem probably would want a way to
> fill the list of trusted CA certificates."

Erh, those people can already do this, but the problem is by default
none are selected.
IMHO something is probably better than nothing in this case(by default).

----------
title: some stdlib modules need to be updated to handle SSL	certificate validation -> some stdlib modules need to be updated to handle SSL certificate validation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:38:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 16:38:40 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290098320.41.0.161890093388.issue4153@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file19632/issue4153.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:38:50 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 16:38:50 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290098330.38.0.774582316347.issue4153@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file19631/issue4153.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:45:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 16:45:38 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290098738.95.0.38982554074.issue4153@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

r82301 appears to be a blind merge of r82120 from the trunk.  It is fairly obvious that it was not intentional.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:46:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 16:46:52 +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: <1290098812.81.0.263401865969.issue9312@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch tweaked and committed in r86521.  Gory details follow.

The patch applied with only two fuzzy hunks and one rejected hunk.

I did a careful review of "" ? ``""`` changes and edited a number of them.  I?m confident in my choices but am of course open to comments on the checkin.

My remark about not using :program:`name --option` was wrong.  It is actually supported, see for instance in shutil.rst ?Unix command :program:`cp -p`?.  I apologize for causing you unnecessary work.  I changed that back before committing.

I ran ?make clean html? in the docs (no warnings) and looked at the HTML output for each change.  Modules that wrongly used :option: are fixed; conversely, timeit and unittest now have a good-looking, indexed list of options, the program/cmdoption combo you used is terrific!

Actually, I found that so cool that I added an option list for ?unittest discover? (was a table) and ?compileall? (was a plain paragraph, missing two options).  Consider that an experiment; I?m willing to revert them if people prefer the old form.

I?ll rewrap too long or too short lines in a following commit.  I?ll also backport relevant parts to 3.1 and 2.7 with the approval of the release manager.

Thank you Eli for this contribution.  Thanks Terry and Georg for the help.

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:47:48 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 18 Nov 2010 16:47:48 +0000
Subject: [issue2244] urllib and urllib2 decode userinfo multiple times
In-Reply-To: <1204819810.33.0.413464262118.issue2244@psf.upfronthosting.co.za>
Message-ID: <1290098868.88.0.651530765697.issue2244@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r86520 (py3k) and r86522 (release31-maint). 
unquote happens at the first level inside Request class, _parse method.

Shall port to py2.7.

----------
nosy:  -BreamoreBoy
resolution:  -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2244>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:48:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 16:48:26 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290098906.4.0.768623297881.issue4153@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +akuchling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:48:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 18 Nov 2010 16:48:47 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <AANLkTikrc5FVsJAGMUiLpJSoYRVEY8xtJNNGYVXFg1Qw@mail.gmail.com>
Message-ID: <1290098923.3522.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > This may not be satisfying to users. For example, our Windows
> > distribution doesn't ship with any certicates (AFAIK); I have no
> > clue where exactly OpenSSL would be looking for them, either.
> > People worried about this problem probably would want a way to
> > fill the list of trusted CA certificates.

Right, this is just a helper in case OpenSSL is configured correctly by
the OS vendor (the OpenSSL packaged by Linux distros usually is).

> Erh, those people can already do this, but the problem is by default
> none are selected.
> IMHO something is probably better than nothing in this case(by default).

We can't change anything *by default* since it would break
compatibility. We can just provide helpers and arguments to make it easy
to switch to a more "secure" behaviour (for some meaning of secure).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Thu Nov 18 17:52:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 18 Nov 2010 16:52:37 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290099157.36.0.825720954742.issue4153@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/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 18:06:08 2010
From: report at bugs.python.org (lkraav)
Date: Thu, 18 Nov 2010 17:06:08 +0000
Subject: [issue1669349] make install fails if no previous Python installation
Message-ID: <1290099968.84.0.83128468286.issue1669349@psf.upfronthosting.co.za>


lkraav <leho at kraav.com> added the comment:

i think i am running into this trying to cross-compile for i686-gentoo-linux-uclibc and have been unable to figure out how to get altinstall to succeed:

http://bugs.gentoo.org/show_bug.cgi?id=269111#c12

build log available at http://bugs.gentoo.org/attachment.cgi?id=253831&action=view

any thoughts?

----------
nosy: +lkraav

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669349>
_______________________________________

From report at bugs.python.org  Thu Nov 18 18:12:13 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 18 Nov 2010 17:12:13 +0000
Subject: [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>
Message-ID: <1290100333.54.0.044390522379.issue9991@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

r86523(py3k) and r86524(release31-maint)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9991>
_______________________________________

From report at bugs.python.org  Thu Nov 18 18:12:39 2010
From: report at bugs.python.org (david)
Date: Thu, 18 Nov 2010 17:12:39 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1290098923.3522.5.camel@localhost.localdomain>
Message-ID: <AANLkTikWiTyJ1O7mns6o50bQbeufS2er=9=WBYHCut1J@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

On 19 November 2010 03:48, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> > This may not be satisfying to users. For example, our Windows
>> > distribution doesn't ship with any certicates (AFAIK); I have no
>> > clue where exactly OpenSSL would be looking for them, either.
>> > People worried about this problem probably would want a way to
>> > fill the list of trusted CA certificates.
>
> Right, this is just a helper in case OpenSSL is configured correctly by
> the OS vendor (the OpenSSL packaged by Linux distros usually is).
>
>> Erh, those people can already do this, but the problem is by default
>> none are selected.
>> IMHO something is probably better than nothing in this case(by default).
>
> We can't change anything *by default* since it would break
> compatibility. We can just provide helpers and arguments to make it easy
> to switch to a more "secure" behaviour (for some meaning of secure).

what about an environmental setting that can be used to enforce
checking (or the like) ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Thu Nov 18 18:40:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 18 Nov 2010 17:40:08 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle
	SSL	certificate validation
In-Reply-To: <AANLkTikrc5FVsJAGMUiLpJSoYRVEY8xtJNNGYVXFg1Qw@mail.gmail.com>
Message-ID: <4CE564F5.60401@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> This may not be satisfying to users. For example, our Windows
>> distribution doesn't ship with any certicates (AFAIK); I have no
>> clue where exactly OpenSSL would be looking for them, either.
>> People worried about this problem probably would want a way to
>> fill the list of trusted CA certificates.
>>
> 
> Martin does it matter?
> To be honest I don't know about that many client side python windows
> applications for which this is a problem for. Maybe I am mistaken.

I can't understand why you are saying that. The very same issues
that people perceive as problems on Unix ("users can be victim
to man in the middle attack") also exist on Windows. If you run
a Python script that does https on Windows, you can *also* be
MITM-victim (as likely as you can on Unix, that is).

Or are you suggesting that Python Windows applications don't use SSL?

> If
> this is the case, then how do these projects work at the moment? (or
> do they just not care about this...) .

"The projects" may be scripts that somebody developed that never get
released. But yes, most people ignore/accept the problem (often as
gruntingly as the Unix users).

> However, they could bundle
> their own certificates, so I don't see this as an issue.

Who is "they"? Most people get their Python binaries from python.org,
and they don't build "applications" from it, but run "scripts".

> However, you seem confused here:
> " I have no
>> clue where exactly OpenSSL would be looking for them, either.
>> People worried about this problem probably would want a way to
>> fill the list of trusted CA certificates."
> 
> Erh, those people can already do this, but the problem is by default
> none are selected.

You misunderstood. I was not proposing that scripts provide a CA
list, but that users might deploy a CA list into their Python
installation, which is then picked up in the same way as you are asking
for on Ubuntu.

----------
title: some stdlib modules need to be updated to handle SSL certificate validation -> some stdlib modules need to be updated to handle SSL	certificate validation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Thu Nov 18 18:51:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 17:51:40 +0000
Subject: [issue7828] chr() and ord() documentation for wide characters
In-Reply-To: <1264999918.27.0.407460194608.issue7828@psf.upfronthosting.co.za>
Message-ID: <1290102700.29.0.552294557148.issue7828@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19633/issue7828.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7828>
_______________________________________

From report at bugs.python.org  Thu Nov 18 19:10:20 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 18 Nov 2010 18:10:20 +0000
Subject: [issue7828] chr() and ord() documentation for wide characters
In-Reply-To: <1264999918.27.0.407460194608.issue7828@psf.upfronthosting.co.za>
Message-ID: <1290103820.13.0.715783523388.issue7828@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Looks good to me, except for a 'stings' near the end of the patch.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7828>
_______________________________________

From report at bugs.python.org  Thu Nov 18 19:16:41 2010
From: report at bugs.python.org (lkraav)
Date: Thu, 18 Nov 2010 18:16:41 +0000
Subject: [issue1669349] make install fails if no previous Python installation
Message-ID: <1290104201.43.0.270610756346.issue1669349@psf.upfronthosting.co.za>


lkraav <leho at kraav.com> added the comment:

i have managed to get past unicodedata fails by manually enabling unicodedata (https://groups.google.com/group/comp.lang.python/browse_thread/thread/21a3b6db8f5a246b?hl=en). got another error right after that, but that might be something further gentoo/xcompile specific, details in gentoo bug for those interested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1669349>
_______________________________________

From report at bugs.python.org  Thu Nov 18 19:37:33 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 18 Nov 2010 18:37:33 +0000
Subject: [issue7132] Regexp: capturing groups in repetitions
In-Reply-To: <1255550896.44.0.457470031322.issue7132@psf.upfronthosting.co.za>
Message-ID: <1290105453.15.0.465884147524.issue7132@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Earlier this week I discovered that .Net supports repeated capture and its API suggested a much cleaner approach than what Perl offered, so I'll be adding it to the regex module at:

    http://pypi.python.org/pypi/regex

The new methods will follow the example of .group() & co.

Given a match object m, m.group(i) returns the last match of group i (or None if there's no match), so I'll be adding m.captures(i) to return a tuple of the captures (an empty tuple if there's no match). I'll also be adding m.starts(i), m.ends(i) and m.spans(i).

The issue for this work is #2636.

Units tests are welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7132>
_______________________________________

From report at bugs.python.org  Thu Nov 18 19:48:22 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 18 Nov 2010 18:48:22 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290106102.02.0.17170001061.issue10356@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Should there be a 'versionchanged' note in the doc, even if the error type was not documented?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Thu Nov 18 19:55:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 18:55:39 +0000
Subject: [issue7828] chr() and ord() documentation for wide characters
In-Reply-To: <1264999918.27.0.407460194608.issue7828@psf.upfronthosting.co.za>
Message-ID: <1290106539.89.0.511681476491.issue7828@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r86526 (3.2) and r86527 (3.1).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7828>
_______________________________________

From report at bugs.python.org  Thu Nov 18 20:41:38 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Thu, 18 Nov 2010 19:41:38 +0000
Subject: [issue10455] typo in urllib.request documentation
In-Reply-To: <1290109297.93.0.111882063571.issue10455@psf.upfronthosting.co.za>
Message-ID: <1290109297.93.0.111882063571.issue10455@psf.upfronthosting.co.za>


New submission from Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com>:

Typo in Doc/library/urllib.request.rst, under the "urllib.response" module description: "and" -> "an"

----------
assignee: docs at python
components: Documentation
files: urllib.request_typo.diff
keywords: patch
messages: 121487
nosy: docs at python, jfinkels
priority: normal
severity: normal
status: open
title: typo in urllib.request documentation
versions: Python 3.2
Added file: http://bugs.python.org/file19634/urllib.request_typo.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10455>
_______________________________________

From report at bugs.python.org  Thu Nov 18 20:41:55 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 18 Nov 2010 19:41:55 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290109315.27.0.672337666392.issue4153@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Thanks for persisting with this. Looking at the patch:

@@ -65,7 +63,7 @@
 goal was to have Unicode contain the alphabets for every single human language.
 It turns out that even 16 bits isn't enough to meet that goal, and the modern
 Unicode specification uses a wider range of codes, 0-1,114,111 (0x10ffff in
-base-16).
+base 16).

I visually parse 0-1,114,111 as 0-1, 114, 111. So I think either the commas should be removed or extra spaces are needed: 0-1114111 or 0 - 1,114,111. In your recent (and excellent) chr/ord doc patch, you used (or stayed with) 'hexadecimal' versus 'base 16'. Do we have a standard? I *think* I prefer the former.

-character with value 0x12ca (4810 decimal).  The Unicode standard contains a lot
+character with value 0x12ca (4,810 decimal).  The Unicode standard contains a lot

I prefer without the added comma.

     >>> b'\x80abc'.decode("utf-8", "replace")
-    '\ufffdabc'
+    '???abc'

Three replacements (i with diaeresis, upside-down ?, 1/2) for one bad char looks wrong. With IDLE I get '?abc' (? in hexagon, codepoint 65533). Perhaps something just went wrong to patch from your file to my browser window.

@@ -281,10 +279,10 @@
 built-in :func:`ord` function that takes a one-character Unicode string and
 returns the code point value::

You fixed chr/ord doc, need to fix references thereto in this doc.

-point.  The ``\U`` escape sequence is similar, but expects 8 hex digits, not 4::
+point.  The ``\U`` escape sequence is similar, but expects eight base 16
+digits, not four::

I really think of them as hex or hexadecimal digits, just as 0-9 are decimal, not base 10 digits.


 
     >>> s = "a\xac\u1234\u20ac\U00008000"
               ^^^^ two-digit hex escape

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 20:42:12 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Nov 2010 19:42:12 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290109332.38.0.219220722647.issue4153@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/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 20:51:43 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Nov 2010 19:51:43 +0000
Subject: [issue10455] typo in urllib.request documentation
In-Reply-To: <1290109297.93.0.111882063571.issue10455@psf.upfronthosting.co.za>
Message-ID: <1290109903.83.0.50296791699.issue10455@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Fixed in r86528 (py3k) and r86529 (release31-maint), thanks!

----------
nosy: +ezio.melotti
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10455>
_______________________________________

From report at bugs.python.org  Thu Nov 18 21:00:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 20:00:26 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1290109315.27.0.672337666392.issue4153@psf.upfronthosting.co.za>
Message-ID: <AANLkTikmBxw=7C0c7ruS04180UNAkUZPi+GYwPjZE+=C@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Nov 18, 2010 at 2:41 PM, Terry J. Reedy <report at bugs.python.org> wrote:
..
> I visually parse 0-1,114,111 as 0-1, 114, 111. So I think either the commas
> should be removed or extra spaces are needed: 0-1114111 or 0 - 1,114,111.

What about "0 through 1,114,111"?

> you used (or stayed with) 'hexadecimal' versus 'base 16'. Do we have a standard?
> I *think* I prefer the former.

I prefer 'base 16'.  I thought about changing 'hexadecimal' to 'base
16' in chr/ord docs, but decided to leave it because the term
'hexadecimal' is used elsewhere on the same page notably in hex()
function description where it is quite appropriate.   No, we don't
have a standard.  I've also seen "base-16" used elsewhere which I
really don't like.

> + ? ?'???abc'
>
> Three replacements (i with diaeresis, upside-down ?, 1/2) for one bad char looks wrong.

That must be UTF-8 misinterpreted as Latin-1.  Won't affect the commit.

> With IDLE I get '?abc' (? in hexagon, codepoint 65533). Perhaps something
> just went wrong to patch from your file to my browser window.

Yes.  I get the same on the terminal window and that's what it should look like.

> ?built-in :func:`ord` function that takes a one-character Unicode string and
> ?returns the code point value::
>
> You fixed chr/ord doc, need to fix references thereto in this doc.
>

I don't understand.  I think "one-character Unicode string" is fine
here because "Unicode string" means an abstract Unicode string, not
:class:`str`.

> -point. ?The ``\U`` escape sequence is similar, but expects 8 hex digits, not 4::
> +point. ?The ``\U`` escape sequence is similar, but expects eight base 16
> +digits, not four::
>
> I really think of them as hex or hexadecimal digits, just as 0-9 are decimal, not base 10 digits.
>

I am fine with "hexadecimal" here.  I did not like "hex".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 21:12:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 18 Nov 2010 20:12:21 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <AANLkTikmBxw=7C0c7ruS04180UNAkUZPi+GYwPjZE+=C@mail.gmail.com>
Message-ID: <AANLkTinKQnOBxBti_=JM3Bub-H-kV2B0ExhyROrqJicQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Nov 18, 2010 at 3:00 PM, Alexander Belopolsky
<report at bugs.python.org> wrote:
..
>> I really think of them as hex or hexadecimal digits, just as 0-9 are decimal, not base 10 digits.
>>
>
> I am fine with "hexadecimal" here. ?I did not like "hex".

If you think about it, "hexadecimal digit" is a twice oxymoron because
both "decimal" and "digit" imply base 10. :-)  It does look like the
most widely used term, nevertheless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 21:16:51 2010
From: report at bugs.python.org (Terry Herron)
Date: Thu, 18 Nov 2010 20:16:51 +0000
Subject: [issue10456] unittest.main(verbosity=2) broke in python31,
	worked when I had python27
In-Reply-To: <1290111411.37.0.30283584247.issue10456@psf.upfronthosting.co.za>
Message-ID: <1290111411.37.0.30283584247.issue10456@psf.upfronthosting.co.za>


New submission from Terry Herron <terry.herron at sas.com>:

The unittest.py module no longer accepts verbosity=2 when calling main.  This worked in Python27.  Example...

     unittest.main(verbosity=2)
     

## THE FIX IN unittest.py##
CHANGE FROM:
1547   def __init__(self, module='__main__', defaultTest=None,
1548           argv=None, testRunner=TextTestRunner,
1549           testLoader=defaultTestLoader, exit=True):

1560       self.verbosity = 1

CHANGE TO:
1547   def __init__(self, module='__main__', defaultTest=None,
1548           argv=None, testRunner=TextTestRunner,
1549           testLoader=defaultTestLoader, exit=True, verbosity=1):

1560       self.verbosity = verbosity

----------
messages: 121492
nosy: teherr
priority: normal
severity: normal
status: open
title: unittest.main(verbosity=2) broke in python31, worked when I had python27
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10456>
_______________________________________

From report at bugs.python.org  Thu Nov 18 21:17:50 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 18 Nov 2010 20:17:50 +0000
Subject: [issue10456] unittest.main(verbosity=2) broke in python31,
	worked when I had python27
In-Reply-To: <1290111411.37.0.30283584247.issue10456@psf.upfronthosting.co.za>
Message-ID: <1290111470.2.0.204523256123.issue10456@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10456>
_______________________________________

From report at bugs.python.org  Thu Nov 18 21:20:17 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Nov 2010 20:20:17 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290111617.49.0.237105059248.issue10356@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The choice between ValueError and TypeError can sometimes be ambiguous and seem arbitrary and I understand why you're gravitating towards ValueError (because it works some values and not others), but in this case the API is already fixed by what hash() does elsewhere.

It is no fair to users to have to wrap hash(x) calls with a try/except that catches both exceptions.  So, we should still to a consistent hash API:

  >>> hash([])
  Traceback (most recent call last):
    File "<pyshell#1>", line 1, in <module>
      hash([])
  TypeError: unhashable type: 'list'

In this case, practicality beats purity and released beats unreleased.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Thu Nov 18 21:28:07 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 18 Nov 2010 20:28:07 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290112087.73.0.318235165596.issue10356@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: skrah -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Thu Nov 18 21:44:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 18 Nov 2010 20:44:06 +0000
Subject: [issue10456] unittest.main(verbosity=2) broke in python31,
	worked when I had python27
In-Reply-To: <1290111411.37.0.30283584247.issue10456@psf.upfronthosting.co.za>
Message-ID: <1290113046.09.0.7361317064.issue10456@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

2.7 is post-3.1.  This works as you expect in 3.2.  This is, it is a new feature in both 2.7 and 3.2.

(NB: this is why I wanted 3.2 to come out close to 2.7, but fortunately this is the first report like this I think we've gotten.)

----------
nosy: +r.david.murray
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10456>
_______________________________________

From report at bugs.python.org  Thu Nov 18 21:47:07 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 18 Nov 2010 20:47:07 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290113227.05.0.162103074232.issue4153@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

0 through ... is fine with me.

Yes, hex numeral would be more accurate than hex digit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Thu Nov 18 23:24:42 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Thu, 18 Nov 2010 22:24:42 +0000
Subject: [issue5421] Irritating error message by socket's sendto method
In-Reply-To: <1236248103.61.0.911918415156.issue5421@psf.upfronthosting.co.za>
Message-ID: <1290119082.38.0.290427885744.issue5421@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Here's a patch, which performs argument checking in a way to be able to provide better error message like that:

>>> my_socket.sendto("No Umlaut", ("localhost", 514))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' does not support the buffer interface

----------
keywords: +patch
nosy: +nvetoshkin
Added file: http://bugs.python.org/file19635/issue5421.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5421>
_______________________________________

From report at bugs.python.org  Fri Nov 19 00:02:35 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 18 Nov 2010 23:02:35 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1290111617.49.0.237105059248.issue10356@psf.upfronthosting.co.za>
Message-ID: <20101118230229.GA24733@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Raymond Hettinger <report at bugs.python.org> wrote:
> The choice between ValueError and TypeError can sometimes be ambiguous and seem arbitrary and I understand why you're gravitating towards ValueError (because it works some values and not others), but in this case the API is already fixed by what hash() does elsewhere.
> 
> It is no fair to users to have to wrap hash(x) calls with a try/except that catches both exceptions.  So, we should still to a consistent hash API:
> 
>   >>> hash([])
>   Traceback (most recent call last):
>     File "<pyshell#1>", line 1, in <module>
>       hash([])
>   TypeError: unhashable type: 'list'
> 
> In this case, practicality beats purity and released beats unreleased.

Ok, this makes sense. I can revert the commit unless you prefer to handle
it yourself.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Fri Nov 19 00:41:45 2010
From: report at bugs.python.org (=?utf-8?q?Mihai_Capot=C4=83?=)
Date: Thu, 18 Nov 2010 23:41:45 +0000
Subject: [issue5207] extend strftime/strptime format for RFC3339 and RFC2822
In-Reply-To: <1234285622.79.0.0309055191852.issue5207@psf.upfronthosting.co.za>
Message-ID: <1290123705.86.0.879636167721.issue5207@psf.upfronthosting.co.za>


Changes by Mihai Capot? <mihai at mihaic.ro>:


----------
nosy: +mihaic

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5207>
_______________________________________

From report at bugs.python.org  Fri Nov 19 00:49:37 2010
From: report at bugs.python.org (=?utf-8?q?Mihai_Capot=C4=83?=)
Date: Thu, 18 Nov 2010 23:49:37 +0000
Subject: [issue7584] datetime.rfcformat() for Date and Time on the Internet
In-Reply-To: <1261941488.23.0.907898109437.issue7584@psf.upfronthosting.co.za>
Message-ID: <1290124177.49.0.716677316032.issue7584@psf.upfronthosting.co.za>


Changes by Mihai Capot? <mihai at mihaic.ro>:


----------
nosy: +mihaic

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7584>
_______________________________________

From report at bugs.python.org  Fri Nov 19 01:17:27 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Fri, 19 Nov 2010 00:17:27 +0000
Subject: [issue10183] test_concurrent_futures failure on Windows
In-Reply-To: <1287860051.06.0.49357269827.issue10183@psf.upfronthosting.co.za>
Message-ID: <1290125847.83.0.00953502677661.issue10183@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Could you try rerunning the tests with the attached patch? It could be that your machines are just terribly slow at starting new Python instances.

----------
keywords: +patch
Added file: http://bugs.python.org/file19636/timing.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10183>
_______________________________________

From report at bugs.python.org  Fri Nov 19 02:02:49 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 19 Nov 2010 01:02:49 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290128569.24.0.951426921857.issue4153@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> Yes, hex numeral would be more accurate than hex digit.

Stick with hex digit.   We've used that phraseology for a long time.  See string.hexdigits for example.  And "hex numeral" just sounds weird -- it makes me do a double-take to see if there was some special implied meaning.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Fri Nov 19 02:46:47 2010
From: report at bugs.python.org (david)
Date: Fri, 19 Nov 2010 01:46:47 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <4CE564F5.60401@v.loewis.de>
Message-ID: <AANLkTim-wS1z1rC+fv3YPNPh7dJ4XX=n-WTcHuBADfp8@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

On 19 November 2010 04:40, Martin v. L?wis <report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>>> This may not be satisfying to users. For example, our Windows
>>> distribution doesn't ship with any certicates (AFAIK); I have no
>>> clue where exactly OpenSSL would be looking for them, either.
>>> People worried about this problem probably would want a way to
>>> fill the list of trusted CA certificates.
>>>
>>
>> Martin does it matter?
>> To be honest I don't know about that many client side python windows
>> applications for which this is a problem for. Maybe I am mistaken.
>
> I can't understand why you are saying that. The very same issues
> that people perceive as problems on Unix ("users can be victim
> to man in the middle attack") also exist on Windows. If you run
> a Python script that does https on Windows, you can *also* be
> MITM-victim (as likely as you can on Unix, that is).
>
> Or are you suggesting that Python Windows applications don't use SSL?
>
>> If
>> this is the case, then how do these projects work at the moment? (or
>> do they just not care about this...) .
>
> "The projects" may be scripts that somebody developed that never get
> released. But yes, most people ignore/accept the problem (often as
> gruntingly as the Unix users).
>
>> However, they could bundle
>> their own certificates, so I don't see this as an issue.
>
> Who is "they"? Most people get their Python binaries from python.org,
> and they don't build "applications" from it, but run "scripts".
>
>> However, you seem confused here:
>> " I have no
>>> clue where exactly OpenSSL would be looking for them, either.
>>> People worried about this problem probably would want a way to
>>> fill the list of trusted CA certificates."
>>
>> Erh, those people can already do this, but the problem is by default
>> none are selected.
>
> You misunderstood. I was not proposing that scripts provide a CA
> list, but that users might deploy a CA list into their Python
> installation, which is then picked up in the same way as you are asking
> for on Ubuntu.

No I did not misunderstand at all.
I am pushing for safer defaults or a way to enable safe defaults.
Having to tamper with my python path and point at a modified version
of the ssl module doesn't sound like fun.

OH windows users those guys. Well if they don't have any certificates
at the moment and they don't know this, perhaps some one should tell
them?
I don't know I am not a windows python user.

----------
title: some stdlib modules need to be updated to handle SSL	certificate validation -> some stdlib modules need to be updated to handle SSL certificate validation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Fri Nov 19 07:03:11 2010
From: report at bugs.python.org (5houston)
Date: Fri, 19 Nov 2010 06:03:11 +0000
Subject: [issue8028] self.terminate() from a multiprocessing.Process raises
	AttributeError exception
In-Reply-To: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za>
Message-ID: <1290146591.76.0.0675922444508.issue8028@psf.upfronthosting.co.za>


5houston <cadabras at gmail.com> added the comment:

Hi.
I tried my code (minCrashing.py) in windows using python 3.1.2, 2.3alpha4 and 3.1.3rc1
The behaviour is deeply different from linux 3.1.2.
I think it's a bug.
What do you think about it?

----------
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8028>
_______________________________________

From report at bugs.python.org  Fri Nov 19 07:30:23 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Fri, 19 Nov 2010 06:30:23 +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: <1290148223.25.0.486912968889.issue9312@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric,

I went over both the diffs and the HTML output from "make clean html" on the latest 3.2 trunk. Looks good to me!

Just a tiny nit re unittest.rst, where it says "supports three command-line options". This is the kind of comment that gets left behind when new options are added. I see no added value explicitly saying there are 3 options as opposed to "supports the following command-line options", and there's less chance for future mistakes. It's also more consistent with the list of options for "discover" a bit later in the same document. This is totally a stylistic issue, of course, so IMVHO :-)

Oh, and another thing about unittest.rst: in 24.3.9 where it says "The -c command-line option to unittest", for some reason the -c didn't get linked to the option, although I think you intended it to, since you marked it as :option:

P.S: the program/cmdoption combo idea was Georg's.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Fri Nov 19 09:39:56 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 19 Nov 2010 08:39:56 +0000
Subject: [issue10122] Documentation typo fix and a side question
In-Reply-To: <1287238144.34.0.432770346734.issue10122@psf.upfronthosting.co.za>
Message-ID: <1290155996.63.0.683219536399.issue10122@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

If you visit  http://docs.python.org/library/functions.html?highlight=getattr#getattr  there is still the word 'attributed' present in online docs. Please fix the docs completely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10122>
_______________________________________

From report at bugs.python.org  Fri Nov 19 10:33:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 19 Nov 2010 09:33:08 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290159188.11.0.497696380354.issue10356@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  Does anyone remember the reason for making sNaNs unhashable in the first place.  I recall there was a discussion about this, but can't remember which issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Fri Nov 19 10:41:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 19 Nov 2010 09:41:23 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290159683.78.0.125730132369.issue10356@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah, now I remember: making sNaNs hashable has the potential to introduce seemingly random exceptions with set and dict operations.  The logic went something like:

  (1) if sNaNs are hashable, you can put them in dicts,
  (2) operations on dicts make equality comparisons at (from the
      user's POV) unpredictable times (i.e., when hashes of two
      unequal objects happen to be equal), and
  (3) equality comparisons involving sNaNs raise an exception.

I'm wondering whether we should revisit the decision to have sNaN equalities raise an exception, and just have sNaN equality comparisons behave identically to those for (Decimal or float) NaNs in 3.2.

At any rate, if the code is left as is, the above logic should be added to the __hash__ function as a comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Fri Nov 19 11:07:40 2010
From: report at bugs.python.org (Scott Dial)
Date: Fri, 19 Nov 2010 10:07:40 +0000
Subject: [issue10430] _sha.sha().digest() method is endian-sensitive. and
	hexdigest()
In-Reply-To: <1289893015.01.0.604303806999.issue10430@psf.upfronthosting.co.za>
Message-ID: <1290161260.55.0.497778861662.issue10430@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

Got a test case that demonstrates a failure? Looks like it works to me...

$ uname -ip
sparc SUNW,Sun-Fire-280R
$ python -c 'import sys; print sys.byteorder'
big
$ python -c 'import sha; print sha.new(open("test", "rb").read()).hexdigest()'
851faf3199d27200abf2750c14ae6451696216a9
$ sha1sum -b test
851faf3199d27200abf2750c14ae6451696216a9 *test

# uname -ip
AMD Sempron(tm) Processor 2800+ AuthenticAMD
# python -c 'import sys; print sys.byteorder'
little
# python -c 'import sha; print sha.new(open("test", "rb").read()).hexdigest()'
851faf3199d27200abf2750c14ae6451696216a9
# sha1sum -b /tmp/test
851faf3199d27200abf2750c14ae6451696216a9 *test

I think your code analysis is wrong. Perhaps you missed the call to longReverse(), which does endianness byte-swapping, at the beginning of the sha_transform() that specifically is commented: "When run on a little-endian CPU we need to perform byte reversal on an array of longwords."

----------
nosy: +scott.dial

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10430>
_______________________________________

From report at bugs.python.org  Fri Nov 19 11:08:28 2010
From: report at bugs.python.org (Ray.Allen)
Date: Fri, 19 Nov 2010 10:08:28 +0000
Subject: [issue8690] multiprocessing.dummy.Queue does not expose same
	interface as multiprocessing.Queue
In-Reply-To: <1273603184.02.0.789462329458.issue8690@psf.upfronthosting.co.za>
Message-ID: <1290161308.79.0.538719401131.issue8690@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

+1 on make it identical to multiprossing.Queue. Since the documentation said:

multiprocessing.dummy replicates the API of multiprocessing but is no more than a wrapper around the threading module.

Does the word "replicates" implies that multiprossing.dummy.[AClass] should have the same interfaces as multiprossing.[AClass]? I think so. We should be able to use multiprossing.dummy.xxx wherever multiprossing.xxx can be used. We can just create a subclass of Queue.Queue and implemented these missing methods as dummy functions.

I wonder is there other inconsistence between multiprocessing.dummy and multiprocessing?

----------
nosy: +ysj.ray
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8690>
_______________________________________

From report at bugs.python.org  Fri Nov 19 11:26:39 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 19 Nov 2010 10:26:39 +0000
Subject: [issue10430] _sha.sha().digest() method is endian-sensitive. and
	hexdigest()
In-Reply-To: <1289893015.01.0.604303806999.issue10430@psf.upfronthosting.co.za>
Message-ID: <1290162399.02.0.48798899583.issue10430@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Something is definietly weird on the PS3.  I?ll give more concrete data soon.  (and yes, I may have misread the code)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10430>
_______________________________________

From report at bugs.python.org  Fri Nov 19 11:46:58 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 19 Nov 2010 10:46:58 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290163618.16.0.803198503662.issue10356@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

If I'm not mistaken, signaling NaNs are only created when the user
explicitly initializes a variable. I see this as direct request to
raise an exception whenever the variable is accessed in a way that
changes the outcome of the program:

This is the example I gave:

http://mail.python.org/pipermail/python-dev/2009-November/093952.html


Now, ideally one would still be allowed to store signaling NaNs in
a dictionary and have them raise at the _exact_ location where they
are used in a mathematical operation or influence control flow.

But since that's not possible, I prefer things as they are.


+1 for adding a comment to the hash function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Fri Nov 19 12:12:19 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 19 Nov 2010 11:12:19 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290165139.77.0.707431544334.issue10356@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

[Stefan]
> ... a direct request to raise an exception...

Understood;  the issue is that this conflicts with the general expectation that equality (and inequality) comparisons always work (at least, for objects that are perceived as immutable).  I think there needs to be a very good reason to have an equality comparison raise an exception, and I don't find this particular reason good enough.  The expected IEEE 754 semantics are still available through the published API:  e.g., using Decimal.compare instead of '=='.

So I'd lean towards having '==' follow Python rules rather than IEEE 754 rules in this case, with Decimal.compare available for the times when the IEEE 754 rules are important.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Fri Nov 19 12:13:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 19 Nov 2010 11:13:10 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290165190.54.0.220929769054.issue10356@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Grr.  Horrible formatting on that last comment.
Sorry about that.

Anyway, I'd be interested to hear other people's opinions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Fri Nov 19 14:32:26 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Fri, 19 Nov 2010 13:32:26 +0000
Subject: [issue10430] _sha.sha().digest() method is endian-sensitive. and
	hexdigest()
In-Reply-To: <1289893015.01.0.604303806999.issue10430@psf.upfronthosting.co.za>
Message-ID: <1290173546.83.0.151269105908.issue10430@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10430>
_______________________________________

From report at bugs.python.org  Fri Nov 19 14:32:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 13:32:30 +0000
Subject: [issue4476] compileall fails if current dir has a "types" package
In-Reply-To: <1228107974.27.0.161282978705.issue4476@psf.upfronthosting.co.za>
Message-ID: <1290173550.05.0.68050860317.issue4476@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I can reproduce in 3.1 and 3.2.  2.7 is okay.

----------
stage:  -> needs patch
title: compileall.py  fails if current dir has a "types" subdir with 3.0 (ok with 2.5) -> compileall fails if current dir has a "types" package

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4476>
_______________________________________

From report at bugs.python.org  Fri Nov 19 14:38:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 13:38:10 +0000
Subject: [issue4476] compileall fails if current dir has a "types" package
In-Reply-To: <1228107974.27.0.161282978705.issue4476@psf.upfronthosting.co.za>
Message-ID: <1290173890.96.0.344485298201.issue4476@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

python -v shows that runpy tries to import pkgutil which imports types which is the package in the current directory.  Is this an import bug or a worksforme ?don?t use standard module names in your projects??

----------
nosy: +brett.cannon, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4476>
_______________________________________

From report at bugs.python.org  Fri Nov 19 14:53:37 2010
From: report at bugs.python.org (Cherniavsky Beni)
Date: Fri, 19 Nov 2010 13:53:37 +0000
Subject: [issue10457] "Related help topics" shown outside pager
In-Reply-To: <1290174817.07.0.690141680958.issue10457@psf.upfronthosting.co.za>
Message-ID: <1290174817.07.0.690141680958.issue10457@psf.upfronthosting.co.za>


New submission from Cherniavsky Beni <cben at users.sf.net>:

help('NAMESPACES') or any other long help is shows in a pager.  That's great.  It's a bit surprising however that the text shown in the pager doesn't include the "Related help topics: ..." line, which is shown when you leave the pager.

There is practical benefit to see the related topics after you exited the pager - that's when you have the chance to follow these other topics.  But I think it should be duplicated inside the pager as well.

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 121514
nosy: cben, docs at python
priority: normal
severity: normal
status: open
title: "Related help topics" shown outside pager
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10457>
_______________________________________

From report at bugs.python.org  Fri Nov 19 14:58:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 13:58:26 +0000
Subject: [issue992389] attribute error after non-from import
Message-ID: <1290175106.98.0.504251342723.issue992389@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/issue992389>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:01:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 14:01:13 +0000
Subject: [issue10457] "Related help topics" shown outside pager
In-Reply-To: <1290174817.07.0.690141680958.issue10457@psf.upfronthosting.co.za>
Message-ID: <1290175273.62.0.170803445943.issue10457@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> 
components:  -Documentation
nosy: +eric.araujo -docs at python
stage:  -> needs patch
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10457>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:14:19 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 19 Nov 2010 14:14:19 +0000
Subject: [issue10430] _sha.sha().digest() method is endian-sensitive. and
	hexdigest()
In-Reply-To: <1289893015.01.0.604303806999.issue10430@psf.upfronthosting.co.za>
Message-ID: <1290176059.17.0.264722324076.issue10430@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If I was looking for opportunities for a compiler to do something weird, I'd start with the TestEndianness macro (i.e. maybe it is incorrectly flagging the Cell as little endian when it is actually big endian)

The endianness handling itself looks fine to me, though.

----------
nosy: +ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10430>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:18:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 14:18:17 +0000
Subject: [issue10436] tarfile.extractfile in "r|" stream mode fails with
	filenames or members from getmembers()
In-Reply-To: <1289931464.79.0.618120236196.issue10436@psf.upfronthosting.co.za>
Message-ID: <1290176297.22.0.211664112023.issue10436@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Documentation -Library (Lib)
nosy: +docs at python
stage:  -> needs patch
versions:  -Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10436>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:21:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Nov 2010 14:21:51 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1290065849.46.0.393272046055.issue2001@psf.upfronthosting.co.za>
Message-ID: <AANLkTik2FmE4fu_eLfDR=bkzcNMmCtEkWQt7imgO9i_z@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Nov 18, 2010 at 2:37 AM, Ron Adam <report at bugs.python.org> wrote:
..
> I'll try reading and writing directly to the socket and working up some tests from that.
> I don't suppose there's something like that already in the test suite I can copy?

I believe you can find relevant code in test/test_httpservers.py.
What I had in mind was simpler: test_pydoc already checks html output
for a module, but this test did not fail after I applied your patch.
There should be something in the tests that checks that the new
navigation bar is generated correctly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:23:29 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 19 Nov 2010 14:23:29 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1289900719.31.0.940052239207.issue10070@psf.upfronthosting.co.za>
Message-ID: <hbf.20101119kh3v@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

?ric Araujo writes:
>> That's fair enough.
> 
> :) Do you want to close this feature request then?

Me?  No.  I just figured that after all this arguing, I should mention
that closing it as out of scope is not something I'll be difficult about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:25:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Nov 2010 14:25:27 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290176727.23.0.208386265624.issue2001@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

issue2001_b.diff patch includes changes to urllib.  Is this intentional?  Is it a bug fix, a feature?  There is no mention in the NEWS file.  If these changes are needed for pydoc enhancements, I would like to separate them in its own issue and commit separately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:31:36 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 19 Nov 2010 14:31:36 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290177096.62.0.912814781148.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 Nov 19 15:32:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 19 Nov 2010 14:32:02 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1290177122.71.0.0871977654197.issue10070@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:32:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 14:32:20 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1290177140.57.0.0976773113556.issue9182@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Sergey: Do you want to make a patch for that, and/or for the documentation?  Guidelines are on http://www.python.org/dev/patches/

----------
nosy: +bethard
resolution: accepted -> 
versions: +Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:33:10 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 19 Nov 2010 14:33:10 +0000
Subject: [issue10458] 2.7 += re.ASCII
In-Reply-To: <1290177190.59.0.824077136231.issue10458@psf.upfronthosting.co.za>
Message-ID: <1290177190.59.0.824077136231.issue10458@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Could Python 2.7 get a dummy re.ASCII = re.A flag,
for source code compatibility with 3.2?

----------
components: Regular Expressions
messages: 121520
nosy: hfuru
priority: normal
severity: normal
status: open
title: 2.7 += re.ASCII
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10458>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:33:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 14:33:45 +0000
Subject: [issue8158] documentation of 'optparse' module incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1290177225.13.0.553274813774.issue8158@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
nosy: +docs at python -georg.brandl
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8158>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:34:45 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Nov 2010 14:34:45 +0000
Subject: [issue10458] 2.7 += re.ASCII
In-Reply-To: <1290177190.59.0.824077136231.issue10458@psf.upfronthosting.co.za>
Message-ID: <1290177285.66.0.252241860439.issue10458@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10458>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:36:27 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Fri, 19 Nov 2010 14:36:27 +0000
Subject: [issue10459] missing character names in unicodedata (CJK...)
In-Reply-To: <1290177387.08.0.667845269575.issue10459@psf.upfronthosting.co.za>
Message-ID: <1290177387.08.0.667845269575.issue10459@psf.upfronthosting.co.za>


New submission from Vlastimil Brom <vlastimil.brom at gmail.com>:

I just noticed an ommision of come character names in unicodedata module.
These are some CJK - Ideographs:

? (0x9fbc) - ? (0x9fcb)
 (CJK Unified Ideographs [19968-40959] [0x4e00-0x9fff])

? (0x2a700) - ? (0x2b734)
(CJK Unified Ideographs Extension C [173824-177983] [0x2a700-0x2b73f])

? (0x2b740) - ? (0x2b81d)
 (CJK Unified Ideographs Extension D [177984-178207] [0x2b740-0x2b81f])

The names are probably to be generated - e.g. CJK UNIFIED IDEOGRAPH-2A700 ... etc.

(Tested with the recompiled unicodedata - using unicode 6.0; with the py 27 - builtin module (unidata_version: '5.2.0') only the first two ranges are relevant (as CJK Unified Ideographs Extension D is an adition of Unicode 6)

(Also there are the unprintable ASCII controls, surrogates and private use areas, where the missing names are probably ok.)


I tested with the following rather clumsy code:

# # # # # # # # # # # # # # # 
# wide_unichr = custom unichr emulating unicode ranges beyond FFFF on narrow python build
codepoints_missing_char_names = [[-2,-2],] # dummy
for i in xrange(0x10FFFF+1):
    if unicodedata.category(wide_unichr(i))[:1] != 'C' and unicodedata.name(wide_unichr(i), u"??noname??") == u"??noname??":
        if codepoints_missing_char_names[-1][1] == i-1:
            codepoints_missing_char_names[-1][1] = i
        else:
            codepoints_missing_char_names.append([i, i])

for first, last in codepoints_missing_char_names[1:]:
    print u"%s (%s) - %s (%s)" % (wide_unichr(first), hex(first), wide_unichr(last), hex(last),)
# # # # # # # # # # # # # # # # # # # # # # # # # # 

Unfortunately, I can't provide a fix, as unicodedata involves C code, where my knowledge is near zero.

vbr

----------
messages: 121521
nosy: vbr
priority: normal
severity: normal
status: open
title: missing character names in unicodedata (CJK...)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10459>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:37:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 19 Nov 2010 14:37:26 +0000
Subject: [issue10458] 2.7 += re.ASCII
In-Reply-To: <1290177190.59.0.824077136231.issue10458@psf.upfronthosting.co.za>
Message-ID: <1290177446.43.0.0846127785024.issue10458@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

-1. That's a new feature.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10458>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:38:01 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Nov 2010 14:38:01 +0000
Subject: [issue10459] missing character names in unicodedata (CJK...)
In-Reply-To: <1290177387.08.0.667845269575.issue10459@psf.upfronthosting.co.za>
Message-ID: <1290177481.8.0.75296356854.issue10459@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/issue10459>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:40:43 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Fri, 19 Nov 2010 14:40:43 +0000
Subject: [issue10459] missing character names in unicodedata (CJK...)
In-Reply-To: <1290177387.08.0.667845269575.issue10459@psf.upfronthosting.co.za>
Message-ID: <1290177643.26.0.848684104704.issue10459@psf.upfronthosting.co.za>


Changes by Vlastimil Brom <vlastimil.brom at gmail.com>:


----------
components: +Library (Lib), Unicode
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10459>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:41:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 14:41:17 +0000
Subject: [issue10458] 2.7 += re.ASCII
In-Reply-To: <1290177190.59.0.824077136231.issue10458@psf.upfronthosting.co.za>
Message-ID: <1290177677.47.0.560329207429.issue10458@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10458>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:42:46 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 19 Nov 2010 14:42:46 +0000
Subject: [issue10430] _sha.sha().digest() method is endian-sensitive. and
	hexdigest()
In-Reply-To: <1289893015.01.0.604303806999.issue10430@psf.upfronthosting.co.za>
Message-ID: <1290177766.68.0.349837773491.issue10430@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Yes, in my original myopic observation I was mistaken in thinking that we were reading the digest out of the 5 entry int32 "digest" field in the SHAobject.
I?ve already verified that the "Endianness" field is correctly set.  What I thought was an obvious error due to people not using big-endian much, is probably much more subtle.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10430>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:47:53 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 19 Nov 2010 14:47:53 +0000
Subject: [issue4113] Add custom __repr__ to functools.partial
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1290178073.33.0.426133192694.issue4113@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Here is a patch. It includes tests.

----------
keywords: +patch
nosy: +durban
Added file: http://bugs.python.org/file19637/issue4113.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4113>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:52:52 2010
From: report at bugs.python.org (Mick Beaver)
Date: Fri, 19 Nov 2010 14:52:52 +0000
Subject: [issue10460] Misc/indent.pro does not reflect PEP 7
In-Reply-To: <1290178371.97.0.656359898425.issue10460@psf.upfronthosting.co.za>
Message-ID: <1290178371.97.0.656359898425.issue10460@psf.upfronthosting.co.za>


New submission from Mick Beaver <myheartinamerica at gmail.com>:

Hello,

I noticed that the indent.pro in Misc seems very different from PEP 7. Would it be possible to have one that produces C code that meets the PEP 7 style guidelines?

As always, thanks for all of the hard work for Python!

-Mick

----------
components: Demos and Tools
messages: 121526
nosy: Mick.Beaver
priority: normal
severity: normal
status: open
title: Misc/indent.pro does not reflect PEP 7
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10460>
_______________________________________

From report at bugs.python.org  Fri Nov 19 15:54:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 14:54:51 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1290178491.19.0.638038461691.issue8890@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Who wants to make a patch to update the documentation?

For command-line examples (like ?python setup.py install --install-base /tmp?), someone has to research what standard variable to use (TMPDIR, TMP, something else?).

----------
keywords: +easy
stage:  -> needs patch
title: Modules have dangerous examples in documentation -> Use tempfile instead of /tmp in examples
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:04:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 15:04:21 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1290179061.72.0.9456136855.issue8890@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch submission guidelines are found at http://www.python.org/dev/patches/

Since patches are made for the py3k branch, some matches in Henri?s grep won?t get patched: bsddb, compiler, posixfile and rexec have been removed.  The person that will commit the patch will have to edit those too when merging into 2.7, unless a kind soul provides one patch per branch (not a requirement).

Last remark: tempfile is a false positive; editing old whatsnew is not worth it IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:05:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Nov 2010 15:05:59 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290179159.03.0.0958787970618.issue2001@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

issue2001_c.diff is the same as issue2001_b.diff, but without urlparse changes and with minor modifications to pydoc.rst resolving a conflict with a recent commit.  I have also uploaded the same patch to rietveld:

http://codereview.appspot.com/3187042

Does anyone know how to properly subscribe report at bugs.python.org to the Rietveld issue so that we see reviews here?

----------
Added file: http://bugs.python.org/file19638/issue2001_c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:16:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 15:16:23 +0000
Subject: [issue8538] Add FlagAction to argparse
In-Reply-To: <1272303487.22.0.380388489779.issue8538@psf.upfronthosting.co.za>
Message-ID: <1290179783.37.0.205566600324.issue8538@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think FlagAction should implement strictly boolean options, that is --foo and --no-foo, without arguments at all.

For ConfigureAction, there is a precedent (unless I?m mistaken) in configure, which permits such things:
  --without-unicode
  --with-unicode=ucs4
  --with-unicode (uses default value for arg)

I say we focus on the simple FlagAction for this bug and keep ConfigureAction for another patch.

Yaniv: Can you give us a status update?

----------
keywords: +easy
title: Add ConfigureAction to argparse -> Add FlagAction to argparse

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8538>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:18:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 15:18:17 +0000
Subject: [issue9938] Documentation for argparse interactive use
In-Reply-To: <1285338690.84.0.283413950067.issue9938@psf.upfronthosting.co.za>
Message-ID: <1290179897.48.0.258309278687.issue9938@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do you want to work on a patch?

(Aside: you may want to learn about the cmd and shlex modules for read-eval-print-loop programs :)

----------
keywords: +easy
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9938>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:20:43 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 19 Nov 2010 15:20:43 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1290180043.96.0.988220399459.issue9182@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

The original point is basically a duplicate of issue 9338. It is undesirable behavior, I just don't know how to fix it. Patches to fix it are welcome (on issue 9338). ;-)

As to documenting '--', I agree it's hidden too far down in the documentation currently. I'd be happy to approve any documentation patch that makes the '--' workaround more visible.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:23:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Nov 2010 15:23:09 +0000
Subject: [issue4113] Add custom __repr__ to functools.partial
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1290180189.3.0.982102818074.issue4113@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

There is an ongoing discussion about deprecating undocumented PyUnicode_AppendAndDel(). See Marc-Andre's comment in msg121371:

"""
+.. c:function:: void PyUnicode_Append(PyObject **pleft, PyObject *right)
+
+   Concat two strings and put the result in *pleft. Sets *pleft to
+   NULL on error.
+
+.. c:function:: void PyUnicode_AppendAndDel(PyObject **pleft, PyObject *right)
+
+   Concat two strings and put the result in *pleft and drop the right
+   object. Sets *pleft to NULL on error.
+
+

Please don't document these two obscure APIs. Instead we should
make them private functions by prepending them with an underscore.
If you look at the implementations of those two APIs, they
are little more than a macros around PyUnicode_Concat().

3rd party extensions should use PyUnicode_Concat() to achieve
the same effect.
"""

While it is OK for Python library to use private APIs, please consider if PyUnicode_Concat() may be more appropriate.  If not, please make a case at issue 10435 for keeping it public.

----------
assignee:  -> belopolsky
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4113>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:23:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 15:23:14 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1290180194.06.0.196097452769.issue9182@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You?re right, sorry I was unclear: ?a patch for that? referred to the addition of ?--? in the generated usage text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:27:15 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 19 Nov 2010 15:27:15 +0000
Subject: [issue4476] compileall fails if current dir has a "types" package
In-Reply-To: <1228107974.27.0.161282978705.issue4476@psf.upfronthosting.co.za>
Message-ID: <1290180435.4.0.777999211838.issue4476@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Indeed, any time you shadow a standard library module you run the risk of breaking things. runpy (and its dependencies) are just like any other module in that respect.

----------
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4476>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:27:47 2010
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 19 Nov 2010 15:27:47 +0000
Subject: [issue8028] self.terminate() from a multiprocessing.Process raises
	AttributeError exception
In-Reply-To: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za>
Message-ID: <1290180467.22.0.957685773333.issue8028@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Can you please expand on "deeply different"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8028>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:29:50 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 19 Nov 2010 15:29:50 +0000
Subject: [issue10459] missing character names in unicodedata (CJK...)
In-Reply-To: <1290177387.08.0.667845269575.issue10459@psf.upfronthosting.co.za>
Message-ID: <4CE697EB.2050304@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Vlastimil Brom wrote:
> 
> New submission from Vlastimil Brom <vlastimil.brom at gmail.com>:
> 
> I just noticed an ommision of come character names in unicodedata module.
> These are some CJK - Ideographs:
> 
> ? (0x9fbc) - ? (0x9fcb)
>  (CJK Unified Ideographs [19968-40959] [0x4e00-0x9fff])
> 
> ? (0x2a700) - ? (0x2b734)
> (CJK Unified Ideographs Extension C [173824-177983] [0x2a700-0x2b73f])
> 
> ? (0x2b740) - ? (0x2b81d)
>  (CJK Unified Ideographs Extension D [177984-178207] [0x2b740-0x2b81f])
> 
> The names are probably to be generated - e.g. CJK UNIFIED IDEOGRAPH-2A700 ... etc.

I don't think we should fill those rather big ranges with generated
names, unless there's a standard for this. There are quite a
few ranges in the Unicode database that are assigned, but don't
have a literal name associated with them.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10459>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:30:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 15:30:46 +0000
Subject: [issue8158] Docstring of optparse.OptionParser incomplete
In-Reply-To: <1268763667.28.0.98928586354.issue8158@psf.upfronthosting.co.za>
Message-ID: <1290180646.12.0.614916319586.issue8158@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
title: documentation of 'optparse' module incomplete -> Docstring of optparse.OptionParser incomplete

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8158>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:32:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 15:32:31 +0000
Subject: [issue4476] compileall fails if current dir has a "types" package
In-Reply-To: <1228107974.27.0.161282978705.issue4476@psf.upfronthosting.co.za>
Message-ID: <1290180751.39.0.569877454463.issue4476@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do you think it would be useful to update the doc of compileall?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4476>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:36:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 15:36:24 +0000
Subject: [issue4391] optparse: use proper gettext plurals forms
In-Reply-To: <1227390268.91.0.0525140101381.issue4391@psf.upfronthosting.co.za>
Message-ID: <1290180984.59.0.30067665399.issue4391@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

optparse is widely used, so the answer to my question is: yes, it is worth fixing.  Checking argparse for the same errors is also a good idea.

Dwayne: can you update your patch to address my remarks?  If not, someone else or I may do it.  Adding the ?easy? keyword for potential bug-day contributors.

----------
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4391>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:37:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 15:37:15 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1290181035.08.0.112998558124.issue9921@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg118372

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:39:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 15:39:26 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1290181166.73.0.448097106496.issue9921@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think the comment is fine as is.  +1 to adding your wording to the docs.

----------
keywords: +patch
nosy: +eric.araujo
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:40:13 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 19 Nov 2010 15:40:13 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290181213.54.0.276413617593.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Gah, I accidentally generated a diff that included some unrelated changes to urrlib (and its tests) for a different issue I had been working on, and Ron's subsequent patch picked them up. I then misinterpreted "left them alone" to mean "didn't include them in the regenerated patch". Sorry about that - taking those changes out was the right thing to do.

The test_pyclbr change was necessary at the time (the new code isn't particularly class browser friendly, so the tests referencing pydoc started failing), but it shouldn't be needed now that the server and client implementation details are once again hidden inside function scopes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:44:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 15:44:38 +0000
Subject: [issue10396] stdin argument to pdb.Pdb doesn't work unless you also
	set Pdb.use_rawinput = False
In-Reply-To: <1289584221.71.0.586527779083.issue10396@psf.upfronthosting.co.za>
Message-ID: <1290181478.63.0.100619239833.issue10396@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 on clarifying the docs.  Michael, where in the file do you think it should go?  (You can also directly make a diff if you want.)

----------
assignee:  -> docs at python
components: +Documentation -Library (Lib)
keywords: +patch
nosy: +docs at python, eric.araujo
resolution: duplicate -> 
stage: committed/rejected -> patch review
status: closed -> open
superseder: cmd.py always uses raw_input, even when another stdin is specified -> 
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10396>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:49:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 15:49:24 +0000
Subject: [issue10395] new os.path function to extract common prefix based on
	path components
In-Reply-To: <1289574847.69.0.366708031395.issue10395@psf.upfronthosting.co.za>
Message-ID: <1290181764.11.0.963114178786.issue10395@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/issue10395>
_______________________________________

From report at bugs.python.org  Fri Nov 19 16:51:00 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 19 Nov 2010 15:51:00 +0000
Subject: [issue4476] compileall fails if current dir has a "types" package
In-Reply-To: <1228107974.27.0.161282978705.issue4476@psf.upfronthosting.co.za>
Message-ID: <1290181860.34.0.164226789518.issue4476@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No. Once you start shadowing standard library modules, all bets are off as to what will and won't work. It's one of the reasons we need to be somewhat careful with the naming of new standard library modules.

I'm mildly curious as to why 2.7 didn't also throw ImportError*, but given the description, I don't consider it incorrect behaviour that this scenario broke in 3.x.

*Off the top of my head, I would guess it is due to the change in initialisation order needed to bootstrap the new IO stack in 3.x, but it would take a bit of investigation to confirm that

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4476>
_______________________________________

From report at bugs.python.org  Fri Nov 19 17:00:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 16:00:55 +0000
Subject: [issue4476] compileall fails if current dir has a "types" package
In-Reply-To: <1228107974.27.0.161282978705.issue4476@psf.upfronthosting.co.za>
Message-ID: <1290182455.31.0.242466186969.issue4476@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the replies.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4476>
_______________________________________

From report at bugs.python.org  Fri Nov 19 17:05:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 16:05:04 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

The docs contain numerous examples that would trigger resource warnings under 3.2 (for example ?open(...).read()?).  They should be changed to use (and thus promote) the with statement.

Not adding the ?easy? keyword, since grepping for those things is not easy.

Not sure we?ll backport that to 3.1 and 2.7.

----------
assignee: docs at python
components: Documentation
messages: 121545
nosy: docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Use with statement throughout the docs
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Fri Nov 19 17:13:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 16:13:07 +0000
Subject: [issue10252] Fix resource warnings in distutils
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1290183187.61.0.882828801121.issue10252@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

These constructs don?t generate warnings at present but should IMO use the with statement too:

./distutils/command/upload.py:128:                                     open(filename+".asc").read())
./distutils/command/bdist_rpm.py:514:                    spec_file.extend(open(val, 'r').read().split('\n'))
./distutils/command/bdist_wininst.py:248:            bitmapdata = open(bitmap, "rb").read()
./distutils/command/bdist_wininst.py:288:        file.write(open(arcname, "rb").read())
./distutils/command/bdist_msi.py:399:            f.write(open(self.pre_install_script).read())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Fri Nov 19 17:22:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Nov 2010 16:22:11 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290183731.89.0.803365194039.issue4153@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 86530. Thanks Terry and Raymond for your comments.  I would like to keep this issue open (at a low priority) because the question in the titles is still relevant.  There are many new 3.x features that are not covered such as surrogateescape error handler.  Such topics may or may not be appropriate for a HOWTO.  there are also some stylistic changes that I would like to consider:

1. Replace verbatim URLs with properly formatted hyperlinked titles of the referenced resources.

2. I couldn't figure out who the original author was. With first person passages, such as "I remember looking at Apple ][ BASIC programs, .." it may be appropriate to list the original author at the top even if the text has been changed by others over the years.  At the very least the Acknowlegements section should start with "This article was originally written by X [on an occasion Y.]"

3. Examples should be properly marked up to allow sphinx to run them and check the output.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Fri Nov 19 17:30:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 16:30:42 +0000
Subject: [issue4153] Unicode HOWTO up to date?
In-Reply-To: <1224525840.81.0.649106205615.issue4153@psf.upfronthosting.co.za>
Message-ID: <1290184242.47.0.833952750673.issue4153@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed on 1 and 3.  Regarding 2, looking at the early history of the file makes me suspect that amk is the author.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4153>
_______________________________________

From report at bugs.python.org  Fri Nov 19 17:43:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Nov 2010 16:43:15 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1290184995.02.0.834555765001.issue9921@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

"first part" by itself sounds like there can only be two parts.  How about 'inserts a separator between each pair of...'

Also, what does 'absolute' mean on Windows?  Does it include the drive?  If so, the second sentence should probably say 'if a part starts with a separator...'  (Assuming, of course, that that's how ntpath.join actually works).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Fri Nov 19 17:45:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 16:45:32 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1290185132.75.0.352963091564.issue9921@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Comment in ntpath.isabs:

For Windows it is absolute if it starts with a slash or backslash (current volume), or if a pathname after the volume-letter-and-colon or UNC-resource starts with a slash or backslash.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Fri Nov 19 17:49:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 16:49:58 +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: <1290185398.71.0.331858351861.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My build error seems actually unrelated to encoding issues.  Working directory is ASCII-only, locale is UTF-8.

$ ./configure --with-pydebug
[snip]
$ make
[snip]
ranlib libpython3.2dm.a
gcc -pthread   -Xlinker -export-dynamic -o python Modules/python.o libpython3.2dm.a -lpthread -ldl  -lutil   -lm  
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Segmentation fault
make: *** [sharedmods] Erreur 139

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri Nov 19 17:52:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Nov 2010 16:52:32 +0000
Subject: [issue10396] stdin argument to pdb.Pdb doesn't work unless you also
	set Pdb.use_rawinput = False
In-Reply-To: <1289584221.71.0.586527779083.issue10396@psf.upfronthosting.co.za>
Message-ID: <1290185552.55.0.727094149379.issue10396@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The argument against adding this to the pdb docs is that if you pull in that statement from cmd, you really ought to pull in the full description of the __init__ arguments. And whether you do that or just pull in that single statement, you are duplicating the documentation from cmd.  This *may* be best, but it does increase the maintenance burden, since any change to cmd will require changes to both the cmd and pdb docs, whereas now someone changing cmd doesn't need to know that they also have to update pdb.  If the situation being documented here improves in some way, I'll bet we will forget to update the pdb docs accordingly....

So, I'm -1 on adding this to the pdb docs, but will bow to the wisdom of the doc folks :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10396>
_______________________________________

From report at bugs.python.org  Fri Nov 19 18:02:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 17:02:47 +0000
Subject: [issue10396] stdin argument to pdb.Pdb doesn't work unless you also
	set Pdb.use_rawinput = False
In-Reply-To: <1289584221.71.0.586527779083.issue10396@psf.upfronthosting.co.za>
Message-ID: <1290186167.46.0.702498712937.issue10396@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is a sound argument.  I had also missed your comment ?Note that the pdb docs direct you the cmd docs, which clearly document the need to set use_rawinput, so this is not even a doc bug?, which I was about to write with other words :)  There was actually no need to reopen this bug.

----------
assignee: docs at python -> 
components: +Library (Lib) -Documentation
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> cmd.py always uses raw_input, even when another stdin is specified

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10396>
_______________________________________

From report at bugs.python.org  Fri Nov 19 18:32:01 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Nowak?=)
Date: Fri, 19 Nov 2010 17:32:01 +0000
Subject: [issue10462] Handler.close is not called in subclass while
	Logger.removeHandler is called
In-Reply-To: <1290187921.16.0.743406159262.issue10462@psf.upfronthosting.co.za>
Message-ID: <1290187921.16.0.743406159262.issue10462@psf.upfronthosting.co.za>


New submission from ?ukasz Nowak <email at lnowak.com>:

Attached file produces output in MyHandler.close on python2.6.6, which is expected.

But on python 2.7 and 2.7.1rc1 it produces nothing, so my handler's close method is not called.

----------
components: Library (Lib)
files: checker.py
messages: 121554
nosy: Shufla
priority: normal
severity: normal
status: open
title: Handler.close is not called in subclass while Logger.removeHandler is called
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19639/checker.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10462>
_______________________________________

From report at bugs.python.org  Fri Nov 19 18:36:07 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Nowak?=)
Date: Fri, 19 Nov 2010 17:36:07 +0000
Subject: [issue10462] Handler.close is not called in subclass while
	Logger.removeHandler is called
In-Reply-To: <1290187921.16.0.743406159262.issue10462@psf.upfronthosting.co.za>
Message-ID: <1290188167.66.0.667852909861.issue10462@psf.upfronthosting.co.za>


?ukasz Nowak <email at lnowak.com> added the comment:

Attached simpler version of checker.

----------
Added file: http://bugs.python.org/file19640/checkersimple.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10462>
_______________________________________

From report at bugs.python.org  Fri Nov 19 18:36:57 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Nowak?=)
Date: Fri, 19 Nov 2010 17:36:57 +0000
Subject: [issue10462] Handler.close is not called in subclass while
	Logger.removeHandler is called
In-Reply-To: <1290187921.16.0.743406159262.issue10462@psf.upfronthosting.co.za>
Message-ID: <1290188217.3.0.761512455039.issue10462@psf.upfronthosting.co.za>


?ukasz Nowak <email at lnowak.com> added the comment:

Another snippet, which *WORKS* on python>=2.7, non catched exception is raised.

----------
Added file: http://bugs.python.org/file19641/checkerkeyint.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10462>
_______________________________________

From report at bugs.python.org  Fri Nov 19 18:59:51 2010
From: report at bugs.python.org (Ron Adam)
Date: Fri, 19 Nov 2010 17:59:51 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290189591.52.0.283323670262.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Here is the patch in the current state which includes the changes in issue2001_c.diff as well as most of the changes ?ric suggested.

Still to do:
  * Use the with statement in several places to ensure closing.
  * Add tests for the server.

I did try to make the header a bit less cluttered, but I'm not completely happy with it yet, but I think it will be good enough for now.  Fixing the HTML probably should be a separate issue where we can add a style sheet at the same time.  Lets get this patch in first.

This is also reitveld:  
    
    http://codereview.appspot.com/3151042/

----------
Added file: http://bugs.python.org/file19642/issue2001_d.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Fri Nov 19 19:50:24 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 19 Nov 2010 18:50:24 +0000
Subject: [issue10262] Add --disable-abi-flags option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1290192624.4.0.297451746426.issue10262@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

What specifically is the motivation for this option?  Since abiflags are used in many places, most of which are hidden from the end user, why are they a problem, and what are the use cases for suppressing them?

If it's to eliminate the abiflags in the binary names, then I can get on board with that.  (IOW, instead of symlinking python3.2 -> python3.2dmu, just write out python3.2 and avoid the extra symlinks).

Please clarify.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Fri Nov 19 20:10:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Nov 2010 19:10:33 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290193833.12.0.385717075111.issue10461@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

+1

BTW, I've updated examples in Unicode HOWTO to use with.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Fri Nov 19 20:23:46 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Nov 2010 19:23:46 +0000
Subject: [issue6941] Socket error when launching IDLE
In-Reply-To: <1253304050.64.0.637575348166.issue6941@psf.upfronthosting.co.za>
Message-ID: <1290194626.57.0.511857364449.issue6941@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Download and install a current release 2.6.6, 2.7, or 3.1.2 (or 2.7.1 or 3.1.3 in a week or so). Disable or otherwise reconfigure whatever firewall or security software you have that is blocking the socket connection (as your screenshot says).

If you still have a problem, ask on python-list and give the info needed for people to help (hardware, os and version, python version, security/firewall software). The bug tracker is for solving problems with Python, not with user machines.

Note that 2.6.6 and 3.1.3 are the last bugfix releases for their respective versions.

----------
nosy: +terry.reedy
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6941>
_______________________________________

From report at bugs.python.org  Fri Nov 19 20:42:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Nov 2010 19:42:53 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1290195773.07.0.831312765946.issue9769@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I don't understand Victor's argument in msg115889.  According to UTF-8 RFC, <http://www.ietf.org/rfc/rfc2279.txt>:

   -  US-ASCII values do not appear otherwise in a UTF-8 encoded
      character stream.  This provides compatibility with file systems
      or other software (e.g. the printf() function in C libraries) that
      parse based on US-ASCII values but are transparent to other
      values.

This means that printf-like formatters should not care whether the format string is in UTF-8, Latin1, or any other ASCII-compatible 8-bit encoding.  (Passing in multibyte encoding pretending to be bytes would of course lead to havoc, but C type system will protect you from that.)

It is also fairly simple to ssnity-check for UTF-8 if necessary, but in case of PyUnicode_FromFormat, the resulting string will be decoded as UTF-8, so all characters in the format string will be checked anyways.

Am I missing something?

----------
nosy: +belopolsky
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Fri Nov 19 20:55:32 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Nov 2010 19:55:32 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <1283557981.28.0.85027629308.issue9769@psf.upfronthosting.co.za>
Message-ID: <1290196532.53.0.817572540707.issue9769@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/issue9769>
_______________________________________

From report at bugs.python.org  Fri Nov 19 20:58:07 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Nov 2010 19:58:07 +0000
Subject: [issue10458] 2.7 += re.ASCII
In-Reply-To: <1290177190.59.0.824077136231.issue10458@psf.upfronthosting.co.za>
Message-ID: <1290196687.86.0.181418772049.issue10458@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10458>
_______________________________________

From report at bugs.python.org  Fri Nov 19 21:02:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 19 Nov 2010 20:02:20 +0000
Subject: [issue10462] Handler.close is not called in subclass while
	Logger.removeHandler is called
In-Reply-To: <1290187921.16.0.743406159262.issue10462@psf.upfronthosting.co.za>
Message-ID: <1290196940.49.0.406268451445.issue10462@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I doubt that close is ever called when removehandler is called.  That doesn't strike me as sensible semantics.  I suspect that what is happening is that in 2.6 calling removehandler removed all references to the handler, and python's garbage collection called the close method during cleanup.  In 2.7 something is probably still holding a reference; I know Vinay made a number of changes in how handlers are handled in 2.7/3.2.

I think Vinay will want to take a look since (assuming I am correct) the holding of the reference may be a bug, so I'm adding him to nosy.

However, you shouldn't depend on close getting called after the removehandler, since not all Python implementations do garbage collection/cleanup in the same way.  You should always explicitly call close when you are done with a resource.

Finally, I don't understand the point of your third example (but I haven't run it).

----------
nosy: +r.david.murray, vinay.sajip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10462>
_______________________________________

From report at bugs.python.org  Fri Nov 19 21:06:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Nov 2010 20:06:23 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <1290195773.07.0.831312765946.issue9769@psf.upfronthosting.co.za>
Message-ID: <201011192106.06983.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

On Friday 19 November 2010 20:42:53 you wrote:
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> I don't understand Victor's argument in msg115889.  According to UTF-8 RFC,
> <http://www.ietf.org/rfc/rfc2279.txt>:
> 
>    -  US-ASCII values do not appear otherwise in a UTF-8 encoded
>       character stream.  This provides compatibility with file systems
>       or other software (e.g. the printf() function in C libraries) that
>       parse based on US-ASCII values but are transparent to other
>       values.

Most C functions including printf works on multi*byte* strings, not on (wide) 
character strings. Whereas PyUnicode_FromFormatV() converts the format string 
(bytes) to unicode (characters). If you would like a comparaison in C, it's 
like printf()+mbstowcs() in the same function.

> This means that printf-like formatters should not care whether the format
> string is in UTF-8, Latin1, or any other ASCII-compatible 8-bit encoding. 

It's maybe true with bytes input and bytes output (eg. PyString_FromFormatV() 
of Python2), but it's no more true with bytes input and str output (eg. 
PyUnicode_FromFormatV() of Python3).

> It is also fairly simple to ssnity-check for UTF-8 if necessary, but in
> case of PyUnicode_FromFormat, the resulting string will be decoded as
> UTF-8, so all characters in the format string will be checked anyways.

I choosed to use ASCII instead of UTF-8, because an UTF-8 decoder is long (210 
lines) and complex (see PyUnicode_DecodeUTF8Stateful()), whereas ASCII decode 
is just: "unicode_char = (Py_UNICODE)byte;" + an if before to check that 0 <= 
byte <= 127).

Nobody noticed my change just because the whole Python code base only uses 
ASCII argument for the format argument of PyUnicode_FromFormatV().

Victor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Fri Nov 19 21:11:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 19 Nov 2010 20:11:13 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1290185398.71.0.331858351861.issue6011@psf.upfronthosting.co.za>
Message-ID: <201011192111.05602.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> My build error seems actually unrelated to encoding issues.  Working
> directory is ASCII-only, locale is UTF-8.
> 
> $ ./configure --with-pydebug
> [snip]
> $ make
> [snip]
> ranlib libpython3.2dm.a
> gcc -pthread   -Xlinker -export-dynamic -o python Modules/python.o
> libpython3.2dm.a -lpthread -ldl  -lutil   -lm Could not find platform
> dependent libraries <exec_prefix>
> Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
> Segmentation fault
> make: *** [sharedmods] Erreur 139

Can you retry in gdb to dump the backtrace?

Try maybe to cleanup your local copy with "make distclean".

As expected, I cannot reproduce your bug. Try to give all commands to 
reproduce the bug, and give as much information as possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri Nov 19 21:12:36 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 19 Nov 2010 20:12:36 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290197556.07.0.481784230432.issue10461@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

+1
I have not yet had occasion to use 'with' yet, but in reading the Unicode HOWTO diff, I noticed that I liked replacing 'open,read,close' with 'with open, read' just for reading purposes since it turns 3 steps into 1 compound transaction.

Perhaps something should also be added to the doc style guide (along with using 'attributes' instead of 'members').

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Fri Nov 19 21:13:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Nov 2010 20:13:10 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290197590.96.0.925240747262.issue10461@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/issue10461>
_______________________________________

From report at bugs.python.org  Fri Nov 19 21:22:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 19 Nov 2010 20:22:00 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <201011192111.05602.victor.stinner@haypocalc.com>
Message-ID: <6b2de50e04987044eb29f157f5f37f5e@netwok.org>


?ric Araujo <merwok at netwok.org> added the comment:

I will try tomorrow, thanks for reminding me.

 That was a fresh clone.

 I did.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From rrr at ronadam.com  Fri Nov 19 18:05:47 2010
From: rrr at ronadam.com (Ron Adam)
Date: Fri, 19 Nov 2010 11:05:47 -0600
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <AANLkTik2FmE4fu_eLfDR=bkzcNMmCtEkWQt7imgO9i_z@mail.gmail.com>
References: <1290065849.46.0.393272046055.issue2001@psf.upfronthosting.co.za>
	<AANLkTik2FmE4fu_eLfDR=bkzcNMmCtEkWQt7imgO9i_z@mail.gmail.com>
Message-ID: <ic6apc$597$1@dough.gmane.org>



On 11/19/2010 08:21 AM, Alexander Belopolsky wrote:
>
> Alexander Belopolsky<belopolsky at users.sourceforge.net>  added the comment:
>
> On Thu, Nov 18, 2010 at 2:37 AM, Ron Adam<report at bugs.python.org>  wrote:
> ..
>> I'll try reading and writing directly to the socket and working up some tests from that.
>> I don't suppose there's something like that already in the test suite I can copy?
>
> I believe you can find relevant code in test/test_httpservers.py.

Thanks I'll check it out.

> What I had in mind was simpler:test_pydoc already checks html output
> for a module, but this test did not fail after I applied your patch.

When I put the old server and gui() function back the existing tests passed 
with changes.  Which is good.  Also the old tests didn't actually test the 
server and the tk interface.

> There should be something in the tests that checks that the new
> navigation bar is generated correctly.

I'm going to work on this today.


From report at bugs.python.org  Fri Nov 19 21:55:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Nov 2010 20:55:04 +0000
Subject: [issue10183] test_concurrent_futures failure on Windows
In-Reply-To: <1287860051.06.0.49357269827.issue10183@psf.upfronthosting.co.za>
Message-ID: <1290200104.13.0.790610340809.issue10183@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Then I get more failures:

======================================================================
FAIL: test_map_timeout (test.test_concurrent_futures.ProcessPoolExecutorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_concurrent_futures.py", line 563, in test_
map_timeout
    timeout=10):
  File "Y:\py3k\__svn__\lib\concurrent\futures\_base.py", line 546, in map
    yield future.result(end_time - time.time())
  File "Y:\py3k\__svn__\lib\concurrent\futures\_base.py", line 400, in result
    return self.__get_result()
  File "Y:\py3k\__svn__\lib\concurrent\futures\_base.py", line 352, in __get_res
ult
    raise self._exception
AssertionError

======================================================================
FAIL: test_map_timeout (test.test_concurrent_futures.ThreadPoolExecutorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_concurrent_futures.py", line 563, in test_
map_timeout
    timeout=10):
  File "Y:\py3k\__svn__\lib\concurrent\futures\_base.py", line 546, in map
    yield future.result(end_time - time.time())
  File "Y:\py3k\__svn__\lib\concurrent\futures\_base.py", line 400, in result
    return self.__get_result()
  File "Y:\py3k\__svn__\lib\concurrent\futures\_base.py", line 352, in __get_res
ult
    raise self._exception
  File "Y:\py3k\__svn__\lib\concurrent\futures\thread.py", line 65, in run
    result = self.fn(*self.args, **self.kwargs)
  File "Y:\py3k\__svn__\lib\test\test_concurrent_futures.py", line 132, in __cal
l__
    super().__call__()
  File "Y:\py3k\__svn__\lib\test\test_concurrent_futures.py", line 107, in __cal
l__
    self._wait_on_event(self._can_finish)
  File "Y:\py3k\__svn__\lib\test\test_concurrent_futures.py", line 79, in _wait_
on_event
    assert r == 0
AssertionError

======================================================================
FAIL: test_timeout (test.test_concurrent_futures.ProcessPoolWaitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\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 0x2c73a80 state=finished raised AssertionError>

======================================================================
FAIL: test_timeout (test.test_concurrent_futures.ThreadPoolWaitTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\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 0x2c99740 state=finished raised AssertionError>

----------------------------------------------------------------------
Ran 55 tests in 64.828s

FAILED (failures=4)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10183>
_______________________________________

From report at bugs.python.org  Fri Nov 19 21:57:48 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 19 Nov 2010 20:57:48 +0000
Subject: [issue10434] Document the rules for "public names"
In-Reply-To: <1289919338.9.0.394057770971.issue10434@psf.upfronthosting.co.za>
Message-ID: <1290200268.78.0.90012799239.issue10434@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/issue10434>
_______________________________________

From report at bugs.python.org  Fri Nov 19 21:58:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 19 Nov 2010 20:58:25 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <201011192106.06983.victor.stinner@haypocalc.com>
Message-ID: <AANLkTimBUsS3VQixbG-NLHP_PrDvK7jxHZQUfmqBCvam@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 19, 2010 at 3:06 PM, STINNER Victor <report at bugs.python.org> wrote:
> .. Whereas PyUnicode_FromFormatV() converts the format string
> (bytes) to unicode (characters). If you would like a comparaison in C, it's
> like printf()+mbstowcs() in the same function.
>

I see.  So it is really the

        else
            *s++ = *f;

that surreptitiously widens the characters.

..
> I choosed to use ASCII instead of UTF-8, because an UTF-8 decoder is long (210
> lines) and complex (see PyUnicode_DecodeUTF8Stateful()), whereas ASCII decode
> is just: "unicode_char = (Py_UNICODE)byte;" + an if before to check that 0 <=
> byte <= 127).

I don't think we need 210 lines to replace "*s++ = *f" with proper
UTF-8 logic.  Even if we do, the code can be shared with
PyUnicode_DecodeUTF8 and a UTF-8 iterator may be a welcome addition to
Python C API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Fri Nov 19 22:03:11 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 19 Nov 2010 21:03:11 +0000
Subject: [issue10434] Document the rules for "public names"
In-Reply-To: <1289919338.9.0.394057770971.issue10434@psf.upfronthosting.co.za>
Message-ID: <1290200591.78.0.10116185899.issue10434@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10434>
_______________________________________

From report at bugs.python.org  Fri Nov 19 22:20:20 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 19 Nov 2010 21:20:20 +0000
Subject: [issue4113] Add custom __repr__ to functools.partial
In-Reply-To: <1223898315.71.0.950281538816.issue4113@psf.upfronthosting.co.za>
Message-ID: <1290201620.39.0.206175810431.issue4113@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

Well, of course it can be done with PyUnicode_Concat (obviously, since PyUnicode_AppendAndDel uses that). I used PyUnicode_AppendAndDel because that function does exactly what I needed.

I don't see why PyUnicode_AppendAndDel should be deprecated. Anyway, here is a new patch which uses PyUnicode_Concat.

----------
Added file: http://bugs.python.org/file19643/issue4113b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4113>
_______________________________________

From report at bugs.python.org  Fri Nov 19 22:25:37 2010
From: report at bugs.python.org (Ron Adam)
Date: Fri, 19 Nov 2010 21:25:37 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290201937.55.0.932381045833.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

I added an empty _pydoc.css file.  The server does read it and you'll be able to play around with it, but don't expect it to be pretty if you do until the rest of the html is updated.

Should I put that in the pydoc_data?

It just needs tests now, which I'll be working on as time permits over the next few days.  (And any other minor details we find.)

----------
Added file: http://bugs.python.org/file19644/issue2001_e.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Fri Nov 19 22:31:56 2010
From: report at bugs.python.org (Daniel Seither)
Date: Fri, 19 Nov 2010 21:31:56 +0000
Subject: [issue10463] Wrong return value for xml.etree.ElementTree.parse()
In-Reply-To: <1290202316.91.0.542826237315.issue10463@psf.upfronthosting.co.za>
Message-ID: <1290202316.91.0.542826237315.issue10463@psf.upfronthosting.co.za>


New submission from Daniel Seither <post at tiwoc.de>:

Cite from http://docs.python.org/library/xml.etree.elementtree.html
> xml.etree.ElementTree.parse(source, parser=None)
>
> Parses an XML section into an element tree. source is a filename or
> file object containing XML data. parser is an optional parser
> instance. If not given, the standard XMLParser parser is used.
> Returns an ElementTree instance.

The last sentence should be "Returns an Element instance."

I verified this error for the Python versions as listed in this issue. In 2.5, the information was imprecise but correct.

----------
assignee: docs at python
components: Documentation
messages: 121571
nosy: docs at python, tiwoc
priority: normal
severity: normal
status: open
title: Wrong return value for xml.etree.ElementTree.parse()
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10463>
_______________________________________

From report at bugs.python.org  Fri Nov 19 22:32:41 2010
From: report at bugs.python.org (Daniel Seither)
Date: Fri, 19 Nov 2010 21:32:41 +0000
Subject: [issue10463] Wrong return type for xml.etree.ElementTree.parse()
In-Reply-To: <1290202316.91.0.542826237315.issue10463@psf.upfronthosting.co.za>
Message-ID: <1290202361.72.0.558815925813.issue10463@psf.upfronthosting.co.za>


Changes by Daniel Seither <post at tiwoc.de>:


----------
title: Wrong return value for xml.etree.ElementTree.parse() -> Wrong return type for xml.etree.ElementTree.parse()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10463>
_______________________________________

From report at bugs.python.org  Fri Nov 19 22:41:23 2010
From: report at bugs.python.org (Daniel Seither)
Date: Fri, 19 Nov 2010 21:41:23 +0000
Subject: [issue10463] Wrong return type for xml.etree.ElementTree.parse()
In-Reply-To: <1290202316.91.0.542826237315.issue10463@psf.upfronthosting.co.za>
Message-ID: <1290202883.65.0.402221585979.issue10463@psf.upfronthosting.co.za>


Daniel Seither <post at tiwoc.de> added the comment:

I need to read more accurately what is printed on my console... Forget about it.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10463>
_______________________________________

From report at bugs.python.org  Fri Nov 19 22:43:21 2010
From: report at bugs.python.org (Doug Shea)
Date: Fri, 19 Nov 2010 21:43:21 +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: <1290203001.37.0.474762467865.issue9742@psf.upfronthosting.co.za>


Doug Shea <doug.shea at gmail.com> added the comment:

Is there perhaps a work-around we could use to get this to compile and have a math module? Force it to export that 'round' symbol in the core, perhaps?

----------
nosy: +Doug.Shea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Fri Nov 19 22:51:59 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Fri, 19 Nov 2010 21:51:59 +0000
Subject: [issue10183] test_concurrent_futures failure on Windows
In-Reply-To: <1287860051.06.0.49357269827.issue10183@psf.upfronthosting.co.za>
Message-ID: <1290203519.97.0.766614348956.issue10183@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Could you try with the patch that I just attached? And thanks for you help, I really appreciated it!

----------
Added file: http://bugs.python.org/file19645/timing2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10183>
_______________________________________

From report at bugs.python.org  Fri Nov 19 23:03:42 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Fri, 19 Nov 2010 22:03:42 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1290204222.03.0.595141831041.issue10424@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

This issue seems already fixed.

File: Lib/argparse.py
922         # if we didn't use all the Positional objects, there were too few
1923         # arg strings supplied.
1924         if positionals:
1925             self.error(_('too few arguments'))
1926 
1927         # make sure all required actions were present
1928         for action in self._actions:
1929             if action.required:
1930                 if action not in seen_actions:
1931                     name = _get_action_name(action)
1932                     self.error(_('argument %s is required') % name)

----------
nosy: +ezio.melotti, maker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Fri Nov 19 23:08:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 19 Nov 2010 22:08:48 +0000
Subject: [issue10183] test_concurrent_futures failure on Windows
In-Reply-To: <1290203519.97.0.766614348956.issue10183@psf.upfronthosting.co.za>
Message-ID: <1290204522.3621.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Could you try with the patch that I just attached? And thanks for you
> help, I really appreciated it!

It works ok indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10183>
_______________________________________

From report at bugs.python.org  Fri Nov 19 23:40:46 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 19 Nov 2010 22:40:46 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1290206446.19.0.378369427794.issue10424@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

No, it's exactly line 1925 that's the problem. The OP would like that to tell him which arguments were missing instead of saying just 'too few arguments'.

The block below that is for checking required optionals/positionals. It won't execute if the self.error above it happens.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Sat Nov 20 00:26:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 19 Nov 2010 23:26:15 +0000
Subject: [issue10459] missing character names in unicodedata (CJK...)
In-Reply-To: <1290177387.08.0.667845269575.issue10459@psf.upfronthosting.co.za>
Message-ID: <1290209175.23.0.214785976733.issue10459@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Marc-Andre: Many of the characters you refer actually do have names assigned, even if the names don't appear in the Unicode character database. Instead, they are specified in section 4.8 of the Unicode standard, and unicodedata.c already implements that (it just wasn't updated when the ranges changed; I will look into this).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10459>
_______________________________________

From report at bugs.python.org  Sat Nov 20 01:01:38 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 20 Nov 2010 00:01:38 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1290211298.26.0.0578004534764.issue10399@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> Third, for that Graphviz output, was anything special required? If so, 
> I would toss the code into Tools for others to benefit from.
It's merely the "to_dot" function from Lib/__optimizer__.py (which turns an AST into .dot source code), followed by "dot_to_png" in the same file which invokes /usr/bin/dot on it, which is likely to be readily available on any Linux system.  Would it be reasonable to add "to_dot" to Lib/ast.py? (it's ~25 lines, and very similar to that file's "dump" function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Sat Nov 20 01:07:03 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 00:07:03 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1290211623.09.0.358830290312.issue10424@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

The attached patch solves this issue.

I haven't added any unittest because test_argparse.py is quite huge - over 4300 lines-, and I was undecided between ?ArgumentError tests? (4251) and ?ArgumentTypeError tests? (4262). Any hint?
However, file bug10424.py reproduces this bug.

----------
keywords: +patch
Added file: http://bugs.python.org/file19646/issue10424.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Sat Nov 20 01:07:19 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 00:07:19 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1290211639.52.0.2103907085.issue10424@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file19647/bug10424.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Sat Nov 20 01:12:49 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 20 Nov 2010 00:12:49 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1290211969.51.0.281970289637.issue10399@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

No, it's rather Linux and tool specific to go into ast.py. But adding it to the Tools/ directory makes sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Sat Nov 20 01:15:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 20 Nov 2010 00:15:56 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <AANLkTimBUsS3VQixbG-NLHP_PrDvK7jxHZQUfmqBCvam@mail.gmail.com>
Message-ID: <201011200115.49177.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

On Friday 19 November 2010 21:58:25 you wrote:
> > I choosed to use ASCII instead of UTF-8, because an UTF-8 decoder is long
> > (210 lines) and complex (see PyUnicode_DecodeUTF8Stateful()), whereas
> > ASCII decode is just: "unicode_char = (Py_UNICODE)byte;" + an if before
> > to check that 0 <= byte <= 127).
> 
> I don't think we need 210 lines to replace "*s++ = *f" with proper
> UTF-8 logic.  Even if we do, the code can be shared with
> PyUnicode_DecodeUTF8 and a UTF-8 iterator may be a welcome addition to
> Python C API.

Why should we do that? ASCII format is just fine. Remember that 
PyUnicode_FromFormatV() is part of the C API. I don't think that anyone would 
use non-ASCII format in C. If someone does that, (s)he should open a new issue 
for that :-) But I don't think that we should make the code more complex if 
it's just useless.

Victor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Sat Nov 20 01:16:06 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Nov 2010 00:16:06 +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: <1290212166.53.0.439019518354.issue10299@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a new patch with a 5 column tables.  I had to use some rst trickery to make a decent header that works both in the HTML and Latex outputs.  I put the title in the middle cell (the 3rd) of the header and left the others empty.  The column cells are a little wider but they are still OK at 800x600.
?ric how do you like this version?  I could also drop the header altogether, but I don't like the headless table too much.

----------
Added file: http://bugs.python.org/file19648/issue10299-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Sat Nov 20 01:17:07 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 20 Nov 2010 00:17:07 +0000
Subject: [issue10459] missing character names in unicodedata (CJK...)
In-Reply-To: <1290209175.23.0.214785976733.issue10459@psf.upfronthosting.co.za>
Message-ID: <4CE7137E.6040705@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:
> 
> Marc-Andre: Many of the characters you refer actually do have names assigned, even if the names don't appear in the Unicode character database. Instead, they are specified in section 4.8 of the Unicode standard, and unicodedata.c already implements that (it just wasn't updated when the ranges changed; I will look into this).

Thanks for pointing this out. I wasn't aware of there being a standard
for constructing names for CJK ideograph ranges.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10459>
_______________________________________

From report at bugs.python.org  Sat Nov 20 01:22:04 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Nov 2010 00:22:04 +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: <1290212524.88.0.29195159121.issue9198@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9198>
_______________________________________

From report at bugs.python.org  Sat Nov 20 02:10:42 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 20 Nov 2010 01:10:42 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1290215442.72.0.648644728384.issue10399@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Sorry again for another epic-length comment...

I'm attaching the latest work-in-progress on this.

The code is still fairly messy (embarrasingly so in places), but it's better to have it out in public in this tracker than stuck on my hard drive.

Symbol tables
=============
  - I've moved the optimization pass to after symbol table generation.  Pass the symtable to mod2obj et al, adding an "ste" attribute to all objects that have their own PySTEntryObject (adding a PySymtable_TryLookup function to Python/symtable.c to help with this).  The symtable pass is rerun after optimization.
    - the "ste" attribute isn't exposed anywhere in the grammar (do other VMs implement symbol table entries?)
  - in the graphviz debug output, add boxes around scopes (i.e. those nodes with an "ste")
  - use the symbol table info: only inline functions that purely reference locals and globals, not free/cellvars.
  - only rename locals when inlining, not globals
  - don't inline functions that use the "locals" or "dir" builtin

Specialization
==============
I've implemented a first pass at the specialization ideas in the original comment.

I've added a new AST node: "Specialize".  It's an expression, but contains statements.
            -- Generated by the optimizer:
            | Specialize(expr name,
                          stmt* specialized_body,
                          expr specialized_result,
                          expr generalized) -- must be a Call

The idea is that:
  - "name" should be dynamically evaluated, then compared in some (not yet well specified) way against the expected value during inlining
  - If we have a match:
     - then execute the statements in "specialized_body", then evaluate "specialized_result", the latter giving the overall value of this expression
  - If we don't have a match:
       - then evaluate "generalized", which currently must be a Call, and this gives the overall value of the expression.

I've added  a JUMP_IF_SPECIALIZABLE opcode, mostly as described in the initial comment.

This allows us to implement "specialized" bytecode that makes an assumption, but has a fallback ("generalized") for the case when the assumption fails.

To wire this up for function inlining, we need some way of recording the "original" version of a function versus what it's now bound to.  For now, I'm simply adding an assignment after each function def, equivalent to:

   def foo():
       print('hello world')
   __saved__foo = foo

   def callsite():
       foo()

and the "Specialize" in "callsite" is compiled to:

   LOAD_GLOBAL   (foo)              ; dynamic lookup
   LOAD_GLOBAL (__saved__foo__)   ; get saved version
   JUMP_IF_SPECIALIZABLE -> inline impl
   CALL_FUNCTION 0
   POP_TOP
   JUMP_FORWARD
; inline implementation
   LOAD_GLOBAL ('print')
   LOAD_CONST ('hello world')
   CALL_FUNCTION 1
   POP_TOP
   LOAD_CONST (None)   
   RETURN_VALUE

Additional optimizations
========================
I've added:
  - a very simple copy-propagation pass, which only runs on functions with a single basic block (to keep dataflow ananalysis simple: no edges in the CFG, since we don't have an explicit CFG yet)
  - a pass which removes locals that are only ever written to, never read from, provided that the function doesn't use "globals", "locals", or "dir"

These combine nicely with the function inlining.  For example, given this code (from "test_copy_propagation")::
    def function_to_be_inlined(a, b, c, d):
        return(a + b + c + d)
    def callsite():
        print(function_to_be_inlined('fee', 'fi', 'fo', 'fum'))

then "callsite" compiles down to this bytecode::

  5           0 LOAD_GLOBAL              0 (print) 
              3 LOAD_GLOBAL              1 (function_to_be_inlined) 
              6 LOAD_GLOBAL              2 (__saved__function_to_be_inlined) 
              9 JUMP_IF_SPECIALIZABLE    30 
             12 LOAD_CONST               1 ('fee') 
             15 LOAD_CONST               2 ('fi') 
             18 LOAD_CONST               3 ('fo') 
             21 LOAD_CONST               4 ('fum') 
             24 CALL_FUNCTION            4 
             27 JUMP_FORWARD            15 (to 45) 
        >>   30 LOAD_CONST               0 (None) 
             33 STORE_FAST               0 (__inline_function_to_be_inlined_1976300____returnval__) 
             36 LOAD_CONST               7 ('feefifofum') 
             39 STORE_FAST               0 (__inline_function_to_be_inlined_1976300____returnval__) 
             42 LOAD_FAST                0 (__inline_function_to_be_inlined_1976300____returnval__) 
        >>   45 CALL_FUNCTION            1 
             48 POP_TOP              
             49 LOAD_CONST               0 (None) 
             52 RETURN_VALUE         

Note how the specialized inline implementation is able to do:
               LOAD_CONST               7 ('feefifofum') 
rather than have to compute the sum at runtime.  (the return value handling is still a little messy, alas).


Other stuff
===========
- don't try to optimize anything until the end of Py_InitializeEx, since we can't run arbitrary python code until e.g. "sys" and "codecs" etc are brought up
- don't inline for functions that have rebound names
- co_lnotab's implementation of line numbers described in Objects/lnotab_notes.txt only supports monotonically-increasing line numbers within a code object's bytecode, but with inlining, we can jump around arbitrarily within one file.  I've disabled the check for now, and line numbers sometimes come out wrong.


Correctness
===========
Just a proof-of-concept for now.  There's a "safety switch" in Lib/__optimizer__.py:is_test_code which restricts optimizations to just a few places.  I've been occasionally turning it off and runnning regrtest: many tests pass, many fail; I have fixed some failures as I see them.


Performance
===========

The optimizer is currently slow, and adds a noticable delay whey compiling a .py file.  Potentially it could be optimized.  Alternatively, we could gain a command-line flag to tell python to more heavily optimize its bytecode.  This is particularly relevant with my downstream-distributor hat on: in Fedora and RHEL we ship hundreds of Python packages (and .pyc/.pyo) via RPM, and it would be simple to turn up the optimizations when we do a build.

bm_call_simple.py gets significantly faster: a 49% speedup (albeit for a do-nothing benchmark, and this isn't counting the start-up time)::

    ### call_simple ###
    Min: 0.320839 -> 0.214237: 1.4976x faster
    Avg: 0.322125 -> 0.215405: 1.4954x faster
    Significant (t=155.641488)
    Stddev: 0.00246 -> 0.00099: 2.4894x smaller
    Timeline: b'http://tinyurl.com/2abok5l'

Other benchmarks show no change, or slight slowdowns (or crashes).  I hope that this will improve upon implementation method-call inlining.

----------
Added file: http://bugs.python.org/file19649/py3k-ast-pyoptimize-2010-11-19-006.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Sat Nov 20 02:16:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Nov 2010 01:16:03 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1290215442.72.0.648644728384.issue10399@psf.upfronthosting.co.za>
Message-ID: <1290215757.3621.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Sorry again for another epic-length comment...
> 
> I'm attaching the latest work-in-progress on this.

If this a work in progress, you could create an SVN branch in the
sandbox (you can then use svnmerge to avoid diverging too much from
mainline) or an hg repo.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Sat Nov 20 02:25:55 2010
From: report at bugs.python.org (John Keyes)
Date: Sat, 20 Nov 2010 01:25:55 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1290216355.13.0.0499896786001.issue809163@psf.upfronthosting.co.za>


John Keyes <johnkeyes at gmail.com> added the comment:

This is my first contribution as part of the Bug Weekend (and possibly my first to Python).

I tested this by writing a MANIFEST.in and a very small setup.py but after looking at distutils I narrowed the area down to the FileList.

I wrote a unittest and have attached the diff. I tested this on py3k.

----------
keywords: +patch
nosy: +johnkeyes
Added file: http://bugs.python.org/file19650/issue809163.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Sat Nov 20 02:39:05 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Nov 2010 01:39:05 +0000
Subject: [issue10391] obj2ast's error handling can lead to python crashing
	with a C-level assertion failure
In-Reply-To: <1289508823.86.0.760663346752.issue10391@psf.upfronthosting.co.za>
Message-ID: <1290217145.36.0.154286990052.issue10391@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r86538

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10391>
_______________________________________

From report at bugs.python.org  Sat Nov 20 02:43:20 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 20 Nov 2010 01:43:20 +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: <1290217400.9.0.885089995885.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101120.zip is a new version of the regex module.

The match object now supports additional methods which return information on all the successful matches of a repeated capture group.

The API was inspired by that of .Net:

    matchobject.captures([group1, ...])

        Returns a tuple of the strings matched in a group or groups. Compare with matchobject.group([group1, ...]).

    matchobject.starts([group])

        Returns a tuple of the start positions. Compare with matchobject.start([group]).

    matchobject.ends([group])

        Returns a tuple of the end positions. Compare with matchobject.end([group]).

    matchobject.spans([group])

        Returns a tuple of the spans. Compare with matchobject.span([group]).

----------
Added file: http://bugs.python.org/file19651/issue2636-20101120.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Nov 20 03:59:39 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Nov 2010 02:59:39 +0000
Subject: [issue10002] Installer doesn't install on Windows Server 2008
	DataCenter R2
In-Reply-To: <1285882629.62.0.145594356076.issue10002@psf.upfronthosting.co.za>
Message-ID: <1290221979.09.0.245166648303.issue10002@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

joblack - are you still seeing issues with this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10002>
_______________________________________

From report at bugs.python.org  Sat Nov 20 04:12:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 03:12:08 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1290222728.12.0.503411232564.issue809163@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for diagnosis and the test patch, and welcome to the bug weekend.

Some comments:

test.support has a symbol, TESTFN, which is guaranteed to be unique for the test run and located in an appropriate writeable location.  Many tests use it to create a directory via os.mkdir and then create working files in it.  The test should also clean up the directory afterward, which can be done easily using test.support.rmtree.  Using these two test support items should simplify your test.  The other advantage of using TESTFN rather than the tempfile module is that TESTFN locates the file/directory in a place that the buildbot runner cleans up after each test run, so no cruft is left on the buildbot system even if the test runs ends abnormally in the middle of the test.

----------
nosy: +r.david.murray
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Sat Nov 20 04:53:52 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Sat, 20 Nov 2010 03:53:52 +0000
Subject: [issue10437] ThreadPoolExecutor should accept max_workers=None
In-Reply-To: <1289936174.35.0.332227808259.issue10437@psf.upfronthosting.co.za>
Message-ID: <1290225232.76.0.835371047094.issue10437@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Daniel,

I wasn't trying to avoid importing multiprocessing.

What's your use case though? I think that defaulting the number of threads to the numbers of CPUs would trick users into believing that threads are useful for CPU-intensive work in Python ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10437>
_______________________________________

From report at bugs.python.org  Sat Nov 20 04:58:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 03:58:00 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1290225480.63.0.233466562242.issue10424@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There are currently no tests in argparse that test the content of error messages, which is fairly standard for stdlib tests since the error messages aren't considered part of the API (only the nature of the exception is).  So there's really no existing test class in test_argparse that would be an appropriate place to put a unit test for this.  

I would instead create a new class.  Perhaps TestErrorContent?  For this test it would probably be best to use assertRaisesRegexp and just check to make sure that the expected list of argument names appears in the message (that is, don't test the contents of the remainder of the message).  You should test several combinations.  (The argparse tests do some fancy footwork around errors, though, so you may not be able to use assertRaisesRegexp directly).

Your approach to the patch, by the way, is an interesting one, and seems to me to make sense.  But I'm not 100% sure I understand the logic of the code you are modifying, so I'll leave it to Steven to comment on that aspect of it :)

Your reference to TestArgumentError reveals a minor bug in the tests: there are actually two test classes named TestArgumentError.  Presumably the second one was indeed supposed to be TestArgumentTypeError.  I've fixed that in r86542.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Sat Nov 20 05:10:10 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Sat, 20 Nov 2010 04:10:10 +0000
Subject: [issue10183] test_concurrent_futures failure on Windows
In-Reply-To: <1287860051.06.0.49357269827.issue10183@psf.upfronthosting.co.za>
Message-ID: <1290226210.07.0.155769832037.issue10183@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Fixed in r10183

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10183>
_______________________________________

From report at bugs.python.org  Sat Nov 20 06:18:17 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Nov 2010 05:18:17 +0000
Subject: [issue8705] shutil.rmtree with empty filepath
In-Reply-To: <1273769844.52.0.734161024788.issue8705@psf.upfronthosting.co.za>
Message-ID: <1290230297.16.0.740384314211.issue8705@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This can't actually work. You can't delete a directory which has open handles to it on Windows, namely the Python process you're running in that directory.

The empty file path isn't really the issue here. shutil.rmtree(os.getcwd()) attempts the same thing but gives you a better error message since a full path gets sent down to os.rmdir rather than "".

----------
nosy: +brian.curtin
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8705>
_______________________________________

From report at bugs.python.org  Sat Nov 20 06:45:31 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 05:45:31 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1290231931.76.0.0746142215601.issue2986@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Terry, when is the deadline for producing the patch for 3.2? Perhaps we should at least submit the 2.7 patch for now so that it goes in for sure?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Sat Nov 20 10:08:30 2010
From: report at bugs.python.org (Alex)
Date: Sat, 20 Nov 2010 09:08:30 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1290244110.85.0.703948546367.issue10399@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

There are a couple places you mention not doing the optimization when specific functions are used (e.g. dir, globals, locals), how exactly do you verify that, given those functions could be bound to any name?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Sat Nov 20 10:28:40 2010
From: report at bugs.python.org (the_isz)
Date: Sat, 20 Nov 2010 09:28:40 +0000
Subject: [issue10464] netrc module not parsing passwords containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>


New submission from the_isz <the_isz at gmx.de>:

The netrc module stops parsing passwords at # characters, which can be part of
passwords.

Tested with Python 2.7 and 3.1.

----------
components: Extension Modules
messages: 121598
nosy: the_isz
priority: normal
severity: normal
status: open
title: netrc module not parsing passwords containing #s.
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10464>
_______________________________________

From report at bugs.python.org  Sat Nov 20 10:39:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Nov 2010 09:39:36 +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: <1290245976.65.0.403061705727.issue9742@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Force it to export that 'round' symbol in the core, perhaps?

Sure.  That might involve first understanding why it's not being exported.  That's where I'm a bit stuck, especially without a Solaris system to test on.  If someone can figure out why the symbol isn't being exported in the first place, that would be helpful.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Sat Nov 20 11:24:48 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 10:24:48 +0000
Subject: [issue10450] Fix markup in Misc/NEWS
In-Reply-To: <1290048675.36.0.613944727318.issue10450@psf.upfronthosting.co.za>
Message-ID: <1290248688.19.0.223961763473.issue10450@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I ran Misc/NEWS through rst2hml, and apart from unknown python-specific interpreter roles, there are two warnings:

Misc/NEWS:64: (WARNING/2) Inline strong start-string without end-string.
Misc/NEWS:128: (WARNING/2) Inline emphasis start-string without end-string.

Are these warnings what you refer to when you say there are markup errors, or is there something else?

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10450>
_______________________________________

From report at bugs.python.org  Sat Nov 20 11:29:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Nov 2010 10:29:39 +0000
Subject: [issue10450] Fix markup in Misc/NEWS
In-Reply-To: <1290048675.36.0.613944727318.issue10450@psf.upfronthosting.co.za>
Message-ID: <1290248979.69.0.198537002712.issue10450@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/issue10450>
_______________________________________

From report at bugs.python.org  Sat Nov 20 11:39:49 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 10:39:49 +0000
Subject: [issue10450] Fix markup in Misc/NEWS
In-Reply-To: <1290048675.36.0.613944727318.issue10450@psf.upfronthosting.co.za>
Message-ID: <1290249589.97.0.621900987224.issue10450@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

A fix to Misc/NEWS was committed by Georg in revision 86550. Now Misc/NEWS no longer causes warnings with `rst2html`. ?ric - if this is what you meant, the issue can be closed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10450>
_______________________________________

From report at bugs.python.org  Sat Nov 20 11:41:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 10:41:22 +0000
Subject: [issue9965] Loading malicious pickle may cause excessive memory usage
In-Reply-To: <1285632468.19.0.235987005106.issue9965@psf.upfronthosting.co.za>
Message-ID: <1290249682.13.0.083106048817.issue9965@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing as "won't fix".

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9965>
_______________________________________

From report at bugs.python.org  Sat Nov 20 11:42:58 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 10:42:58 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1290249778.5.0.146734180043.issue10439@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I will write a codecs.rst for this. Any suggestion of where in c-api/index.html it should be linked?

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10439>
_______________________________________

From report at bugs.python.org  Sat Nov 20 11:43:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Nov 2010 10:43:59 +0000
Subject: [issue10325] PY_LLONG_MAX & co - preprocessor constants or not?
In-Reply-To: <1288965372.95.0.322439917087.issue10325@psf.upfronthosting.co.za>
Message-ID: <1290249839.78.0.190205820338.issue10325@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed in r86552.  Thanks!

----------
assignee:  -> mark.dickinson
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10325>
_______________________________________

From report at bugs.python.org  Sat Nov 20 11:47:17 2010
From: report at bugs.python.org (joblack)
Date: Sat, 20 Nov 2010 10:47:17 +0000
Subject: [issue10002] Installer doesn't install on Windows Server 2008
	DataCenter R2
In-Reply-To: <1290221979.09.0.245166648303.issue10002@psf.upfronthosting.co.za>
Message-ID: <4CE7A734.2000409@gmail.com>


joblack <johannes.black at gmail.com> added the comment:

No it seems a problem of the installation routine. If you have 
installed a program before Python it sometimes doesn't work.

On 11/20/2010 03:59 AM, Brian Curtin wrote:
>
> Brian Curtin<curtin at acm.org>  added the comment:
>
> joblack - are you still seeing issues with this?
>
> ----------
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue10002>
> _______________________________________

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10002>
_______________________________________

From report at bugs.python.org  Sat Nov 20 11:51:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 10:51:11 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1290250271.57.0.768903460278.issue10439@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please call it codec.rst.  It is probably best placed under "utilities".

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10439>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:05:44 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 20 Nov 2010 11:05:44 +0000
Subject: [issue10465] gzip module calls getattr incorrectly
In-Reply-To: <1290251144.53.0.084416923691.issue10465@psf.upfronthosting.co.za>
Message-ID: <1290251144.53.0.084416923691.issue10465@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

gzip._PaddedFile.__getattr__ chains out to getattr, but does so incorrectly (found via running the numpy test suite).

The attached patch fixes this.

----------
files: gzip_getattr.diff
keywords: patch
messages: 121607
nosy: Neil Muller
priority: normal
severity: normal
status: open
title: gzip module calls getattr incorrectly
Added file: http://bugs.python.org/file19652/gzip_getattr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10465>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:06:58 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 20 Nov 2010 11:06:58 +0000
Subject: [issue10465] gzip module calls getattr incorrectly
In-Reply-To: <1290251144.53.0.084416923691.issue10465@psf.upfronthosting.co.za>
Message-ID: <1290251218.81.0.479869302332.issue10465@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

Add a test demonstrating the error.

----------
Added file: http://bugs.python.org/file19653/gzip_getattr_test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10465>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:09:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Nov 2010 11:09:38 +0000
Subject: [issue9920] test_cmath on atan fails on AIX
In-Reply-To: <1285164788.53.0.85582412597.issue9920@psf.upfronthosting.co.za>
Message-ID: <1290251378.17.0.498361721479.issue9920@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This should now be fixed in r86553.  If you have a chance to test and report back, that would be great!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9920>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:15:09 2010
From: report at bugs.python.org (Jeremy Thurgood)
Date: Sat, 20 Nov 2010 11:15:09 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>
Message-ID: <1290251709.34.0.157004882535.issue10231@psf.upfronthosting.co.za>


Jeremy Thurgood <firxen at gmail.com> added the comment:

Attached a patch to test for and fix the first two issues described in this ticket.

Basically, it modifies SimpleHTTPRequestHandler.send_head() to operate on a path already stripped of the query string and fragment rather than the completely unparsed URL.

----------
keywords: +patch
nosy: +jerith
Added file: http://bugs.python.org/file19654/issue10231.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:20:44 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 11:20:44 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>
Message-ID: <1290252044.37.0.93738966686.issue10231@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:24:36 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 20 Nov 2010 11:24:36 +0000
Subject: [issue2244] urllib and urllib2 decode userinfo multiple times
In-Reply-To: <1204819810.33.0.413464262118.issue2244@psf.upfronthosting.co.za>
Message-ID: <1290252276.43.0.925194096757.issue2244@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

back-ported to release27-maint in r86554.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2244>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:26:33 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 11:26:33 +0000
Subject: [issue10465] gzip module calls getattr incorrectly
In-Reply-To: <1290251144.53.0.084416923691.issue10465@psf.upfronthosting.co.za>
Message-ID: <1290252393.32.0.601271270681.issue10465@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the catch, fixed in r86555.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10465>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:27:10 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 11:27:10 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1290252430.44.0.112073828306.issue10439@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

While preparing a .rst document for this, I ran into a possible inaccuracy in a comment in codecs.h:

/* Lookup the error handling callback function registered under the
   name error. As a special case NULL can be passed, in which case
   the error handling callback for "strict" will be returned. */
PyAPI_FUNC(PyObject *) PyCodec_LookupError(const char *name);

----

The problem may be with the phrase "under the name error". Shouldn't it be just "under *name*"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10439>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:31:12 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 11:31:12 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1290252672.04.0.668701479911.issue10439@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, apparently the parameter was (intended to be) called "error" at some point.  Can you put the correction in your patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10439>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:34:32 2010
From: report at bugs.python.org (Simon Cross)
Date: Sat, 20 Nov 2010 11:34:32 +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: <1290252872.22.0.347836177301.issue4236@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

I'm attaching a patch to relax the check in PyModule_Create2 as suggested by the Amaury (http://bugs.python.org/issue4236#msg75409).

The patch uses "PyThreadState_Get()->interp->modules == NULL" to determine whether the import machinery has been cleaned up yet.

The test suite still appears to pass.

----------
nosy: +hodgestar
Added file: http://bugs.python.org/file19655/check-import-machinery-only.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4236>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:36:07 2010
From: report at bugs.python.org (Sibylle Koczian)
Date: Sat, 20 Nov 2010 11:36:07 +0000
Subject: [issue10466] locale.py throws exception on Windows / Non-UTF8 system
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>


New submission from Sibylle Koczian <nulla.epistola at web.de>:

Running locale.py as a module on Windows, using the Python command window, produces this output:

C:\Python31\Lib>locale.py
Locale aliasing:

Locale defaults as determined by getdefaultlocale():
------------------------------------------------------------------------
Language:  de_DE
Encoding:  cp1252

Locale settings on startup:
------------------------------------------------------------------------
LC_NUMERIC ...
   Language:  (undefined)
   Encoding:  (undefined)

LC_MONETARY ...
   Language:  (undefined)
   Encoding:  (undefined)

LC_COLLATE ...
   Language:  (undefined)
   Encoding:  (undefined)

LC_CTYPE ...
   Language:  (undefined)
   Encoding:  (undefined)

LC_TIME ...
   Language:  (undefined)
   Encoding:  (undefined)


Locale settings after calling resetlocale():
------------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python31\Lib\locale.py", line 1798, in <module>
    _print_locale()
  File "C:\Python31\Lib\locale.py", line 1761, in _print_locale
    resetlocale()
  File "C:\Python31\Lib\locale.py", line 537, in resetlocale
    _setlocale(category, _build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting

Tried with 2.7 on Windows XP, 32bit, 3.1.2 and 3.2a4 on Windows 7, 64bit. System character set in all cases cp1252 as usual for a German windows installation.

With 2.6, 2.6.5, 3.1.2 on Linux with UTF-8 system character set: no exception, expected output.

----------
components: Library (Lib)
messages: 121616
nosy: skoczian
priority: normal
severity: normal
status: open
title: locale.py throws exception on Windows / Non-UTF8 system
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:47:39 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 11:47:39 +0000
Subject: [issue10460] Misc/indent.pro does not reflect PEP 7
In-Reply-To: <1290178371.97.0.656359898425.issue10460@psf.upfronthosting.co.za>
Message-ID: <1290253659.5.0.605792923637.issue10460@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Done in r86561.  Thanks for the report!

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10460>
_______________________________________

From report at bugs.python.org  Sat Nov 20 12:53:26 2010
From: report at bugs.python.org (Sebastian Hagen)
Date: Sat, 20 Nov 2010 11:53:26 +0000
Subject: [issue10467] io.BytesIO.readinto() segfaults when used on BytesIO
	object seeked beyond end.
In-Reply-To: <1290254006.57.0.463412315578.issue10467@psf.upfronthosting.co.za>
Message-ID: <1290254006.57.0.463412315578.issue10467@psf.upfronthosting.co.za>


New submission from Sebastian Hagen <sh_pybugs at memespace.net>:

io.BytesIO().readinto() does not correctly handle the case of being called on a BytesIO object that has been seeked past the end of its data. It consequently ends up reading into unallocated memory, and (typically?) segfaulting if used in this manner. I've confirmed that this bug exists in the same fashion in 2.6, 2.7, 3.0, 3.1 and 3.2; the following demonstration code works on all of these.

Demonstration:
>>> import io; b = io.BytesIO(b'bytes'); b.seek(42); b.readinto(bytearray(1))
42
Segmentation fault

I'm attaching a simple patch against r32a3:85355 that fixes this problem.

----------
components: IO
files: bio_readinto_1.patch
keywords: patch
messages: 121618
nosy: sh
priority: normal
severity: normal
status: open
title: io.BytesIO.readinto() segfaults when used on BytesIO object seeked beyond end.
type: crash
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19656/bio_readinto_1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10467>
_______________________________________

From report at bugs.python.org  Sat Nov 20 13:06:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 12:06:02 +0000
Subject: [issue10349] Error in Module/python.c when building on OpenBSD 4.8
In-Reply-To: <1289199143.28.0.506984185363.issue10349@psf.upfronthosting.co.za>
Message-ID: <1290254762.38.0.522469619636.issue10349@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is the old issue of casting the result of malloc() -- frowned upon in C, but required in C++.  Looking at the Python sources, most uses of PyMem_Malloc seem to have the cast, so it doesn't seem wrong to add one here (where it actually can be configured to be compiled with a C++ compiler).

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10349>
_______________________________________

From report at bugs.python.org  Sat Nov 20 13:26:57 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 12:26:57 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1290256017.32.0.418638320464.issue10439@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Submitting a patch. What was touched:

1. Include/codecs.h - minor inaccuracy and inconsistency in a comment
2. Doc/c-api/codec.rst - new reST documentation file for the codecs.h C API
3. Doc/c-api/utilities.rst - for linking to codec.rst, per Georg's suggestion

----------
keywords: +patch
Added file: http://bugs.python.org/file19657/issue10439.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10439>
_______________________________________

From report at bugs.python.org  Sat Nov 20 13:31:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 12:31:21 +0000
Subject: [issue8705] shutil.rmtree with empty filepath
In-Reply-To: <1273769844.52.0.734161024788.issue8705@psf.upfronthosting.co.za>
Message-ID: <1290256281.64.0.397733857826.issue8705@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Just as an FYI, a similar situation exists on Solaris.  I had to fix one of the Python test suite tests once because it was naively trying to rmtree the CWD.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8705>
_______________________________________

From report at bugs.python.org  Sat Nov 20 13:36:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 12:36:43 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290256603.32.0.324043679299.issue10461@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

with also replaces open-try-do stuff-finally-close, the correct idiom for ensuring file handles are always closes in all VMs.

I don?t think the doc style guide is the right place, since this is a code issue.  with is advertised in http://docs.python.org/dev/tutorial/inputoutput#methods-of-file-objects and http://docs.python.org/dev/howto/doanddont#exceptions ; http://docs.python.org/dev/library/functions#open says nothing about closing, and http://docs.python.org/dev/library/io tells about the with statement without recommending it strongly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 13:37:21 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sat, 20 Nov 2010 12:37:21 +0000
Subject: [issue10464] netrc module not parsing passwords containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1290256641.97.0.164624016758.issue10464@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Included test case for the reported bug. Test fails on my machine. Also split up test_case_1 (in order to put in the new test case cleanly)

----------
keywords: +patch
nosy: +xuanji
Added file: http://bugs.python.org/file19658/issue_10464_testcase.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10464>
_______________________________________

From report at bugs.python.org  Sat Nov 20 13:38:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 12:38:37 +0000
Subject: [issue10450] Fix markup in Misc/NEWS
In-Reply-To: <1290048675.36.0.613944727318.issue10450@psf.upfronthosting.co.za>
Message-ID: <1290256717.74.0.425254722805.issue10450@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed indeed.

Dave: Please open a feature request, this is a good idea.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10450>
_______________________________________

From report at bugs.python.org  Sat Nov 20 13:38:42 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 12:38:42 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290256722.76.0.106042501884.issue10461@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric, although grepping for all such references may be tricky, could you specify the places where you did see them? I guess a few fixed places is better than none at all.

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 13:50:30 2010
From: report at bugs.python.org (John Keyes)
Date: Sat, 20 Nov 2010 12:50:30 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1290257430.03.0.943431928799.issue809163@psf.upfronthosting.co.za>


John Keyes <johnkeyes at gmail.com> added the comment:

I'll change the test to use TESTFN later today. Thanks for the feedback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Sat Nov 20 13:56:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 12:56:06 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290257766.55.0.277419500688.issue10461@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Certainly.  Here is my secret grep:
$ cd py3k/Doc
$ grep -n --color=auto -d skip -I --exclude-dir .svn --exclude-dir .hg -R open\(.*\).read *.rst c-api distutils documenting extending faq howto library reference tutorial using

List without false positives: 

faq/library.rst
library/pkgutil.rst
library/atexit.rst
library/pipes.rst
library/cmd.rst
library/logging.rst
library/difflib.rst
library/collections.rst
tutorial/interpreter.rst
tutorial/stdlib2.rst

List for open(.*).write:
faq/library.rst
library/ftplib.rst
library/atexit.rst

There is probably a better regex that would catch ?open(.*).[valid method name]?, but I hate regexes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:00:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 13:00:18 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1290258018.95.0.384590006257.issue809163@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch John.  Instead of low-level use of TESTFN, you can use distutils.tests.support.TempdirManager to create a temporary directory and write files to it in a few lines.

----------
assignee: tarek -> eric.araujo
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:02:04 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 20 Nov 2010 13:02:04 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1290258124.97.0.40455943923.issue10439@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Thanks for the patch, it looks good, I have 2 remarks though:

- "under the name name" could be replaced by "under the given name".

- "The *search_function*'s refcount is incremented by this function."
This information is not useful to the caller - she just wants to know whether she still owns the reference she had before.  Most probably here, the refcount is incremented because the object is stored in a list; the caller still owns the reference to the parameter, like most functions of the API, and there is nothing to say about refcounts here.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10439>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:08:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 13:08:03 +0000
Subject: [issue10463] Wrong return type for xml.etree.ElementTree.parse()
In-Reply-To: <1290202316.91.0.542826237315.issue10463@psf.upfronthosting.co.za>
Message-ID: <1290258483.39.0.0414349953425.issue10463@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: works for me -> invalid
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10463>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:10:19 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 13:10:19 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290258619.35.0.591943359292.issue10461@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Eric, I'm attaching a provisional fix for library/atexit.rst just to be sure this is what you mean.

----------
Added file: http://bugs.python.org/file19659/atexit.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:11:15 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 13:11:15 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290258675.09.0.346354374168.issue10461@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19660/issue10461.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:11:19 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 13:11:19 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290258679.57.0.946172295978.issue10461@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file19659/atexit.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:12:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 13:12:08 +0000
Subject: [issue10351] Add autocompletion for keys in dictionaries
In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>
Message-ID: <1290258728.4.0.555194374753.issue10351@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I will review your patch later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10351>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:14:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 13:14:24 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1290258864.06.0.638138752065.issue10424@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/issue10424>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:18:07 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 13:18:07 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1290259087.42.0.228055346179.issue10439@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Amaury,

Thanks for the review & comments.
I'm attaching a fixed patch.

----------
Added file: http://bugs.python.org/file19661/issue10439.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10439>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:18:54 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 13:18:54 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1290259134.66.0.62617541634.issue10439@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please also keep to 3-space indentation in directives.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10439>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:19:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 13:19:24 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290259164.87.0.906713215743.issue10461@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes, that?s it.  Please don?t change whitespace in your patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:21:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 13:21:24 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290259284.31.0.24234031572.issue10461@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

FWIW, this doesn't belong in the style guide; it is obvious that the docs should exhibit "best practice" Python code, and using the with statement when opening resources is certainly such a best practice now.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:22:56 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 13:22:56 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1290259376.08.0.960379047972.issue10439@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Georg,
Thanks. Submitting fixed patch with 3-space indentation in directives.

----------
Added file: http://bugs.python.org/file19662/issue10439.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10439>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:25:31 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 13:25:31 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290259531.06.0.607366879875.issue10461@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Eric, which whitespace change do you refer to. I changed to 4-spaces indentation in the code sample to conform to PEP-8. Shouldn't I have?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:27:37 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 13:27:37 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290259657.17.0.718316139109.issue10461@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Here is the patch for Docs/library/cmd.rst

----------
nosy: +SilentGhost
Added file: http://bugs.python.org/file19663/cmd.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:42:42 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 13:42:42 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290260562.24.0.904095780778.issue10461@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Here is the patch for Doc/library/difflib.rst

----------
Added file: http://bugs.python.org/file19664/difflib.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:44:27 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sat, 20 Nov 2010 13:44:27 +0000
Subject: [issue10464] netrc module not parsing passwords containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1290260667.68.0.635031007889.issue10464@psf.upfronthosting.co.za>


Changes by Xuanji Li <xuanji at gmail.com>:


Removed file: http://bugs.python.org/file19658/issue_10464_testcase.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10464>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:45:30 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 13:45:30 +0000
Subject: [issue10439] PyCodec C API is not documented in reST
In-Reply-To: <1289952536.84.0.590599988157.issue10439@psf.upfronthosting.co.za>
Message-ID: <1290260730.85.0.60155698845.issue10439@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Reviewed and applied in r86562.  Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10439>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:47:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 13:47:42 +0000
Subject: [issue10468] Document UnicodeError access functions
In-Reply-To: <1290260862.46.0.923226351306.issue10468@psf.upfronthosting.co.za>
Message-ID: <1290260862.46.0.923226351306.issue10468@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

There are a couple of functions for accessing UnicodeError subclass properties that are needed e.g. in codec error handlers.  They should be documented in exceptions.rst.

----------
assignee: docs at python
components: Documentation
messages: 121641
nosy: docs at python, georg.brandl
priority: normal
severity: normal
status: open
title: Document UnicodeError access functions

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10468>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:48:11 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 13:48:11 +0000
Subject: [issue10468] Document UnicodeError access functions
In-Reply-To: <1290260862.46.0.923226351306.issue10468@psf.upfronthosting.co.za>
Message-ID: <1290260891.04.0.349589036391.issue10468@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10468>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:49:17 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 13:49:17 +0000
Subject: [issue10468] Document UnicodeError access functions
In-Reply-To: <1290260862.46.0.923226351306.issue10468@psf.upfronthosting.co.za>
Message-ID: <1290260957.62.0.726378531959.issue10468@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

>From IRC:

  the PyUnicode*Error_Foo access functions are not documented
  they are in exceptions.c / pyerrors.h

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10468>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:54:15 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 13:54:15 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290261255.98.0.478384277061.issue10461@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I'm trying to port the example in tutorial/stdlib2.rst, but the sample in "working with binary data record layouts" fails (before my porting to 'with'...)

  struct.error: unpack requires a bytes argument of length 16

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 14:59:22 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 13:59:22 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290261562.6.0.742598122908.issue10461@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Patch for Doc/library/collections.rst

----------
Added file: http://bugs.python.org/file19665/collections.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:00:03 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sat, 20 Nov 2010 14:00:03 +0000
Subject: [issue10464] netrc module not parsing passwords containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1290261603.71.0.828913347255.issue10464@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Sorry, patch had a mistake

----------
Added file: http://bugs.python.org/file19666/issue_10231_testcase.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10464>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:00:47 2010
From: report at bugs.python.org (Mick Beaver)
Date: Sat, 20 Nov 2010 14:00:47 +0000
Subject: [issue10460] Misc/indent.pro does not reflect PEP 7
In-Reply-To: <1290253659.5.0.605792923637.issue10460@psf.upfronthosting.co.za>
Message-ID: <AANLkTinPLXNWmARh57gja3af=UuoakksbfpxAzRy59rV@mail.gmail.com>


Mick Beaver <myheartinamerica at gmail.com> added the comment:

Georg,

Thanks for looking at this. Before getting your response, I decided to
take a crack at it and came up with something different. We explicitly
disagree on:

1. You had --no-blank-lines-after-declarations, but PEP 7 says:
- Function definition style: function name in column 1, outermost
      curly braces in column 1, blank line after local variable
      declarations.

2. You had --cuddle-else, but PEP 7 has the following listing:
if (mro != NULL) {
    ...
}
else {
    ...
}

I merged our two indent.pro files. Between the two of us, we had a
number of switches that were inferred, and should probably be made
more explicit in PEP 7. Those are:
--braces-on-struct-decl-line
--comment-indentation25
--swallow-optional-blank-lines

How do you feel about the following indent.pro?:

--blank-lines-after-declarations
--blank-lines-after-procedures
--braces-after-func-def-line
--braces-on-if-line
--braces-on-struct-decl-line
--break-after-boolean-operator
--comment-indentation25
--comment-line-length79
--continue-at-parentheses
--dont-cuddle-do-while
--dont-cuddle-else
--indent-level4
--line-length79
--no-space-after-casts
--no-space-after-function-call-names
--no-space-after-parentheses
--no-tabs
--procnames-start-lines
--space-after-for
--space-after-if
--space-after-while
--swallow-optional-blank-lines
-T PyCFunction
-T PyObject

Thanks for your help,
Mick

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10460>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:05:03 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 14:05:03 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290261903.52.0.400885339301.issue10461@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching patches for library/atexit.rst and for tutorial/stdlib2.rst

----------
Added file: http://bugs.python.org/file19667/issue10461.atexit.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:05:13 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 14:05:13 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290261913.19.0.459337555512.issue10461@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Added file: http://bugs.python.org/file19668/issue10461.stdlib2.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:05:17 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 14:05:17 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290261917.63.0.581760065436.issue10461@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file19660/issue10461.1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:08:17 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 14:08:17 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290262097.86.0.545062570828.issue10461@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

SilentGhost,

Your patches look fine. I have a doubt re collections.rst, however - about the Python prompt. The same issue is in faq/library.rst and I didn't want to touch it because I thought that on the prompt personally I probably wouldn't use 'with' - why write 2 lines when you can write 1? After all, it's just playing on the prompt - I don't care about safe closing of the file, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:09:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 14:09:20 +0000
Subject: [issue10460] Misc/indent.pro does not reflect PEP 7
In-Reply-To: <1290178371.97.0.656359898425.issue10460@psf.upfronthosting.co.za>
Message-ID: <1290262160.9.0.314921968731.issue10460@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

ad 1: yes, that makes sense.

ad 2: "cuddling" and "non-cuddling" else are actually pretty evenly mixed in the source.  I didn't explicitly look at PEP 7 for this, but in that case it should get preference.

Your suggested profile looked good, applied in r86564.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10460>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:13:46 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Nov 2010 14:13:46 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1290262426.21.0.781234320084.issue9732@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Reworked as a patch, including documentation and NEWS update.

----------
keywords: +patch
Added file: http://bugs.python.org/file19669/getattr_static.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9732>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:24:42 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 14:24:42 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>


New submission from Daniel Albeseder <kotan at gmx.at>:

Using WinXP I compiled python 3.2 from the current sources using Visual C++ 2010 Express.

Running

rt -v test_socket

resulted in the attached output.

The tests testSmallReadNonBlocking and testWriteNonBlocking have errors, and an assertion fails for test_connect and test_create_connections.

----------
components: Library (Lib)
files: test_socket.log
messages: 121651
nosy: Kotan
priority: normal
severity: normal
status: open
title: test_socket fails
versions: Python 3.2
Added file: http://bugs.python.org/file19670/test_socket.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:28:47 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 14:28:47 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290263327.06.0.413175369613.issue10469@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

current revision = svn revision 86553

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:31:57 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 14:31:57 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290263517.64.0.281097116307.issue10461@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

patch for Doc/library/logging.rst

Also, note the the change of the mode from `'r'` to `'rb'`. `data_to_send` is further send through socket and therefore requires to be bytes.

I expressed my opinion in irc, but I can repeat here that I think only the most trivial code such as in Doc/library/pipes.rst isn't worth converting.

----------
Added 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  Sat Nov 20 15:32:03 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 14:32:03 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290263523.61.0.986580390433.issue10461@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

patch for Doc/library/logging.rst

Also, note the the change of the mode from `'r'` to `'rb'`. `data_to_send` is further send through socket and therefore requires to be bytes.

I expressed my opinion in irc, but I can repeat here that I think only the most trivial code such as in Doc/library/pipes.rst isn't worth converting.

----------
Added file: http://bugs.python.org/file19672/logging.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:32:17 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 14:32:17 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290263537.9.0.0931627840548.issue10461@psf.upfronthosting.co.za>


Changes by SilentGhost <michael.mischurow+bpo at gmail.com>:


Removed file: http://bugs.python.org/file19672/logging.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:33:41 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 20 Nov 2010 14:33:41 +0000
Subject: [issue10462] Handler.close is not called in subclass while
	Logger.removeHandler is called
In-Reply-To: <1290187921.16.0.743406159262.issue10462@psf.upfronthosting.co.za>
Message-ID: <1290263621.48.0.770965529656.issue10462@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The reason for this behaviour is as follows: the internal list of handlers now uses weak references, see

http://bugs.python.org/issue6615#msg95691

If there are no references to a handler, it can disappear at any time: and if it does, then it won't get closed at shutdown.

If there are references to it, then the shutdown code will close all handlers on application exit.

So: either leave references to your handlers, or close them when you're done with them, or add a __del__() which will call close() when the handler is garbage collected.

BTW removeHandler() does not call close(), and never has - these are two distinct operations.

It wouldn't be right for the logging package to automatically call close() on handlers, except at application exit - where the main reason for doing so is to flush any pending output and release any resources used by the handler.

Note that adding a __del__(self): self.close() method to MyHandler results in the close() being called [during garbage collection].

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10462>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:37:01 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Nov 2010 14:37:01 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1290263821.7.0.67832297811.issue9732@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


Removed file: http://bugs.python.org/file19669/getattr_static.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9732>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:37:27 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Nov 2010 14:37:27 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1290263847.23.0.947307731466.issue9732@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
versions: +Python 2.5 -Python 3.2
Added file: http://bugs.python.org/file19673/getattr_static.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9732>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:37:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 14:37:28 +0000
Subject: [issue10466] locale.py throws exception on Windows / Non-UTF8 system
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1290263848.43.0.227530094029.issue10466@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

unsupported locale setting is a message that comes from the C runtime, IIUC.  Does it work on windows with 2.6?

----------
nosy: +lemburg, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:42:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 14:42:25 +0000
Subject: [issue10467] io.BytesIO.readinto() segfaults when used on BytesIO
	object seeked beyond end.
In-Reply-To: <1290254006.57.0.463412315578.issue10467@psf.upfronthosting.co.za>
Message-ID: <1290264145.07.0.0865068181901.issue10467@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10467>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:44:49 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sat, 20 Nov 2010 14:44:49 +0000
Subject: [issue10464] netrc module not parsing passwords containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1290264289.26.0.363095815826.issue10464@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

The issue seems to be that when shlex (the lexer that netrc uses) sees a '#' character it thinks that the rest of the line is a comment. I am not sure what the behavior of netrc should be - should it treat '#' as beginning a comment only if its the first non-whitespace character on a line? Should shlex be changed to reflect this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10464>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:47:07 2010
From: report at bugs.python.org (Jeremy Thurgood)
Date: Sat, 20 Nov 2010 14:47:07 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290264427.08.0.0823264783687.issue1859@psf.upfronthosting.co.za>


Jeremy Thurgood <firxen at gmail.com> added the comment:

The weird behaviour is caused by newlines being treated as normal whitespace characters and not actually causing _wrap_chunks() to break the line. This means that it builds "lines" of up to 'width' characters which may contain newlines:

>>> text = '''\
... aaa aaa aaa
... bbb bbb bbb
... ccc ccc ccc
... ddd ddd ddd'''
>>> T = TextWrapper(replace_whitespace=False, width=17)    
>>> T.wrap(text)
['aaa aaa aaa\nbbb', 'bbb bbb\nccc ccc', 'ccc\nddd ddd ddd']
>>> for line in T.wrap(text): print(line)
... 
aaa aaa aaa
bbb
bbb bbb
ccc ccc
ccc
ddd ddd ddd

There's no clean way to deal with this inside _wrap_chunks() (as Greg implied), so I think we should just document the existing behaviour and recommend the splitlines() workaround.

It might be useful to add a wrap_paragraphs() convenience function that does the split/wrap/join, but I don't think that would add enough value to be worth the change.

----------
nosy: +jerith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:48:32 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 20 Nov 2010 14:48:32 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1290264512.74.0.753658387664.issue9732@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
versions: +Python 3.2 -Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9732>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:52:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Nov 2010 14:52:44 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290264764.93.0.47279350254.issue10469@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brian.curtin, loewis, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 15:59:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Nov 2010 14:59:26 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290265166.47.0.55335264519.issue10469@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The core problem seems to be that the errno module has mismatching values on your Python build (for ECONNREFUSED and EWOULDBLOCK, at least, which explains all 4 failures). On a Windows 7 VM here:

>>> errno.ECONNREFUSED
10061
>>> errno.EWOULDBLOCK
10035

----------
components: +Build
nosy: +pitrou
type:  -> behavior
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 16:08:01 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 20 Nov 2010 15:08:01 +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: <1290265681.85.0.928107611265.issue6490@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

The attached patch grabs the os.popen documentation from python 2.7, throws away the deprecation notes, and adds a pointer to subprocess.Popen for more details.

----------
keywords: +patch
nosy: +Neil Muller
Added file: http://bugs.python.org/file19674/os_popen_doc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6490>
_______________________________________

From report at bugs.python.org  Sat Nov 20 16:09:14 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Nov 2010 15:09:14 +0000
Subject: [issue9732] Addition of getattr_static for inspect module
In-Reply-To: <1283347386.83.0.146152049794.issue9732@psf.upfronthosting.co.za>
Message-ID: <1290265754.27.0.966011922969.issue9732@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 86566.

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9732>
_______________________________________

From report at bugs.python.org  Sat Nov 20 16:18:20 2010
From: report at bugs.python.org (Simon Cross)
Date: Sat, 20 Nov 2010 15:18:20 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1290266300.76.0.0357850862739.issue2986@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

I made the minor changes needed to get Eli Bendersky's patch to apply against 3.2. Diff attached.

----------
nosy: +hodgestar
Added file: http://bugs.python.org/file19675/issue2986.fix32.5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Sat Nov 20 16:21:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Nov 2010 15:21:15 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290266475.96.0.413194917379.issue10469@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 16:24:06 2010
From: report at bugs.python.org (Jeremy Thurgood)
Date: Sat, 20 Nov 2010 15:24:06 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290266646.19.0.192389543455.issue1859@psf.upfronthosting.co.za>


Jeremy Thurgood <firxen at gmail.com> added the comment:

Here's a doc patch for py3k. A similar patch for 2.7 (and other versions?) might be a good idea.

----------
keywords: +patch
Added file: http://bugs.python.org/file19676/issue1859_docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sat Nov 20 16:28:09 2010
From: report at bugs.python.org (Graham Poulter)
Date: Sat, 20 Nov 2010 15:28:09 +0000
Subject: [issue1574217] isinstance swallows exceptions
Message-ID: <1290266889.92.0.0506973177934.issue1574217@psf.upfronthosting.co.za>


Graham Poulter <graham.poulter at gmail.com> added the comment:

issue1574217.diff still applies against py3k as revision 86545  (offset -8 lines)

patching file Objects/abstract.c
Hunk #1 succeeded at 2500 (offset -8 lines).
Hunk #2 succeeded at 2523 (offset -8 lines).

And tests pass (./python ./Lib/test/test_isinstance.py)

----------
nosy: +greppo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1574217>
_______________________________________

From report at bugs.python.org  Sat Nov 20 16:31:18 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Nov 2010 15:31:18 +0000
Subject: [issue9424] Disable unittest.TestCase.assertEquals and assert_ during
	a regrtest run
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1290267078.26.0.447456088152.issue9424@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The attached patch addresses the point 1) of msg113147.

----------
keywords: +patch
Added file: http://bugs.python.org/file19677/issue9424.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9424>
_______________________________________

From report at bugs.python.org  Sat Nov 20 16:32:13 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 20 Nov 2010 15:32:13 +0000
Subject: [issue5412] extend configparser to support mapping access(__*item__)
In-Reply-To: <1236093276.38.0.814047349626.issue5412@psf.upfronthosting.co.za>
Message-ID: <1290267133.75.0.961566048451.issue5412@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________

From report at bugs.python.org  Sat Nov 20 16:35:10 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Nov 2010 15:35:10 +0000
Subject: [issue10326] Can't pickle unittest.TestCase instances
In-Reply-To: <1288966649.03.0.6620170389.issue10326@psf.upfronthosting.co.za>
Message-ID: <1290267310.84.0.156255341597.issue10326@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Applied to Python 3.2 in revision 86570.

Python 2.7 will have to be fixed after the next release as we are currently in release candidate stage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10326>
_______________________________________

From report at bugs.python.org  Sat Nov 20 16:48:01 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 20 Nov 2010 15:48:01 +0000
Subject: [issue9637] docs do not say that urllib uses HTTP_PROXY
In-Reply-To: <1282196669.74.0.629180904202.issue9637@psf.upfronthosting.co.za>
Message-ID: <1290268081.05.0.574552851772.issue9637@psf.upfronthosting.co.za>


Changes by Neil Muller <drnlmuller+bugs at gmail.com>:


----------
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9637>
_______________________________________

From report at bugs.python.org  Sat Nov 20 16:50:48 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Nov 2010 15:50:48 +0000
Subject: [issue10027] os.lstat/os.stat don't set st_nlink on Windows
In-Reply-To: <1286289327.29.0.159315245099.issue10027@psf.upfronthosting.co.za>
Message-ID: <1290268248.24.0.0115207075596.issue10027@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm not sure how that would work in terms of redistributing, and how we'd handle it within our own build process. This close to the beta I'm -1 on adding that API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:03:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 16:03:35 +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: <1290269015.54.0.297609081141.issue5871@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords:  -easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5871>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:14:19 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 20 Nov 2010 16:14:19 +0000
Subject: [issue9637] docs do not say that urllib uses HTTP_PROXY
In-Reply-To: <1282196669.74.0.629180904202.issue9637@psf.upfronthosting.co.za>
Message-ID: <1290269659.4.0.253188321346.issue9637@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

The problem is that the getproxies_environment function converts all environment variables to lower case before deciding whether to use the name. This means that whichever ends up last in os.environment will be used.

The attached patch does two things. It changes the behaviour to prefer the all lower case version if it exists, and adds a note to the ProxyHandler description noting that the environment variable used is not case sensitive, although the all lower case version will be preferred.

The behaviour change is debatable, but preferring the lower case name is likely to be less surprising in general.

----------
keywords: +patch
nosy: +Neil Muller
Added file: http://bugs.python.org/file19678/urllib_PROXY.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9637>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:15:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Nov 2010 16:15:10 +0000
Subject: [issue9424] Disable unittest.TestCase.assertEquals and assert_ during
	a regrtest run
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1290269710.34.0.96991935578.issue9424@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I uploaded the patch on http://codereview.appspot.com/3232042 too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9424>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:23:00 2010
From: report at bugs.python.org (Simon Cross)
Date: Sat, 20 Nov 2010 16:23:00 +0000
Subject: [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1290270180.65.0.0738249705773.issue8647@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

This issue is subsumed by #10435 and can probably be closed as a duplicated.

----------
nosy: +hodgestar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8647>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:23:30 2010
From: report at bugs.python.org (Simon Cross)
Date: Sat, 20 Nov 2010 16:23:30 +0000
Subject: [issue8646] PyUnicode_EncodeDecimal is undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1290270210.22.0.887554117914.issue8646@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

This issue is subsumed by #10435 and can probably be closed as a duplicated.

----------
nosy: +hodgestar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8646>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:23:46 2010
From: report at bugs.python.org (Simon Cross)
Date: Sat, 20 Nov 2010 16:23:46 +0000
Subject: [issue8645] PyUnicode_AsEncodedObject is undocumented
In-Reply-To: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>
Message-ID: <1290270226.79.0.107506334467.issue8645@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

This issue is subsumed by #10435 and can probably be closed as a duplicated.

----------
nosy: +hodgestar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8645>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:23:57 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 16:23:57 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290270237.68.0.474895417151.issue10453@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

I'm still working on this task; the attachment shows how I'm solving the bug. 
The patch is NOT yet completed, there are some problems with the unittests. Hoping that Eric will give me a help soon.

----------
keywords: +patch
nosy: +ezio.melotti, maker
Added file: http://bugs.python.org/file19679/issue10453.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:25:41 2010
From: report at bugs.python.org (Simon Cross)
Date: Sat, 20 Nov 2010 16:25:41 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1289924206.67.0.561264270455.issue10435@psf.upfronthosting.co.za>
Message-ID: <1290270341.49.0.684747863297.issue10435@psf.upfronthosting.co.za>


Changes by Simon Cross <hodgestar at gmail.com>:


----------
nosy: +hodgestar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:28:25 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 20 Nov 2010 16:28:25 +0000
Subject: [issue1486713] HTMLParser : A auto-tolerant parsing mode
Message-ID: <1290270505.48.0.662894423857.issue1486713@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

#975556 and #1046092 look like they should also be superseded by this.

----------
nosy: +Neil Muller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1486713>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:29:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 20 Nov 2010 16:29:55 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>
Message-ID: <1290270595.85.0.575802390463.issue10231@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I have doubts on the validity of this bug itself.

- First is, query and fragment are usually for the file being served from the webserver, not on the directories. If there are characters such as '?' and '#'  in the directory names, which may get featured in the path, then those should be quoted in the request. So foo/dir?baz is wrong where as foo/dir%3Fbaz it the correct request.

We see the 301 redirection code in http.server code, the for the cases wherein it the "directory" is not specified with '/'. It just adds the '/' to get to the path. The code explicitly checks that path is directory before doing '/' added 301 redirection.

In the patch's first case:

+        response = self.request(self.tempdir_name + '?foo')

This is wrong because /tmp/somthing?foo (Is invalid path - It should be quoted for it be a PATH and follow the 301 redirection to list its contents by appending '/')

To verify the above points, just create a file foo?bar and directory foo?baz and serve those using http.server, you come to know that the interpretation by the OP does not come up here.

If you any counter arguments to the above, please provide good examples or a better yet, the test_httpservers patch.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:30:57 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 20 Nov 2010 16:30:57 +0000
Subject: [issue975556] HTMLParser lukewarm on bogus bare attribute chars
Message-ID: <1290270657.91.0.668512276484.issue975556@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

This should probably be solved as part of #1486713 .

----------
nosy: +Neil Muller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue975556>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:31:02 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 20 Nov 2010 16:31:02 +0000
Subject: [issue1046092] HTMLParser fix to accept mailformed tag attributes
Message-ID: <1290270662.0.0.4557713272.issue1046092@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

I think this change is makes the parser far too lenient. Something like the explicit tolerant mode proposed in #1486713 is a better solution.

----------
nosy: +Neil Muller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1046092>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:32:06 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 16:32:06 +0000
Subject: [issue4925] Improve error message of subprocess when cannot open
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1290270726.78.0.556602120094.issue4925@psf.upfronthosting.co.za>


endian <andrew at andrewschaaf.com> added the comment:

I'm working this for platforms that use OSError. #pythonbugday2010 #myfirstpatch

----------
nosy: +endian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:40:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 16:40:22 +0000
Subject: [issue1574217] isinstance swallows exceptions
Message-ID: <1290271222.84.0.502030792084.issue1574217@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've committed this (with the whitespace fix) in r86577.  I've made myself a note to backport it when the maint branches unfreeze.

----------
assignee: nnorwitz -> 
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/issue1574217>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:40:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 16:40:40 +0000
Subject: [issue1574217] isinstance swallows exceptions
Message-ID: <1290271240.92.0.443060661364.issue1574217@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/issue1574217>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:41:53 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 16:41:53 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290271313.96.0.866648209299.issue10453@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Removed file: http://bugs.python.org/file19679/issue10453.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:42:36 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 16:42:36 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290271356.13.0.200050527769.issue5800@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Correct and update patch + update test case

----------
keywords: +patch
nosy: +SilentGhost
Added file: http://bugs.python.org/file19680/headers.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:43:06 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 16:43:06 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290271386.45.0.257061296684.issue5800@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

here is the updated test case

----------
Added file: http://bugs.python.org/file19681/test_wsgiref.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:43:07 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 16:43:07 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290271387.53.0.12753135497.issue10453@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

The new attached patch passes the unittest.

----------
Added file: http://bugs.python.org/file19682/issue10453.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:43:23 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 16:43:23 +0000
Subject: [issue4925] Improve error message of subprocess when cannot open
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1290271403.68.0.0641518540695.issue4925@psf.upfronthosting.co.za>


Changes by endian <andrew at andrewschaaf.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19683/issue4925.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:51:58 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 16:51:58 +0000
Subject: [issue4925] Improve error message of subprocess when cannot open
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1290271918.3.0.0931154142531.issue4925@psf.upfronthosting.co.za>


Changes by endian <andrew at andrewschaaf.com>:


Removed file: http://bugs.python.org/file19683/issue4925.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:55:33 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 16:55:33 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290272133.94.0.654125295339.issue10453@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Removed file: http://bugs.python.org/file19682/issue10453.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 17:55:49 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 16:55:49 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290272149.58.0.894324352998.issue10453@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file19684/issue10453.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:02:39 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 17:02:39 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290272559.56.0.314093458851.issue10453@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

I did a very simple addition to the CommandLineTest, to check that "-h" really returns the "usage:". I am not sure, if this is useful since, it rather tests argparse now with the proposed patch...

----------
nosy: +Kotan
Added file: http://bugs.python.org/file19685/test_compileall.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:06:04 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 17:06:04 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290272764.83.0.10003421533.issue10453@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Eric, the unittests in Lib/test/test_compileall.py seems quite consistent to me, so for now I won't add anything.
About adding a method for testing the '-h' argument, now that Lib/compileall.py uses argparse, it sounds trivial.

EDIT: Kotan, I'm still of the same opinion. Anyway, I  think you should use as template test.test_compileall.CommandLineTests.test_legacy_paths: so, check for returncode and use subprocess.call instead of subprocess.Popen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:09:32 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 20 Nov 2010 17:09:32 +0000
Subject: [issue10377] cProfile incorrectly labels its output
In-Reply-To: <1289330157.64.0.804847448743.issue10377@psf.upfronthosting.co.za>
Message-ID: <1290272972.94.0.896738120766.issue10377@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r86580 (py3k), r86581 and r86582.

----------
components: +Library (Lib)
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10377>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:11:42 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 17:11:42 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290273102.58.0.376517448561.issue10453@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

I wanted to test, that no unwanted output is given before the usage. I just added the test before I started to try to fix this bug, as I recognized Michele already was already fixing the bug. This was just my test-driven approach, where the unit test failed before the fix, and should pass afterwards. As the unwanted output was the main reason for the issue, I just did put this into the test. However I agree that the test at all is silly, and I fully agree if it is not used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:13:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 17:13:24 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290273204.85.0.494590340654.issue5800@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
keywords:  -patch
stage: unit test needed -> patch review
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:24:28 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Nov 2010 17:24:28 +0000
Subject: [issue10467] io.BytesIO.readinto() segfaults when used on BytesIO
	object seeked beyond end.
In-Reply-To: <1290254006.57.0.463412315578.issue10467@psf.upfronthosting.co.za>
Message-ID: <1290273868.63.0.793714839917.issue10467@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r86587

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10467>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:25:58 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 17:25:58 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290273958.13.0.787203681926.issue10469@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

As this was requested on IRC, I put the Visual C++ 2010 Express solution and project files here as well. The patch "pcbuild_vs2010.patch" should be applied to the PCbuild directory.

----------
keywords: +patch
Added file: http://bugs.python.org/file19686/pcbuild_vs2010.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:26:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 17:26:36 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290273996.67.0.258468046574.issue10453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

On the other hand, the test case in test_compileall says "test some aspects of compileall's CLI".  Since the patch completely changes the logic of CLI parsing, having tests that cover as much as practical of the CLI would greatly increase the confidence that the patch is correct.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:29:03 2010
From: report at bugs.python.org (Ramiro Batista da Luz)
Date: Sat, 20 Nov 2010 17:29:03 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290274143.84.0.704702781304.issue5800@psf.upfronthosting.co.za>


Ramiro Batista da Luz <ramiroluz at gmail.com> added the comment:

I applied the patches for wsgiref.headers and test_headers.py, ran the test with runtests.sh test_headers.py and it passed.

I also tried the code in the description: 

>>> from wsgiref.headers import Headers
>>> headers = Headers()
>>> headers.add_header('Content-Type', 'text/plain')
>>>

----------
nosy: +ramiroluz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:29:52 2010
From: report at bugs.python.org (5houston)
Date: Sat, 20 Nov 2010 17:29:52 +0000
Subject: [issue8028] self.terminate() from a multiprocessing.Process raises
	AttributeError exception
In-Reply-To: <1267300713.42.0.457825051385.issue8028@psf.upfronthosting.co.za>
Message-ID: <1290274192.82.0.194849220352.issue8028@psf.upfronthosting.co.za>


5houston <cadabras at gmail.com> added the comment:

Yes, I can.
This is the minCrashing.py output from python3.2a4 in windows XP sp3:

Traceback (most recent call last):
  File "c:\Python32\lib\multiprocessing\process.py", line 233, in _bootstrap
    self.run()
  File "c:\Python32\lib\multiprocessing\process.py", line 87, in run
    if self._target:
AttributeError: 'Process' object has no attribute '_target'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "c:\Python32\lib\multiprocessing\forking.py", line 349, in main
    exitcode = self._bootstrap()
  File "c:\Python32\lib\multiprocessing\process.py", line 249, in _bootstrap
    sys.stderr.write('Process %s:\n' % self.name)
  File "c:\Python32\lib\multiprocessing\process.py", line 137, in name
    return self._name
AttributeError: 'Process' object has no attribute '_name'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8028>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:35:37 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Nov 2010 17:35:37 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290274537.59.0.237914189423.issue10469@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Daniel: If you need VS2008, you can get it here: http://www.microsoft.com/express/Downloads/#2008-Visual-CPP

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:35:37 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sat, 20 Nov 2010 17:35:37 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1290274537.84.0.877138106872.issue9305@psf.upfronthosting.co.za>


Changes by Rodrigo Bernardo Pimentel <rbp at isnomore.net>:


----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:37:27 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 17:37:27 +0000
Subject: [issue4925] Improve error message of subprocess when cannot open
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1290274647.26.0.513124355334.issue4925@psf.upfronthosting.co.za>


Changes by endian <andrew at andrewschaaf.com>:


Added file: http://bugs.python.org/file19687/issue4925.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:38:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 17:38:46 +0000
Subject: [issue9769] PyUnicode_FromFormatV() doesn't handle non-ascii text
	correctly
In-Reply-To: <201011200115.49177.victor.stinner@haypocalc.com>
Message-ID: <AANLkTin_gy-Axny8BOjUtKmmutcDJ0xpqYy58CJhDH0t@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 19, 2010 at 7:15 PM, STINNER Victor <report at bugs.python.org> wrote:
..
>
> Why should we do that? ASCII format is just fine. Remember that
> PyUnicode_FromFormatV() is part of the C API. I don't think that anyone would
> use non-ASCII format in C.

Why not.  Gettext manual is full of examples with i18nalized format strings.

> If someone does that, (s)he should open a new issue
> for that :-)

Why new issue?  The title of this issue fits perfectly and IMO it is
hard to argue that to "handle non-ascii text correctly" means to raise
an error when non-ascii text is encountered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9769>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:43:34 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 20 Nov 2010 17:43:34 +0000
Subject: [issue10319] SocketServer.TCPServer truncates responses on close (in
	some situations)
In-Reply-To: <1288935519.72.0.951711716225.issue10319@psf.upfronthosting.co.za>
Message-ID: <1290275014.08.0.456116733107.issue10319@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

BaseHTTPServer documentation explains that "Usually, this module isn?t used directly, but is used as a basis for building functioning Web servers". Methods are usually subclassed with desirable behaviors customized.

If you are using SocketServer in your code directly and calling close_request (where you want all your requests to be drained on closing), I think, you should just use shutdown_request. 

This bug can be closed.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10319>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:46:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 17:46:30 +0000
Subject: [issue665194] datetime-RFC2822 roundtripping
Message-ID: <1290275190.28.0.579059901383.issue665194@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/issue665194>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:52:58 2010
From: report at bugs.python.org (Priscila Manhaes)
Date: Sat, 20 Nov 2010 17:52:58 +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: <1290275578.28.0.920684648732.issue10367@psf.upfronthosting.co.za>


Priscila Manhaes <pmnhaes at gmail.com> added the comment:

Well, I fixed the problem moving the "if" that instances "result" even though it getting HTTPError into the "try".

------------------------------------------------------
        # send the data
        try:
            result = urlopen(request)
            status = result.getcode()
            reason = result.msg
            if self.show_response:
                self.announce('-'*75, result.read(), '-'*75)
        except socket.error, e:
            self.announce(str(e), log.ERROR)
            return
        except HTTPError, e:
            status = e.code
            reason = e.msg

        if status == 200:
            self.announce('Server response (%s): %s' % (status, reason),
                          log.INFO)
        else:
            self.announce('Upload failed (%s): %s' % (status, reason),
                          log.ERROR)

-------------------------------------------------

So now it explains the real error:

###
python setup.py sdist upload
running sdist
running check
warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list)

writing manifest file 'MANIFEST'
creating Python-2.7
creating Python-2.7/Lib
creating Python-2.7/Tools
creating Python-2.7/Tools/scripts
making hard links in Python-2.7...
hard linking README -> Python-2.7
'_struct.c' not a regular file -- skipping
hard linking setup.py -> Python-2.7
hard linking Lib/smtpd.py -> Python-2.7/Lib
hard linking Tools/scripts/2to3 -> Python-2.7/Tools/scripts
hard linking Tools/scripts/idle -> Python-2.7/Tools/scripts
hard linking Tools/scripts/pydoc -> Python-2.7/Tools/scripts
Creating tar archive
removing 'Python-2.7' (and everything under it)
running upload
Submitting dist/Python-2.7.tar.gz to http://pypi.python.org/pypi
Upload failed (401): Unauthorized

###


Is this ok?

----------
nosy: +Priscila.Manhaes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:54:27 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 20 Nov 2010 17:54:27 +0000
Subject: [issue1520831] urrlib2 max_redirections=0 disables redirects
Message-ID: <1290275667.9.0.279260329591.issue1520831@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

What should it do? OP expected that it print the redirected url. I don't think that's helpful by setting max_redirections to 0, when it can be achieved in other ways. 

Also, max_redirections is not exposed (as a parameter or arg) or a documented, how do we define user's expectation when he tries to change it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1520831>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:55:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 20 Nov 2010 17:55:28 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1290275728.61.0.611171376439.issue2986@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Deadline is probably next Fri. However I will apply this or slight revision thereof in a couple of days to make sure this much is in. I have to fixup some work stuff today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:55:40 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 20 Nov 2010 17:55:40 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

"python -m unittest" does nothing useful (runs 0 tests). It would be good to have it default to discovery, which removes the useless behaviour *and* makes the default invocation for test discovery shorter.

----------
assignee: michael.foord
components: Library (Lib)
messages: 121698
nosy: michael.foord
priority: normal
severity: normal
status: open
title: python -m unittest ought to default to discovery
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sat Nov 20 18:57:49 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 17:57:49 +0000
Subject: [issue4925] Improve error message of subprocess when cannot open
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1290275869.43.0.53278789914.issue4925@psf.upfronthosting.co.za>


Changes by endian <andrew at andrewschaaf.com>:


Added file: http://bugs.python.org/file19688/issue4925.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:00:21 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 18:00:21 +0000
Subject: [issue4925] Improve error message of subprocess when cannot open
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1290276021.9.0.0777107454302.issue4925@psf.upfronthosting.co.za>


Changes by endian <andrew at andrewschaaf.com>:


Removed file: http://bugs.python.org/file19687/issue4925.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:05:05 2010
From: report at bugs.python.org (Hugo Shi)
Date: Sat, 20 Nov 2010 18:05:05 +0000
Subject: [issue7506] multiprocessing.managers.BaseManager.__reduce__
	references BaseManager.from_address
In-Reply-To: <1260816536.82.0.305544247154.issue7506@psf.upfronthosting.co.za>
Message-ID: <1290276305.76.0.798618196149.issue7506@psf.upfronthosting.co.za>


Hugo Shi <hugo.r.shi at gmail.com> added the comment:

Does BaseManager need to be pickleable?  It looks like it contains an AuthenticationKey which should NOT be pickled for security reasons.  All the unit tests pass if we remove the __reduce__ method.  Is that the fix?

----------
nosy: +Hugo.Shi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7506>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:05:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Nov 2010 18:05:36 +0000
Subject: [issue7506] multiprocessing.managers.BaseManager.__reduce__
	references BaseManager.from_address
In-Reply-To: <1260816536.82.0.305544247154.issue7506@psf.upfronthosting.co.za>
Message-ID: <1290276336.61.0.14283963656.issue7506@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7506>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:08:25 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Nov 2010 18:08:25 +0000
Subject: [issue4925] Improve error message of subprocess when cannot open
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1290276505.27.0.878319527102.issue4925@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r86593

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:15:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 18:15:54 +0000
Subject: [issue4925] Improve error message of subprocess when cannot open
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1290276954.09.0.8194958515.issue4925@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that Benjamin's commit only addresses the posix side.  Amaury, do you want to fix the windows side?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4925>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:19:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 20 Nov 2010 18:19:11 +0000
Subject: [issue7506] multiprocessing.managers.BaseManager.__reduce__
	references BaseManager.from_address
In-Reply-To: <1260816536.82.0.305544247154.issue7506@psf.upfronthosting.co.za>
Message-ID: <1290277151.62.0.976670781478.issue7506@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Questions:

(1) Did you run the unittests on Windows?  I think there are stronger requirements for pickleability there.

(2) What specific security issues do you anticipate from pickling the authentication key?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7506>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:21:34 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Nov 2010 18:21:34 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290277294.88.0.00322272883677.issue10461@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Do not change the examples in collections.rst.
That would interfere with the clarify of what
is being demonstrated.  For example, the hamlet.txt
example is not about file reading, it about 
counting words.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:21:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 18:21:53 +0000
Subject: [issue10371] Deprecate trace module undocumented API
In-Reply-To: <1289269952.54.0.146506315747.issue10371@psf.upfronthosting.co.za>
Message-ID: <1290277313.29.0.879903242108.issue10371@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 86594.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10371>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:23:43 2010
From: report at bugs.python.org (Hugo Shi)
Date: Sat, 20 Nov 2010 18:23:43 +0000
Subject: [issue7506] multiprocessing.managers.BaseManager.__reduce__
	references BaseManager.from_address
In-Reply-To: <1260816536.82.0.305544247154.issue7506@psf.upfronthosting.co.za>
Message-ID: <1290277423.35.0.917744787994.issue7506@psf.upfronthosting.co.za>


Hugo Shi <hugo.r.shi at gmail.com> added the comment:

I didn't run the unittests in windows, But I don't have the capability to do so at the moment.  I maybe able to do this on monday

I don't know why AuthenticationKey has security issues with being pickled, however in process.py


#                                                                                                                                                                                                 
# We subclass bytes to avoid accidental transmission of auth keys over network                                                                                                                    
#                                                                                                                                                                                                 

class AuthenticationString(bytes):
    def __reduce__(self):
        from .forking import Popen
        if not Popen.thread_is_spawning():
            raise TypeError(
                'Pickling an AuthenticationString object is '
                'disallowed for security reasons'
                )
        return AuthenticationString, (bytes(self),)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7506>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:24:48 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 18:24:48 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290277488.59.0.12879881738.issue10461@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

None of the changes are about file reading, they only about using with statement throughout. May be nofix then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:26:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Nov 2010 18:26:52 +0000
Subject: [issue8569] Upgrade OpenSSL in Windows builds
In-Reply-To: <1272545315.42.0.523139730845.issue8569@psf.upfronthosting.co.za>
Message-ID: <1290277612.47.0.687283612412.issue8569@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Closing - OpenSSL was upgraded to version 1.0.0a a few months ago.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8569>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:27:01 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Nov 2010 18:27:01 +0000
Subject: [issue8569] Upgrade OpenSSL in Windows builds
In-Reply-To: <1272545315.42.0.523139730845.issue8569@psf.upfronthosting.co.za>
Message-ID: <1290277621.89.0.892434076387.issue8569@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8569>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:28:55 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Nov 2010 18:28:55 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290277735.94.0.0725758204787.issue10461@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I think the other (non collections patches) are fine.  The change doesn't break up the flow of the text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:29:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 20 Nov 2010 18:29:36 +0000
Subject: [issue4925] Improve error message of subprocess when cannot open
In-Reply-To: <1231777617.86.0.584511455662.issue4925@psf.upfronthosting.co.za>
Message-ID: <1290277776.05.0.00296700235283.issue4925@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/issue4925>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:30:52 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 20 Nov 2010 18:30:52 +0000
Subject: [issue10437] ThreadPoolExecutor should accept max_workers=None
In-Reply-To: <1289936174.35.0.332227808259.issue10437@psf.upfronthosting.co.za>
Message-ID: <1290277852.22.0.0224314626775.issue10437@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

In my case, each thread launches a CPU-intensive process via subprocess, then waits for it to report output and exit.

Also, keep in mind that PyPy and IronPython don't have a GIL (although I'm not a PyPy or IronPython user myself).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10437>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:31:24 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Nov 2010 18:31:24 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290277884.12.0.467767907473.issue10461@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Separate note for ?ric:  the try/finally examples do not need to change.  Those are valid python.   Users need to learn both try/finally and the with-statement.

----------
assignee: docs at python -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:32:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 18:32:03 +0000
Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1290277923.91.0.334975172696.issue5066@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> docs at python
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5066>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:32:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 18:32:27 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290277735.94.0.0725758204787.issue10461@psf.upfronthosting.co.za>
Message-ID: <AANLkTimccSRB=BLCpARAF3F12kStB=Q5YCTFmYJxvk-3@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

FWIW, I find the "with" variant much easier to read than

>>> words = re.findall('\w+', open('hamlet.txt').read().lower())

Too many operations in one line.  It would be even better with

>>> words = re.findall('\w+', hamlet_text.lower())

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:43:05 2010
From: report at bugs.python.org (Abhay Saxena)
Date: Sat, 20 Nov 2010 18:43:05 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1290278585.02.0.342281204901.issue9969@psf.upfronthosting.co.za>


Abhay Saxena <ark3 at email.com> added the comment:

If the goal is tokenize(...) accepting a text I/O readline, we already have the (undocumented) generate_tokens(readline).

----------
nosy: +ark3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9969>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:43:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 18:43:14 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290278594.63.0.776837489103.issue10461@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg121711

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:44:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 18:44:36 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290278676.84.0.830272243474.issue10461@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Eli, SilentGhost: Please open other bug reports for doc errors like the struct one in stdlib2 or the r/rb one.

SilentGhost: with statement used with open *is* about file reading :)

Raymond: I agree about try/finally.  I agree with Alexander about collections.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:46:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 18:46:41 +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: <1290278801.98.0.702966590848.issue10367@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the fix Priscila.  Can you submit it as a diff file?  (guidelines on http://www.python.org/dev/patches/)

Tarek: I wonder if we should backport pydoc_server from d2 to test behavior bugs like this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:47:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 18:47:57 +0000
Subject: [issue9199] distutils upload command crashes when displaying server
	response
In-Reply-To: <1278596334.3.0.531936724428.issue9199@psf.upfronthosting.co.za>
Message-ID: <1290278877.91.0.214924632549.issue9199@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for correcting me!

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9199>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:48:28 2010
From: report at bugs.python.org (Jim Pharis)
Date: Sat, 20 Nov 2010 18:48:28 +0000
Subject: [issue9435] test_distutils fails without zlib
In-Reply-To: <1280590585.97.0.266735291444.issue9435@psf.upfronthosting.co.za>
Message-ID: <1290278908.29.0.902725705013.issue9435@psf.upfronthosting.co.za>


Jim Pharis <binbrain at gmail.com> added the comment:

I think this is a dup of #6026 which is fixed...

svn log for Lib/distutils...

#6026: skip test_get_file_list when zlib is not available.
  this test requires zlib support
  #6026 - fix tests that failed without zlib

----------
nosy: +binbrain

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9435>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:52:14 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 18:52:14 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290279134.01.0.91091194372.issue3709@psf.upfronthosting.co.za>


endian <andrew at andrewschaaf.com> added the comment:

How about this patch?

----------
keywords: +patch
nosy: +endian
Added file: http://bugs.python.org/file19689/issue3709.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:53:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 18:53:51 +0000
Subject: [issue1646068] Dict lookups fail if sizeof(Py_ssize_t) < sizeof(long)
Message-ID: <1290279231.23.0.395131842289.issue1646068@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/issue1646068>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:55:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 18:55:25 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290279325.89.0.470977318556.issue3709@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sat Nov 20 19:58:55 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 20 Nov 2010 18:58:55 +0000
Subject: [issue10437] ThreadPoolExecutor should accept max_workers=None
In-Reply-To: <1289936174.35.0.332227808259.issue10437@psf.upfronthosting.co.za>
Message-ID: <1290279535.24.0.437389674703.issue10437@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

pypy does have a GIL!

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10437>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:01:24 2010
From: report at bugs.python.org (Priscila Manhaes)
Date: Sat, 20 Nov 2010 19:01: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: <1290279684.33.0.463529565578.issue10367@psf.upfronthosting.co.za>


Changes by Priscila Manhaes <pmnhaes at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19690/10367.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:04:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 19:04:17 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290279857.16.0.381799076859.issue3709@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It looks good, but as mentioned on IRC it would be nice to have a unit test that confirmed that the headers were being correctly buffered.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:05:03 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 19:05:03 +0000
Subject: [issue9338] argparse optionals with nargs='+' can't be followed by
	positionals
In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za>
Message-ID: <1290279903.66.0.0527609126932.issue9338@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

My attached patch adds the "--" between the optionals and the arguments, if there are optionals which have variable length and at least some positional argument can be provided.

Patch is for python 3.2 svn revision 86553.

----------
nosy: +Kotan
Added file: http://bugs.python.org/file19691/issue9338_argparse.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9338>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:05:04 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 19:05:04 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290279904.45.0.957449180217.issue3709@psf.upfronthosting.co.za>


endian <andrew at andrewschaaf.com> added the comment:

Working on it...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:05:44 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 19:05:44 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290279944.66.0.094723666984.issue3709@psf.upfronthosting.co.za>


Changes by endian <andrew at andrewschaaf.com>:


Added file: http://bugs.python.org/file19692/issue3709.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:07:00 2010
From: report at bugs.python.org (Rodolpho Eckhardt)
Date: Sat, 20 Nov 2010 19:07:00 +0000
Subject: [issue8078] add more baud constants to termios
In-Reply-To: <1267849602.5.0.0627386493701.issue8078@psf.upfronthosting.co.za>
Message-ID: <1290280020.51.0.965230348146.issue8078@psf.upfronthosting.co.za>


Rodolpho Eckhardt <r at rhe.vg> added the comment:

Added those baud rates using #ifdef's because I'm not sure all platforms will define them.

----------
keywords: +patch
nosy: +Rodolpho.Eckhardt
Added file: http://bugs.python.org/file19693/termios_baud.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8078>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:07:10 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 20 Nov 2010 19:07:10 +0000
Subject: [issue9424] Disable unittest.TestCase.assertEquals and assert_ during
	a regrtest run
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1290280030.08.0.487600098399.issue9424@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Committed in r86596.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9424>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:08:59 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 19:08:59 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1290280139.44.0.425167974574.issue9182@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

I did the patch for adding the "--" in the generated usage text inside issue 9338.

----------
nosy: +Kotan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:09:58 2010
From: report at bugs.python.org (Jeremy Thurgood)
Date: Sat, 20 Nov 2010 19:09:58 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>
Message-ID: <1290280198.27.0.333542204475.issue10231@psf.upfronthosting.co.za>


Jeremy Thurgood <firxen at gmail.com> added the comment:

Thanks for the comments.

There are two separate things here: the URL and the filesystem path. The only part of the URL we care about is the path section, but the fragment ("#anchor") and query parameters ("?foo") are valid -- SimpleHTTPRequestHandler just ignores them. translate_path() turns the URL into the filesystem path, which may be a file or a directory, by extracting the URL path and mapping it onto the filesystem.

The bug is that the fragment and query parameters are stripped in translate_path(), but are *not* stripped when manipulating the URL for the redirect.

This means that when the URL is "/something?foo" and the cwd is "/tmp", the filesystem path is "/tmp/something" (which is a directory) and therefore the response needs to be a redirect. The redirect needs to modify the path section of the URL (which is "/something") to add a slash. This means the redirect needs to be to "/something/" (or "/something/?foo" if you want to preserve the query parameters) rather than "/something?foo/" which is what the current implementation does.

translate_path() unescapes the URL path before mapping it to the filesystem, which means that "/something%3Ffoo" (and even "/something%3Ffoo?bar") will be turned into the filesystem path "/tmp/something?foo".

I'll add some tests for the "/something%3Ffoo" case and possibly update send_head() to preserve the fragment and query parameters on redirect.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:10:59 2010
From: report at bugs.python.org (Henrique Bastos)
Date: Sat, 20 Nov 2010 19:10:59 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1290280259.56.0.842421658655.issue9305@psf.upfronthosting.co.za>


Henrique Bastos <henrique at bastos.net> added the comment:

Here goes a patch to replace east/west references on datetime documentation.

As spoken with fdrake we think the datetime documentation could be improved extracting the timezone subclassing details to specific section. We'll be filling a new issue for that patch.

----------
nosy: +Rodolpho.Eckhardt, henriquebastos

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:11:19 2010
From: report at bugs.python.org (Henrique Bastos)
Date: Sat, 20 Nov 2010 19:11:19 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1290280279.86.0.338565170683.issue9305@psf.upfronthosting.co.za>


Henrique Bastos <henrique at bastos.net> added the comment:

Here goes a patch to replace east/west references on datetime documentation.

As spoken with fdrake we think the datetime documentation could be improved extracting the timezone subclassing details to specific section. We'll be filling a new issue for that patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file19694/datetime_doc_remove_east_west.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:18:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 19:18:27 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1290280259.56.0.842421658655.issue9305@psf.upfronthosting.co.za>
Message-ID: <AANLkTin7xcDnNdONKwAh4B0iS8=XZnF4tkDATDLL5H5s@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

LGTM

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:18:31 2010
From: report at bugs.python.org (Wes Chow)
Date: Sat, 20 Nov 2010 19:18:31 +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: <1290280711.81.0.197096149201.issue9721@psf.upfronthosting.co.za>


Wes Chow <wes.chow at gmail.com> added the comment:

Here's a patch for 3.2 which fixes this problem I believe. There does exist a test case that should have produced an error, except that the last path segment in RFC3986_BASE is only one character long. Had it been more than one character long, RFC3986 checks would have failed.

Also in the supplied patch is a test to catch this specific bug.

----------
nosy: +weschow
Added file: http://bugs.python.org/file19695/urlparse-9721.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9721>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:20:46 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 20 Nov 2010 19:20:46 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290278676.84.0.830272243474.issue10461@psf.upfronthosting.co.za>
Message-ID: <AANLkTinOzak-vxDPz2WjFw8rKafPt=dWsX7Ax_6mFxrt@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

On Sat, Nov 20, 2010 at 20:44, ??ric Araujo <report at bugs.python.org> wrote:

>
> ??ric Araujo <merwok at netwok.org> added the comment:
>
> Eli, SilentGhost: Please open other bug reports for doc errors like the
> struct one in stdlib2 or the r/rb one.
>
> SilentGhost: with statement used with open *is* about file reading :)
>
> Raymond: I agree about try/finally.  I agree with Alexander about
> collections.rst.
>

??ric,

It turned out to be a non-issue, never mind.

----------
Added file: http://bugs.python.org/file19696/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________
-------------- next part --------------
<div dir="ltr"><br><div class="gmail_quote">On Sat, Nov 20, 2010 at 20:44, ??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;">

<div class="im"><br>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<br>
</div>Eli, SilentGhost: Please open other bug reports for doc errors like the struct one in stdlib2 or the r/rb one.<br>
<br>
SilentGhost: with statement used with open *is* about file reading :)<br>
<br>
Raymond: I agree about try/finally. ??I agree with Alexander about collections.rst.<br></blockquote></div><br>??ric,<br><br>It turned out to be a non-issue, never mind.<br><br></div>

From report at bugs.python.org  Sat Nov 20 20:25:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Nov 2010 19:25:25 +0000
Subject: [issue9435] test_distutils fails without zlib
In-Reply-To: <1280590585.97.0.266735291444.issue9435@psf.upfronthosting.co.za>
Message-ID: <1290281125.96.0.90421338864.issue9435@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9435>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:26:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 19:26:02 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1290281162.33.0.257553899078.issue9305@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee: docs at python -> belopolsky
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:27:40 2010
From: report at bugs.python.org (Tarsis Azevedo)
Date: Sat, 20 Nov 2010 19:27:40 +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: <1290281260.0.0.501194571773.issue8911@psf.upfronthosting.co.za>


Tarsis Azevedo <tarsis.azevedo at gmail.com> added the comment:

Hi all,

I followed from 1 to 5 steps of jerry's comment and removed a recursive import I didnt get it.

The patch is attached.

----------
keywords: +patch
nosy: +Tarsis.Azevedo
Added file: http://bugs.python.org/file19697/issue8911.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8911>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:27:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 19:27:44 +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: <1290281264.06.0.532987198019.issue9721@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9721>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:31:23 2010
From: report at bugs.python.org (Mauro Navarro Baraldi)
Date: Sat, 20 Nov 2010 19:31:23 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1290281483.03.0.228569529547.issue8890@psf.upfronthosting.co.za>


Mauro Navarro Baraldi <mauro.baraldi at gmail.com> added the comment:

Replace to most use of /tmp/tempfile for just tempfile, as sugested before.

----------
keywords: +patch
nosy: +maurobaraldi
Added file: http://bugs.python.org/file19698/py3k-docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:31:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 19:31:56 +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: <1290281516.01.0.427260008727.issue9721@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9721>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:35:36 2010
From: report at bugs.python.org (Abhay Saxena)
Date: Sat, 20 Nov 2010 19:35:36 +0000
Subject: [issue7804] test_readline failure
In-Reply-To: <1264773697.69.0.94250627584.issue7804@psf.upfronthosting.co.za>
Message-ID: <1290281736.94.0.242470998709.issue7804@psf.upfronthosting.co.za>


Abhay Saxena <ark3 at email.com> added the comment:

Works for me with a fresh py3k on Ubuntu.

----------
nosy: +ark3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7804>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:36:10 2010
From: report at bugs.python.org (=?utf-8?q?Rafael_dos_Santos_Gon=C3=A7alves?=)
Date: Sat, 20 Nov 2010 19:36:10 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	relative dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1290281770.81.0.265889736453.issue7325@psf.upfronthosting.co.za>


Rafael dos Santos Gon?alves <rafaelsantosg at gmail.com> added the comment:

Hi people,
I insert a simple code in tempfile.py, that verify if the return starts with ./, and concatenate using the abspath function.
I changed the variable name file to temp_dir_abspath, because file is a built-in function and it's not recommended, overwrite it with local variables.
And at least i add one test, that verify if temp_directory returns an absolut path.

thanks.

----------
nosy: +elesbom
Added file: http://bugs.python.org/file19699/issue7325.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:37:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Nov 2010 19:37:29 +0000
Subject: [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1290281849.38.0.850268042606.issue8340@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Done in r86602.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8340>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:37:31 2010
From: report at bugs.python.org (Jim Pharis)
Date: Sat, 20 Nov 2010 19:37:31 +0000
Subject: [issue7804] test_readline failure
In-Reply-To: <1264773697.69.0.94250627584.issue7804@psf.upfronthosting.co.za>
Message-ID: <1290281851.01.0.00482793522865.issue7804@psf.upfronthosting.co.za>


Jim Pharis <binbrain at gmail.com> added the comment:

Unable to recreate this in Ubuntu 10.04 w/3.2 alpha 4. Tried with and without readline lib installed.

----------
nosy: +binbrain

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7804>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:40:47 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 19:40:47 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290282047.85.0.495863273294.issue10453@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Removed file: http://bugs.python.org/file19684/issue10453.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:40:50 2010
From: report at bugs.python.org (Cherniavsky Beni)
Date: Sat, 20 Nov 2010 19:40:50 +0000
Subject: [issue9724] help('nonlocal') missing
In-Reply-To: <1283264506.65.0.891353538251.issue9724@psf.upfronthosting.co.za>
Message-ID: <1290282050.75.0.828883098721.issue9724@psf.upfronthosting.co.za>


Cherniavsky Beni <cben at users.sf.net> added the comment:

Reopening because help('nonlocal') still doesn't work; attached patch fixes that.  It also cross-links all of global/nonlocal/NAMESPACES.

----------
keywords: +patch
resolution: fixed -> 
status: closed -> open
Added file: http://bugs.python.org/file19700/nonlocal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9724>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:41:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 20 Nov 2010 19:41:00 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290282060.35.0.240444938709.issue10469@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Kotan: please perform the following procedure:

1. Open pcbuild.sln
2. In the pythoncore project, open errnomodule.c
3. find the reference to EWOULDBLOCK and WSAEWOULDBLOCK
4. for each one, "go to definition"
5. report here what header files Visual Studio thinks they are defined in, and what values they have.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:41:05 2010
From: report at bugs.python.org (Jeremy Thurgood)
Date: Sat, 20 Nov 2010 19:41:05 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>
Message-ID: <1290282065.21.0.44074259304.issue10231@psf.upfronthosting.co.za>


Jeremy Thurgood <firxen at gmail.com> added the comment:

Updated patch as per previous comment.

----------
Added file: http://bugs.python.org/file19701/issue10231_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:41:22 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 19:41:22 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290282082.99.0.730929834575.issue10453@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Unittest added; should be enough.

----------
Added file: http://bugs.python.org/file19702/issue10453.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:41:34 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 19:41:34 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290282094.44.0.819317118909.issue10453@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file19703/issue10453_tests.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:50:23 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 19:50:23 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290282623.33.0.49320482046.issue10469@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

#define EWOULDBLOCK     140
#define WSAEWOULDBLOCK                   10035L

The editor suggests that EWOULDBLOCK is already defined, therefore its code is used, i.e. 140.

#define ECONNREFUSED    107
#define WSAECONNREFUSED                  10061L

The E* are defined in errno.h and the WSA* in WinError.h. It seems that in my case the POSIX compliant headers are used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:52:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Nov 2010 19:52:17 +0000
Subject: [issue10255] refleak in initstdio
In-Reply-To: <1288467873.78.0.806058844227.issue10255@psf.upfronthosting.co.za>
Message-ID: <1290282737.22.0.742901367754.issue10255@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r86607, thanks.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10255>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:53:08 2010
From: report at bugs.python.org (Ramiro Batista da Luz)
Date: Sat, 20 Nov 2010 19:53:08 +0000
Subject: [issue5066] IDLE documentation for Unix obsolete/incorrect
In-Reply-To: <1232942217.99.0.191249551049.issue5066@psf.upfronthosting.co.za>
Message-ID: <1290282788.56.0.754365449138.issue5066@psf.upfronthosting.co.za>


Ramiro Batista da Luz <ramiroluz at gmail.com> added the comment:

I reviewed the texts, applied the patches, ran idle, edited Demo/classes/Dates.py run module inside Idle. Generated the docs inside Doc, with make html and reviewed the IDLE doc in ~/python/py3k/Doc/build/html/library/idle.html?highlight=idle

Only in the 3.2 tree.

----------
nosy: +ramiroluz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5066>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:54:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 19:54:48 +0000
Subject: [issue9724] help('nonlocal') missing
In-Reply-To: <1283264506.65.0.891353538251.issue9724@psf.upfronthosting.co.za>
Message-ID: <1290282888.66.0.0878779529735.issue9724@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied in r86608. Thanks!

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9724>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:56:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 19:56:11 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1290282971.88.0.0229491054357.issue9305@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On the second reading, I have a few issues with the patch.

1. Please run makepatcheck.  There are whitespace issues in datetime.rst.
2. In docstrings, you remove the information about the sign.  I would not mind leaving docstrings the way they are.  Otherwise, please add a short sentence explaining the sign of utcoffset and dst.
3. "This represents the offset in minutes that must be added to the local time zone to follow DST rules."   This unclear.  DST offset is added to the "standard time", not "local time zone".  (I am not sure if "standard time" is defined in the manual, though.)  Also, "in minutes" is not necessary - timedelta carries the units. You can add that only offsets that are multiples of a minute are supported.

----------
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Sat Nov 20 20:56:46 2010
From: report at bugs.python.org (Dan L)
Date: Sat, 20 Nov 2010 19:56:46 +0000
Subject: [issue10471] include documentation in python docs and under python -h
	for other commandline options
In-Reply-To: <1290283006.28.0.157512175607.issue10471@psf.upfronthosting.co.za>
Message-ID: <1290283006.28.0.157512175607.issue10471@psf.upfronthosting.co.za>


New submission from Dan L <choralreef at naver.com>:

there are options such as 'python -tt -bb' that are undocumented at http://docs.python.org/using/cmdline and that don't show up when you type python -h.   ( Doubling t and b turns tabs or bytes warnings into errors.
) I don't know if they show up or not when you type 'man python', but for windows devs, it'd be best if it were included in the '-h' text excerpt in addition to being in the online docs.  It could also be nice to have an example for the W arg option, e.g. for Wd.

----------
assignee: docs at python
components: Documentation, Interpreter Core
messages: 121746
nosy: docs at python, jdan
priority: normal
severity: normal
status: open
title: include documentation in python docs and under python -h for other commandline options
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10471>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:03:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Nov 2010 20:03:33 +0000
Subject: [issue8078] add more baud constants to termios
In-Reply-To: <1267849602.5.0.0627386493701.issue8078@psf.upfronthosting.co.za>
Message-ID: <1290283413.34.0.54088680712.issue8078@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r86610, thank you!

----------
nosy: +pitrou
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8078>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:07:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 20 Nov 2010 20:07:14 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290283634.91.0.88646662076.issue10469@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

OK, so what's the path to errno.h? In the errno.h included in my copy of VS 2010, the errno values only go up to 42 (80 if you count STRUNCATE), and EWOULDBLOCK is not defined in this header file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:09:47 2010
From: report at bugs.python.org (Rodolpho Eckhardt)
Date: Sat, 20 Nov 2010 20:09:47 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1290283787.62.0.745411121693.issue10220@psf.upfronthosting.co.za>


Rodolpho Eckhardt <r at rhe.vg> added the comment:

This patch adds the getgeneratorstate function and related tests.

----------
keywords: +patch
nosy: +Rodolpho.Eckhardt
Added file: http://bugs.python.org/file19705/getgeneratorstate.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:09:47 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 20:09:47 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290283787.62.0.637111524949.issue3709@psf.upfronthosting.co.za>


endian <andrew at andrewschaaf.com> added the comment:

Ready for review. Added test_header_buffering which fails without the BaseHTTPRequestHandler patch and passes with it.

----------
Added file: http://bugs.python.org/file19704/issue3709.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:11:19 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 20:11:19 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290283879.96.0.336934509311.issue3709@psf.upfronthosting.co.za>


Changes by endian <andrew at andrewschaaf.com>:


Removed file: http://bugs.python.org/file19689/issue3709.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:11:23 2010
From: report at bugs.python.org (endian)
Date: Sat, 20 Nov 2010 20:11:23 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290283883.51.0.857889449149.issue3709@psf.upfronthosting.co.za>


Changes by endian <andrew at andrewschaaf.com>:


Removed file: http://bugs.python.org/file19692/issue3709.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:12:32 2010
From: report at bugs.python.org (Henrique Bastos)
Date: Sat, 20 Nov 2010 20:12:32 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1290283952.35.0.911335039846.issue9305@psf.upfronthosting.co.za>


Henrique Bastos <henrique at bastos.net> added the comment:

To clarify:

1) "we" means henriquebastos, rbp, Rodolpho.Eckhardt.

2) Mentioning fdrake I was trying to say that we followed his suggestion to only submit the specific changes on this patch, leaving further documentation changes to another issue.

Sorry about any inconvenience.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:14:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 20 Nov 2010 20:14:24 +0000
Subject: [issue10471] include documentation in python docs and under python -h
	for other commandline options
In-Reply-To: <1290283006.28.0.157512175607.issue10471@psf.upfronthosting.co.za>
Message-ID: <1290284064.39.0.272785878224.issue10471@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

-tt is documented on the page you link to.  -b and -bb are only available in Python 3, and are documented there: <http://docs.python.org/py3k/using/cmdline>.  -b and -bb also show up in python -h.

In the contrary, -t and -tt have been removed in Python 3 (-tt behavior is default now); you can still give them but they have no effect.

Giving examples for -W option in python -h would be too much verbosity.

All in all, I can't see an issue here.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10471>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:14:54 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 20:14:54 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290284094.97.0.724483064271.issue10469@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

c:\Program Files\Microsoft Visual Studio 10.0\VC\include\errno.h

The content of my errno.h:

...
#define EILSEQ          42
#define STRUNCATE       80
#endif
#endif

/* Support EDEADLOCK for compatibility with older MS-C versions */
#define EDEADLOCK       EDEADLK

/* POSIX SUPPLEMENT */
#define EADDRINUSE      100
#define EADDRNOTAVAIL   101
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:17:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 20:17:59 +0000
Subject: [issue9500] urllib2: Content-Encoding
In-Reply-To: <1280874046.96.0.44632804656.issue9500@psf.upfronthosting.co.za>
Message-ID: <1290284279.6.0.140511463066.issue9500@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Issue 1508475 has a patch, though it still needs updated.

----------
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
status: open -> closed
superseder:  -> transparent gzip compression in liburl2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9500>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:20:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Nov 2010 20:20:58 +0000
Subject: [issue7804] test_readline failure
In-Reply-To: <1264773697.69.0.94250627584.issue7804@psf.upfronthosting.co.za>
Message-ID: <1290284458.46.0.623057478.issue7804@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't reproduce anymore (Debian 5.0.6). Barry?

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7804>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:21:13 2010
From: report at bugs.python.org (Wes Chow)
Date: Sat, 20 Nov 2010 20:21:13 +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: <1290284473.38.0.384699997077.issue9721@psf.upfronthosting.co.za>


Wes Chow <wes.chow at gmail.com> added the comment:

New patch (urlparse-9721-3.2.patch) against 3.2 which fixes the erroneous test.

----------
Added file: http://bugs.python.org/file19706/urlparse-9721-3.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9721>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:21:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 20:21:22 +0000
Subject: [issue10407] missing errno import in distutils/dir_util.py
In-Reply-To: <1289657199.35.0.294057606181.issue10407@psf.upfronthosting.co.za>
Message-ID: <1290284482.23.0.274808409355.issue10407@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Fixed in r86601 and r86605 (py3k), r86606 (3.1), r86609 (2.7).  Thanks!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10407>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:22:01 2010
From: report at bugs.python.org (Wes Chow)
Date: Sat, 20 Nov 2010 20:22:01 +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: <1290284521.74.0.966044773947.issue9721@psf.upfronthosting.co.za>


Wes Chow <wes.chow at gmail.com> added the comment:

Patch against 2.7 (urlparse-9721-2.7.patch).

----------
Added file: http://bugs.python.org/file19707/urlparse-9721-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9721>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:23:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 20:23:25 +0000
Subject: [issue1508475] transparent gzip compression in urllib
Message-ID: <1290284605.17.0.809476234675.issue1508475@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components:  -Extension Modules
nosy: +eric.araujo -BreamoreBoy
title: transparent gzip compression in liburl2 -> transparent gzip compression in urllib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1508475>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:27:40 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 20:27:40 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290284860.3.0.914645536011.issue10453@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Added file: http://bugs.python.org/file19708/issue10453_final.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:29:16 2010
From: report at bugs.python.org (Bruno Gola)
Date: Sat, 20 Nov 2010 20:29:16 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290284956.7.0.038272083748.issue3709@psf.upfronthosting.co.za>


Bruno Gola <brunogola at gmail.com> added the comment:

applied the patch on py3k on trunk and everything seems fine (works here)

----------
nosy: +brunogola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:32:13 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 20 Nov 2010 20:32:13 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290285133.07.0.863333225912.issue7094@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Also note that if # is added for float and Decimal, it should be added for complex. My Bug Day sprint group will have a patch for this shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:34:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 20:34:40 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290285280.0.0.653680034747.issue10470@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The existing discover subcommand would enter the deprecation process, right?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:34:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 20 Nov 2010 20:34:43 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290285283.28.0.934643437743.issue10469@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Oops, I was confused. My copy is VS 2008, of course. So that's another incompatible change in VS 2010. Tcl, Ruby, and curl are ahead of us, here:

http://redmine.ruby-lang.org/issues/show/3092
http://sourceforge.net/tracker/index.php?func=detail&aid=3019634&group_id=10894&atid=310894
http://www.mail-archive.com/curl-library at cool.haxx.se/msg05164.html

I think we can work around that by switching the order of preference: use WSA constants if available, and errno.h values otherwise.

Kotan: can you please search the CRT sources whether these "POSIX" values are used anywhere?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:35:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 20:35:12 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290285312.65.0.204601789353.issue10470@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:42:05 2010
From: report at bugs.python.org (Bruno Gola)
Date: Sat, 20 Nov 2010 20:42:05 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290285725.63.0.961309687404.issue10453@psf.upfronthosting.co.za>


Bruno Gola <brunogola at gmail.com> added the comment:

applied the patch on an ubuntu 10.04 64bits, py3k (trunk)

test_force fails as following:

======================================================================
FAIL: test_force (__main__.CommandLineTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_compileall.py", line 202, in test_force
    self.assertNotEqual(access, access2)
AssertionError: 1290285399.744327 == 1290285399.744327

----------------------------------------------------------------------

----------
nosy: +brunogola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:43:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 20:43:47 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	relative dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1290285827.54.0.337966582533.issue7325@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good to me, with one exception:

 if temp_dir_abspath.startswith('./'):

Wouldn?t this be better:

 if not _os.path.isabs(temp_dir_abspath)

(P.S. file is not a builtin anymore in 3.x, it?s used for example as an argument to the print function.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:46:27 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sat, 20 Nov 2010 20:46:27 +0000
Subject: [issue9305] Don't use east/west of UTC in date/time documentation
In-Reply-To: <1279556505.28.0.814004588201.issue9305@psf.upfronthosting.co.za>
Message-ID: <1290285987.11.0.774107757231.issue9305@psf.upfronthosting.co.za>


Rodrigo Bernardo Pimentel <rbp at isnomore.net> added the comment:

1. Done (it's on the patch I'm uploading). Sorry.

3. Ok, we've rewritten that sentence. As Henrique mentioned, we're working on a larger patch to make datetime documentation clearer, and we can include a definition of "standard time" there.


2. I assume you're talking about sentences like "(negative for west of UTC)". We removed that wording because it inevitably leads to associating UTC with a geographical reference. Even if we disregard that, it's not true that "utcoffset is negative west of UTC", since it will we zero for for UTC-1 (and even +1 for places physically "west of UTC" but at timezone UTC+0) when DST is effective.

It seems that any sentence we add to that effect will be simply restating the definitions of UTC, timezones and DST (and their mathematical relationships). That is, "utcoffset will be negative when dt.tzinfo + dst() is negative".

Perhaps we could include a more detailed discusion about the sign of utcoffset() on the larger doc patch I've mentioned? Or do you have any suggestions?

----------
Added file: http://bugs.python.org/file19709/datetime_doc_remove_east_west_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9305>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:47:34 2010
From: report at bugs.python.org (Daniel Harper)
Date: Sat, 20 Nov 2010 20:47:34 +0000
Subject: [issue10472] Strange tab key behaviour in interactive python 2.7 OSX
	10.6.2
In-Reply-To: <1290286054.61.0.644814416061.issue10472@psf.upfronthosting.co.za>
Message-ID: <1290286054.61.0.644814416061.issue10472@psf.upfronthosting.co.za>


New submission from Daniel Harper <djharperuk at gmail.com>:

Hi there. 

I recently downloaded the python 2.7 installer from the python website and installed it on my Mac. 

When I run python2.7 in interactive mode, the tab key doesn't seem to behave as how it did in 2.6.

For example


>> def helloWorld(name):                                                                    
... ./                                                                                    File "<stdin>", line 2   
    ./                                                                                    
    ^                                                                                       
IndentationError: expected an indented block     

When you hit tab it seems to think I want to browse the contents of the current directory I'm in, rather than placing a tab character so I can quickly use python in interactive mode to prototype stuff.

I'd imagine it's something to do with GNU readline, but I'm pretty sure I have this installed

----------
assignee: ronaldoussoren
components: Macintosh
messages: 121766
nosy: Daniel.Harper, ronaldoussoren
priority: normal
severity: normal
status: open
title: Strange tab key behaviour in interactive python 2.7 OSX 10.6.2
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10472>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:51:49 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 20:51:49 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290286309.97.0.98997297822.issue10469@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

Only in the "system_error" file. (http://msdn.microsoft.com/en-us/library/ee372194.aspx) Seem to be a C++0X standard header file.

http://msdn.microsoft.com/en-us/library/5814770t.aspx

talks about the Posix codes only for compatibility reasons.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:53:11 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Sat, 20 Nov 2010 20:53:11 +0000
Subject: [issue6007] distutils tricks you into thinking you can	build
	extensions with mingw
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <1290286391.64.0.449952626389.issue6007@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

I just compiled the zope.interface c speedups with MinGW on Python 2.7 and 2.6. 

There is a patch being tracked in the MinGW patch tracker <http://sourceforge.net/tracker/index.php?func=detail&aid=2134161&group_id=2435&atid=302435> related to the localtime linking issue, but there is no indication that the patch was accepted.

My experience with MinGW has been that it almost always works except where C++ is used or MinGW itself trips on a MSVCRT issue. Perhaps a note about that would be sufficient to close this bug?

----------
nosy: +lambacck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6007>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:54:16 2010
From: report at bugs.python.org (Roy Smith)
Date: Sat, 20 Nov 2010 20:54:16 +0000
Subject: [issue10473] Strange behavior for socket.timeout
In-Reply-To: <1290286456.52.0.376414349457.issue10473@psf.upfronthosting.co.za>
Message-ID: <1290286456.52.0.376414349457.issue10473@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

While investigating issue7322, I wrote a test case to demonstrate the issue.  I made a mistake and called settimeout() on the wrong socket, but the result appears to demonstrate a different bug.  When I run the attached test-issue7322.py on my OSX-10.6.5 machine, using...

Python 3.2a4+ (py3k:86538, Nov 19 2010, 20:52:31) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin

I get the output below.  The bug is that readline() is returning, even though I never wrote a newline on the other side of the connection.  If I comment out the settimeout() call, it hangs in the readline() call, as expected.

While I admit it makes no sense to call settimeout() on the listening socket, doing so certainly should not cause this behavior.

Note: I also tried this on Ubuntu linux (with python built from the same 3.2a4+ sources).  I cannot reproduce the problem there.


issue7322$ ./test-issue7322.py 
F/Users/roy/python/py3k/Lib/unittest/case.py:382: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=0>
  result.addFailure(self, sys.exc_info())
/Users/roy/python/py3k/Lib/unittest/case.py:382: ResourceWarning: unclosed <socket.socket object, fd=4, family=2, type=1, proto=0>
  result.addFailure(self, sys.exc_info())
/Users/roy/python/py3k/Lib/socket.py:324: ResourceWarning: unclosed <socket.socket object, fd=5, family=2, type=1, proto=0>
  self._sock = None

======================================================================
FAIL: test_foo (__main__.Test_Issue7322)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "./test-issue7322.py", line 22, in test_foo
    self.fail("readline() returned '%s'" % line)
AssertionError: readline() returned 'hello'

----------------------------------------------------------------------
Ran 1 test in 0.026s

FAILED (failures=1)
[49547 refs]

----------
components: Library (Lib)
files: test-issue7322.py
messages: 121769
nosy: roysmith
priority: normal
severity: normal
status: open
title: Strange behavior for socket.timeout
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19710/test-issue7322.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10473>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:55:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 20 Nov 2010 20:55:39 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290286309.97.0.98997297822.issue10469@psf.upfronthosting.co.za>
Message-ID: <4CE835C8.1090606@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Only in the "system_error" file. (http://msdn.microsoft.com/en-us/library/ee372194.aspx) 
> Seem to be a C++0X standard header file.

(I assume you have actually scanned the crt\src folder as well)

Then it's indeed safe to ignore.

> http://msdn.microsoft.com/en-us/library/5814770t.aspx
> 
> talks about the Posix codes only for compatibility reasons.

Unfortunately, they managed to break compatibility with that change,
instead of introducing it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:56:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 20:56:23 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1290286583.79.0.27725059453.issue10220@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good, modulo two nitpicks:

1) Using literals for constants would avoid a lookup and call of range.

2) Please remove four leading spaces in your docstring.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:57:12 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 20:57:12 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290286632.84.0.618835808317.issue10453@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Yes, I was discussing about that on IRC. That's a matter of platform -on mine for example works-. He gave me a hand in solving this failure; now -I think- he's gonna apply that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:57:50 2010
From: report at bugs.python.org (Abhay Saxena)
Date: Sat, 20 Nov 2010 20:57:50 +0000
Subject: [issue9909] request for calendar.dayofyear() function
In-Reply-To: <1285039663.27.0.59327234025.issue9909@psf.upfronthosting.co.za>
Message-ID: <1290286670.0.0.61248300667.issue9909@psf.upfronthosting.co.za>


Abhay Saxena <ark3 at email.com> added the comment:

The test is incorrect on leap years for February 29, due to the way it constructs its list of dates. The function itself appears to give the right answer.

----------
nosy: +ark3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9909>
_______________________________________

From report at bugs.python.org  Sat Nov 20 21:58:06 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 20:58:06 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290286686.71.0.293429271503.issue10453@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

*discussing that on IRC with R. David Murray

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:03:29 2010
From: report at bugs.python.org (John J Lee)
Date: Sat, 20 Nov 2010 21:03:29 +0000
Subject: [issue1520831] urrlib2 max_redirections=0 disables redirects
Message-ID: <1290287009.47.0.184094016799.issue1520831@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Oops, I hadn't noticed that max_redirections isn't part of the API.  In that case, I agree that it's not strictly a bug.  I'd also agree it's not very important.

FWIW: "want[ing] to see all redirects" is not the same thing as printing URLs -- I assume he simply meant that he wanted .open to return the original response, and not a redirected response.  I don't think he meant that he wanted urllib2 itself to allow him to literally see the URLs on his screen, by printing them to stdout (!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1520831>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:04:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 21:04:35 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290287075.92.0.590281825504.issue10453@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: eric.araujo -> r.david.murray
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:07:02 2010
From: report at bugs.python.org (Abhay Saxena)
Date: Sat, 20 Nov 2010 21:07:02 +0000
Subject: [issue9909] request for calendar.dayofyear() function
In-Reply-To: <1285039663.27.0.59327234025.issue9909@psf.upfronthosting.co.za>
Message-ID: <1290287222.9.0.718510011893.issue9909@psf.upfronthosting.co.za>


Abhay Saxena <ark3 at email.com> added the comment:

Quick hack alternative test. It would look nicer if the test used the datetime module, but I'm not sure that would be appropriate.


    def test_dayofyear(self):                                                                                                  
        """Test for the calendar.dayofyear() function, which computes the                                                      
        integer between 1 and 366 (inclusive) representing the specified day in                                                
        the specified month of the specified year.                                                                             
                                                                                                                               
        """                                                                                                                    
        for expected_total, year in (366, 2008), (365, 2010):                                                                  
            expected_day_of_year = 1                                                                                           
            for month in range(1, 13):                                                                                         
                lastDay = calendar.mdays[month]                                                                                
                if year == 2008 and month == 2:                                                                                
                    lastDay = 29                                                                                               
                for day in range(1, lastDay + 1):                                                                              
                    day_of_year = calendar.dayofyear(year, month, day)                                                         
                    self.assertEqual(expected_day_of_year, day_of_year)                                                        
                    # The computed day of the year must be between 1 and 366.                                                  
                    self.assertGreaterEqual(day_of_year, 1)                                                                    
                    self.assertLessEqual(day_of_year, 366)                                                                     
                    expected_day_of_year += 1                                                                                  
            self.assertEqual(expected_day_of_year - 1, expected_total)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9909>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:08:58 2010
From: report at bugs.python.org (Roy Smith)
Date: Sat, 20 Nov 2010 21:08:58 +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: <1290287338.09.0.0990137731584.issue7322@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

I'm looking into this now.  In the meantime, I've opened a marginally-related bug, issue10473

----------
nosy: +roysmith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:11:20 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 20 Nov 2010 21:11:20 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1290287480.86.0.564884877441.issue10399@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Thanks for reading through this.

> There are a couple places you mention not doing the optimization when
> specific functions are used (e.g. dir, globals, locals), how exactly do you
> verify that, given those functions could be bound to any name?

I don't: I'm only looking at explicit references to these global names:
   BUILTINS_THAT_READ_LOCALS = {'locals', 'vars', 'dir'}

but I haven't attempted to track these at the object level, just at the name level.

This means that if someone is passing these around bound to a different name, the results could be "wrong": the optimizations that I'm doing are synthesizing new local and global variables (in each case with a '__' prefix), and sometimes eliminating local variables.

However, it should work as expected for the simple and common case for code like this:

  def foo():
      ...
      pprint(locals())
      ...

since the reference to "locals" can be seen at the name level.

But it won't work for something like this:

   def inlined_fn(a):
       print(a())

   def not_inlinable_for_some_reason(b):
       inlined_fn(b) # assume this callsite is inlined

   def some_other_fn_perhaps_in_another_module():
       hidden_ref_to_locals = locals
       not_inlinable_for_some_reason(hidden_ref_to_locals)

in that (if inlining happens) the local printed will be named "b", rather than "a".

But this seems to me like a contrived example: how often in real code do people pass around these builtins, rather than calling them directly?  I myself use them for debugging, but I only ever call them directly.

At a high level, what I'm interested in is providing additional benefits for python 3 relative to python 2 (to encourage migration), and I picked speed-ups.

I think it's reasonable to provide some kind of "optimized" mode that is allowed to take (limited) liberties with the language.

Note that with other languages, people seem to accept some mild degradation of debuggability in return for compiler optimizations.  I'd like to be able to provide a faster python under similar kinds of tradeoffs.

Currently, Python's optimized mode doesn't seem to do much (just compile away assertions iirc).  Perhaps these optimizations could be associated with the pre-existing optimizer flag; alternatively, perhaps a 3rd level could be provided?

This seems like a PEP-level request, but here's an outline of my thoughts here:

I'd like the highly-optimized mode to be permitted the following::
  - to create additional synthesized globals, with a "__" prefix; modification of these globals to lead to undefined behavior.
  - when querying locals under some circumstances (see below) for locals to not be present, or for additional locals to be present::
     - when using "inspect" and reading/modifying a Frame's f_locals
     - in "non-direct" invocations of "locals", "globals" and "dir" (however, when called directly by name, they must work)
     - as per globals, synthesized locals to have a prefix, and modification to lead to undefined behavior
  - a pony :)
  - more seriously, I'm planning to look next at inlining method calls (within one module), and type inference, and I may come up with additional requirements.

I believe that the above covers all of the places where my patch is taking liberties with existing Python semantics (modulo bugs): I'm still supporting runtime rebinding of other names, and (I believe), preserving existing behavior.  (please let me know if I'm missing something here!)

There seems to be some precedent for this:
http://docs.python.org/library/functions.html states:
> Note Because dir() is supplied primarily as a convenience for use at an
> interactive prompt, it tries to supply an interesting set of names more
> than it tries to supply a rigorously or consistently defined set of names,
> and its detailed behavior may change across releases. For example,
> metaclass attributes are not in the result list when the argument is a class.

and for locals() it warns:
> Note The contents of this dictionary should not be modified; changes may not
> affect the values of local and free variables used by the interpreter.

Does this sound sane? (obviously, actually approving this would be a matter for the BDFL).

Perhaps all synthesized vars could have a "__internal__" prefix to signify that they should be left alone.


The other PEP-level request would be for the highly-optimized mode to be permitted to take human-noticable time to generate its bytecode (rather than being "instantaneous").  I don't know if that's needed yet: the inliner is currently just a prototype, and I don't have any heuristics yet for deciding whether to inline a callsite (beyond an arbitrary cutoff I put in to stop bm_simple_call from "exploding"); I'm probably introducing various O(N^2) time/space behaviors (and worse) right now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:14:02 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sat, 20 Nov 2010 21:14:02 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1290287642.06.0.365939741707.issue10220@psf.upfronthosting.co.za>


Changes by Rodrigo Bernardo Pimentel <rbp at isnomore.net>:


----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:14:12 2010
From: report at bugs.python.org (Roy Smith)
Date: Sat, 20 Nov 2010 21:14:12 +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: <1290287652.18.0.107519035151.issue7322@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

Ataching a test case which demonstrates the bug.

----------
Added file: http://bugs.python.org/file19711/test-issue7322.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:15:25 2010
From: report at bugs.python.org (Rodolpho Eckhardt)
Date: Sat, 20 Nov 2010 21:15:25 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1290287725.68.0.625545085677.issue10220@psf.upfronthosting.co.za>


Rodolpho Eckhardt <r at rhe.vg> added the comment:

Done, thank you!

Second version attached.

----------
Added file: http://bugs.python.org/file19712/getgeneratorstate_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:18:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 21:18:02 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1290287882.93.0.432567212173.issue10220@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Nice.  Now you can sit back, relax and wait for Nick to commit the patch or make further comments.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:22:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 21:22:21 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290288141.59.0.963852115833.issue10453@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Patch committed with minor formatting changes and one fixed test (test_force) in r86611.  Thanks, Michele!

----------
resolution:  -> accepted
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:24:19 2010
From: report at bugs.python.org (Cherniavsky Beni)
Date: Sat, 20 Nov 2010 21:24:19 +0000
Subject: [issue4246] execution model - clear and complete example in
	documentation
In-Reply-To: <1225551571.75.0.81232740458.issue4246@psf.upfronthosting.co.za>
Message-ID: <1290288259.26.0.254214183445.issue4246@psf.upfronthosting.co.za>


Cherniavsky Beni <cben at users.sf.net> added the comment:

The FAQ for this was much improved in 2009 (issue 7290): http://docs.python.org/py3k/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value

To support the claim that this keeps biting people, at least the following bug reports all came from people misundestanding this:
issue 10043
issue 9049
issue 7747
issue 7276
issue 6833
issue 5763
issue 4109 (understood effect of =, surprised by +=)
issue 972467
issue 850110
issue 463640
These are just the people who were persistent enough to open a bug (and in most cases managed to produce a minimal example); many more ask on c.l.p, StackOverflow (>50 hits for UnboundLocalError, many of which are this exact issue) etc., or just give up.

[Interesting point: people mostly complain when the unbound reference occurs textually *before* the assignment (though there's selection bias here), and many of them complain that things happen "out of order".  It seems half the misunderstanding is that people expect variables to *become* localized when first assigned - they don't understand it's a static decision affecting all occurences in a function.]

The central problem I believe is that when people try to modify a non-local var and get
  UnboundLocalError: local variable foo referenced before assignment
their mental model of Python scopes is *wrong*, so the error message is *useless* for them (what 'local variable foo' is it talking about?), and have no idea where to look next.

Also, I'm afraid people just won't internalize this issue until it bites them at least once (I've seen a Python course where I had explained this, with a print-before-assignment example, and 2 days later a student was bitten by the exception and was at a loss.  Therefore, I think providing a clear learning path from UnboundLocalError is crucial.

==>

I propose (i.e. am working on patch(s)) attacking it at many points:

(1) Expand UnboundLocalError message to point to help('NAMESPACES') 
    [Execution Model ? Naming and Binding] and/or the FAQ.
    (requirement IMHO: use a help() ref that can be followed the 
    from a Python prompt on an offline machine; not sure if FAQ can
    work this way.)

    (1B) Ideally, detect if the var is bound in outer/global scope 
         and suggest help('nonlocal') / help('global') approriately.

    (1C) Ideally, improve UnboundLocalError to explain "foo is local 
         throughout the function because it's bound at line 42".

(2) Add an example to Naming and Binding section.
    Currently, it's a bunch of legalese, defining 7 terms(!) before 
    you get to the meat.  Mortal users won't survive that.
    Being the language spec, the precise legalese must stay there;
    but it'd be good to prepend it with a human-readable blurb and 
    example regarding this issue.

(3) Improve the tutorial.  Sections 4.6 [Defining functions] and 9.2 
    [Scopes and Namespaces] are relevant.  4.6 mentions the issue of 
    assignment to global but neither section has a clear example.
    And 9.2 is scary IMHO; I'll see if I can make it any better...
    
(4) Add examples to documentation of global & nonlocal?
    Not clear if helpful, probably too much.

----------
nosy: +cben

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4246>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:29:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 21:29:30 +0000
Subject: [issue4246] execution model - clear and complete example in
	documentation
In-Reply-To: <1225551571.75.0.81232740458.issue4246@psf.upfronthosting.co.za>
Message-ID: <1290288570.42.0.819660391529.issue4246@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python -georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4246>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:33:17 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 21:33:17 +0000
Subject: [issue10469] test_socket fails
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290288797.95.0.109703872317.issue10469@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

Ok I did switched the preference for all "new" defines inside VC++ errno.h to use the WSA* alternatives if available.

Now test_socket passes for me, and the test_asyncore which did block before, now passes without a problem.

----------
Added file: http://bugs.python.org/file19713/issue10469.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:33:48 2010
From: report at bugs.python.org (John Keyes)
Date: Sat, 20 Nov 2010 21:33:48 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1290288828.56.0.0912510657618.issue809163@psf.upfronthosting.co.za>


John Keyes <johnkeyes at gmail.com> added the comment:

I see that distutils.tests.support.TempdirManager uses tempfile for directory creation.

What's the best course of action here? 

1. Use TESTFN or
2. Use TempdirManager or
3. Change the test to use TempdirManager and change TempdirManager to use TESTFN instead of tempfile.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:35:26 2010
From: report at bugs.python.org (Neal Norwitz)
Date: Sat, 20 Nov 2010 21:35:26 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1290287480.86.0.564884877441.issue10399@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Nt0K+T3Zr9aBv7yT9RTKBcKjme1vdttZ+A1R9@mail.gmail.com>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

There is some precedent for allowing minor differences in -O mode.
http://mail.python.org/pipermail/python-dev/2008-February/077193.html

I think we should push this to see how practical we can make it.
Dave, this is great work, I'm really interested to see you continue to
make progress and get something integrated.  Keep up the good work.

On Sat, Nov 20, 2010 at 1:11 PM, Dave Malcolm <report at bugs.python.org> wrote:
>
> Dave Malcolm <dmalcolm at redhat.com> added the comment:
>
> Thanks for reading through this.
>
>> There are a couple places you mention not doing the optimization when
>> specific functions are used (e.g. dir, globals, locals), how exactly do you
>> verify that, given those functions could be bound to any name?
>
> I don't: I'm only looking at explicit references to these global names:
> ? BUILTINS_THAT_READ_LOCALS = {'locals', 'vars', 'dir'}
>
> but I haven't attempted to track these at the object level, just at the name level.
>
> This means that if someone is passing these around bound to a different name, the results could be "wrong": the optimizations that I'm doing are synthesizing new local and global variables (in each case with a '__' prefix), and sometimes eliminating local variables.
>
> However, it should work as expected for the simple and common case for code like this:
>
> ?def foo():
> ? ? ?...
> ? ? ?pprint(locals())
> ? ? ?...
>
> since the reference to "locals" can be seen at the name level.
>
> But it won't work for something like this:
>
> ? def inlined_fn(a):
> ? ? ? print(a())
>
> ? def not_inlinable_for_some_reason(b):
> ? ? ? inlined_fn(b) # assume this callsite is inlined
>
> ? def some_other_fn_perhaps_in_another_module():
> ? ? ? hidden_ref_to_locals = locals
> ? ? ? not_inlinable_for_some_reason(hidden_ref_to_locals)
>
> in that (if inlining happens) the local printed will be named "b", rather than "a".
>
> But this seems to me like a contrived example: how often in real code do people pass around these builtins, rather than calling them directly? ?I myself use them for debugging, but I only ever call them directly.
>
> At a high level, what I'm interested in is providing additional benefits for python 3 relative to python 2 (to encourage migration), and I picked speed-ups.
>
> I think it's reasonable to provide some kind of "optimized" mode that is allowed to take (limited) liberties with the language.
>
> Note that with other languages, people seem to accept some mild degradation of debuggability in return for compiler optimizations. ?I'd like to be able to provide a faster python under similar kinds of tradeoffs.
>
> Currently, Python's optimized mode doesn't seem to do much (just compile away assertions iirc). ?Perhaps these optimizations could be associated with the pre-existing optimizer flag; alternatively, perhaps a 3rd level could be provided?
>
> This seems like a PEP-level request, but here's an outline of my thoughts here:
>
> I'd like the highly-optimized mode to be permitted the following::
> ?- to create additional synthesized globals, with a "__" prefix; modification of these globals to lead to undefined behavior.
> ?- when querying locals under some circumstances (see below) for locals to not be present, or for additional locals to be present::
> ? ? - when using "inspect" and reading/modifying a Frame's f_locals
> ? ? - in "non-direct" invocations of "locals", "globals" and "dir" (however, when called directly by name, they must work)
> ? ? - as per globals, synthesized locals to have a prefix, and modification to lead to undefined behavior
> ?- a pony :)
> ?- more seriously, I'm planning to look next at inlining method calls (within one module), and type inference, and I may come up with additional requirements.
>
> I believe that the above covers all of the places where my patch is taking liberties with existing Python semantics (modulo bugs): I'm still supporting runtime rebinding of other names, and (I believe), preserving existing behavior. ?(please let me know if I'm missing something here!)
>
> There seems to be some precedent for this:
> http://docs.python.org/library/functions.html states:
>> Note Because dir() is supplied primarily as a convenience for use at an
>> interactive prompt, it tries to supply an interesting set of names more
>> than it tries to supply a rigorously or consistently defined set of names,
>> and its detailed behavior may change across releases. For example,
>> metaclass attributes are not in the result list when the argument is a class.
>
> and for locals() it warns:
>> Note The contents of this dictionary should not be modified; changes may not
>> affect the values of local and free variables used by the interpreter.
>
> Does this sound sane? (obviously, actually approving this would be a matter for the BDFL).
>
> Perhaps all synthesized vars could have a "__internal__" prefix to signify that they should be left alone.
>
>
> The other PEP-level request would be for the highly-optimized mode to be permitted to take human-noticable time to generate its bytecode (rather than being "instantaneous"). ?I don't know if that's needed yet: the inliner is currently just a prototype, and I don't have any heuristics yet for deciding whether to inline a callsite (beyond an arbitrary cutoff I put in to stop bm_simple_call from "exploding"); I'm probably introducing various O(N^2) time/space behaviors (and worse) right now.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10399>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:37:22 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 20 Nov 2010 21:37:22 +0000
Subject: [issue10472] Strange tab key behaviour in interactive python 2.7 OSX
	10.6.2
In-Reply-To: <1290286054.61.0.644814416061.issue10472@psf.upfronthosting.co.za>
Message-ID: <1290289042.39.0.668759918027.issue10472@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The problem you see is with the 2.7 64-/32-bit OS X installer and is documented and will be fixed with the patch in Issue9907.  In the meantime, a workaround is to delete the installed 2.7 framework and install the 32-bit-only version which is built with GNU readline.

----------
nosy: +ned.deily
resolution:  -> duplicate
status: open -> closed
superseder:  -> interactive mode TAB does not insert on OS X built with editline instead of GNU readline

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10472>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:45:41 2010
From: report at bugs.python.org (Iuri Diniz)
Date: Sat, 20 Nov 2010 21:45:41 +0000
Subject: [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1290289541.19.0.393690118497.issue9746@psf.upfronthosting.co.za>


Iuri Diniz <iuridiniz at gmail.com> added the comment:

Is this bug valid? 

I have checked that only bytearray, bytes, list, range, str and tuple are valid sequence types [using issubclass(type, collections.Sequence)] and all of them has index and count methods... 

I'm working on a script to discovery what types that are not collections.Sequence ABC yet, but must be.

Merwork said the docs are the authoritative reference to define what classes are sequences and one way to discovery it is by comparing the set of methods of each concrete class with the methods of collections.Sequence

----------
nosy: +iuridiniz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9746>
_______________________________________

From report at bugs.python.org  Sat Nov 20 22:57:39 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Sat, 20 Nov 2010 21:57:39 +0000
Subject: [issue6007] distutils tricks you into thinking you can	build
	extensions with mingw
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <1290290259.98.0.0430480456098.issue6007@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

I'm attaching a patch that includes a disclaimer about some extensions not being able to compile and mentioning some of Martin's specifics.

I also reorganized the instructions to more directly reflect the current state. This puts the common instructions front and center and makes it more clear which instructions are directed at users of old python and MingGW versions. We might want to take those instructions out altogether given that the versions mentioned are pretty old (circa 2005).

----------
keywords: +patch
Added file: http://bugs.python.org/file19714/updated_mingw_docs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6007>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:01:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 22:01:15 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1290290475.88.0.459823734408.issue809163@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

TempdirManager hasn?t caused buildbots failures so far, so there is no need to change it.  You can use it, it?s convenient and works :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:05:30 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 20 Nov 2010 22:05:30 +0000
Subject: [issue7804] test_readline failure
In-Reply-To: <1264773697.69.0.94250627584.issue7804@psf.upfronthosting.co.za>
Message-ID: <1290290730.56.0.823812079879.issue7804@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I can't reproduce it either any more on Ubuntu 10.10 in either 2.6 or py3k.

----------
resolution:  -> out of date
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7804>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:07:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 22:07:14 +0000
Subject: [issue6007] distutils tricks you into thinking you can build
	extensions with mingw
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <1290290834.07.0.385786541846.issue6007@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

distutils docs only get changes that fix a bug (e.g. an example that does not work), not improvements or reorganization.  Your patch is in a gray area; I think we should not accept it in distutils but re-target it at distutils2.  Even if you refresh it against distutils2, I will wait for an agreement between Jean-Paul and Martin before committing it, since I can?t assess the situation alone.  Thank your for your wanting to help.

----------
nosy: +eric.araujo
title: distutils tricks you into thinking you can	build extensions with mingw -> distutils tricks you into thinking you can build extensions with mingw

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6007>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:08:25 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Sat, 20 Nov 2010 22:08:25 +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: <1290290905.81.0.10319937903.issue10367@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

It looks to me as though this patch reintroduces issue9199, as it passes multiple arguments to self.announce() once again.  The patch needs to be made against the SVN version of Python, not the released version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:12:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Nov 2010 22:12:29 +0000
Subject: [issue10448] Add Mako template benchmark to Python Benchmark Suite
In-Reply-To: <1290021787.45.0.410966544451.issue10448@psf.upfronthosting.co.za>
Message-ID: <1290291149.59.0.721431853167.issue10448@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Pushed in 40e80cede832, thank you.
(2to3'ed Mako appears 3x slower than on 2x, but it's not obvious whether it's Python 3 itself or the constructs added by 2to3; I think running 2to3ed benchmarks is a bit pointless in itself, because it's not idiomatic code)

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10448>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:15:19 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 22:15:19 +0000
Subject: [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1290291319.08.0.201821052093.issue9746@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Here is the patch for the table in Doc/library/stdtypes.rst

.count on range by some reason returns a boolean. Should it not be an int?

----------
keywords: +patch
nosy: +SilentGhost
Added file: http://bugs.python.org/file19715/stdtypes.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9746>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:16:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 22:16:32 +0000
Subject: [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1290291392.97.0.744979077372.issue9746@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Doc patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9746>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:21:39 2010
From: report at bugs.python.org (Wes Chow)
Date: Sat, 20 Nov 2010 22:21:39 +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: <1290291699.31.0.191279489027.issue4493@psf.upfronthosting.co.za>


Wes Chow <wes.chow at gmail.com> added the comment:

Attached is a patch against 3.2 that replaces empty paths with '/' in HTTPConnection. I do not totally understand the ; syntax in URIs, and so this implementation may break that, as it splits urls and unsplits them if needed. The Python docs seem to indicate there might be some obscure cases where this is problematic.

And yes, I do realize that this patch fixes the problem in yet another place. Hopefully HTTPConnection is the lowest common denominator.

----------
keywords: +patch
nosy: +weschow
Added file: http://bugs.python.org/file19716/empty-path-4493.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4493>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:23:20 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sat, 20 Nov 2010 22:23:20 +0000
Subject: [issue10469] test_socket fails using Visual Studio 2010
In-Reply-To: <1290263082.19.0.540702085336.issue10469@psf.upfronthosting.co.za>
Message-ID: <1290291800.18.0.444660992538.issue10469@psf.upfronthosting.co.za>


Changes by Daniel Albeseder <kotan at gmx.at>:


----------
title: test_socket fails -> test_socket fails using Visual Studio 2010

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10469>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:25:45 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Sat, 20 Nov 2010 22:25:45 +0000
Subject: [issue1043134] mimetypes.guess_extension('text/plain') == '.ksh' ???
Message-ID: <1290291945.51.0.909908617775.issue1043134@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

While I agree that getting .ksh is an unfortunate guess, I am not sure how you can guess in the face of many options (especially when the those options are parsed out of a mimetypes file or the windows registry). 

Perhaps there should be a "resonable_defaults" map that is checked first for very basic types where there are multiple extensions for a type?

----------
nosy: +lambacck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1043134>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:27:00 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 22:27:00 +0000
Subject: [issue10474] range.count returns boolean
In-Reply-To: <1290292020.04.0.782370247504.issue10474@psf.upfronthosting.co.za>
Message-ID: <1290292020.04.0.782370247504.issue10474@psf.upfronthosting.co.za>


New submission from SilentGhost <michael.mischurow+bpo at gmail.com>:

>>> a = range(5)
>>> a.count(5)
False
>>> a.count(2)
True

I believe this is related to the issue9213 that introduced count and index method on the range object. According to the documentation accompanying that fix it should return an integer.

----------
components: Interpreter Core
messages: 121799
nosy: SilentGhost
priority: normal
severity: normal
status: open
title: range.count returns boolean
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10474>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:27:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 20 Nov 2010 22:27:18 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1290292038.14.0.150569770801.issue10441@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Martin,

> You misunderstood. I was not proposing that scripts provide a CA
> list, but that users might deploy a CA list into their Python
> installation, which is then picked up in the same way as you are asking
> for on Ubuntu.

Could you elaborate on what kind of scheme you are proposing?

It should be noted that the default OpenSSL paths can be modified at runtime using environment variables SSL_CERT_FILE and SSL_CERT_DIR. Not sure we should document this, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:30:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 22:30:48 +0000
Subject: [issue1043134] mimetypes.guess_extension('text/plain') == '.ksh' ???
Message-ID: <1290292248.55.0.261025707115.issue1043134@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/issue1043134>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:31:41 2010
From: report at bugs.python.org (Iuri Diniz)
Date: Sat, 20 Nov 2010 22:31:41 +0000
Subject: [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1290292301.04.0.1914070778.issue9746@psf.upfronthosting.co.za>


Iuri Diniz <iuridiniz at gmail.com> added the comment:

Well, I think that script not more necessary

count problem: Issue10474

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9746>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:35:06 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sat, 20 Nov 2010 22:35:06 +0000
Subject: [issue10474] range.count returns boolean
In-Reply-To: <1290292020.04.0.782370247504.issue10474@psf.upfronthosting.co.za>
Message-ID: <1290292506.0.0.903244515134.issue10474@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/issue10474>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:36:08 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Nov 2010 22:36:08 +0000
Subject: [issue10474] range.count returns boolean
In-Reply-To: <1290292020.04.0.782370247504.issue10474@psf.upfronthosting.co.za>
Message-ID: <1290292568.53.0.47609854689.issue10474@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r86618

----------
nosy: +benjamin.peterson
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10474>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:36:13 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Nov 2010 22:36:13 +0000
Subject: [issue10474] range.count returns boolean
In-Reply-To: <1290292020.04.0.782370247504.issue10474@psf.upfronthosting.co.za>
Message-ID: <1290292573.88.0.929434220831.issue10474@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10474>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:40:01 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 20 Nov 2010 22:40:01 +0000
Subject: [issue10474] range.count returns boolean
In-Reply-To: <1290292020.04.0.782370247504.issue10474@psf.upfronthosting.co.za>
Message-ID: <1290292801.6.0.172471353218.issue10474@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Benjamin, the docs say that it's possible to have count more than 1, depending on comparison rules. If that's the case, I'm afraid your solution might need to be adjusted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10474>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:41:17 2010
From: report at bugs.python.org (Cherniavsky Beni)
Date: Sat, 20 Nov 2010 22:41:17 +0000
Subject: [issue10043] UnboundLocalError with local variable set by setattr,
	caused by code run later
In-Reply-To: <1286446430.16.0.85312530766.issue10043@psf.upfronthosting.co.za>
Message-ID: <1290292877.85.0.105858080428.issue10043@psf.upfronthosting.co.za>


Cherniavsky Beni <cben at users.sf.net> added the comment:

Hi Steven.
Please confirm if we can mark the bug closed; if you need farther advice, posting your full code (not just the error case) on comp.lang.python or StackOverflow would be more effective.

The documentation is indeed correct but hard to find (you're not the first to be surprised by UnboundLocalError); I'm working on making things more discoverable in issue 4246.
See also http://docs.python.org/py3k/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value

First of all, it's important to understand that a Python function has a *fixed* set of local variables, frozen when the function is parsed.  If you assign to it (e.g. ``name = None``), *all* appearances of the name in the function refer to a local variable; if not, they refer to the outer scope.
Therefore, you can't achieve what you want with local variables.

Generally, dynamically creating variables is a bad programming practice.  A dictionary is the cleanest way to hold a set of names/values that is not fixed.  Yes, you'll have to write ``cols['foo']`` instead of ``foo``; OTOH, setting them will not require any ugly magic...
Note also that string formatting can use values from a dictionary with very conveniently: ``"... {foo} ...".format(**cols)``.

The next best thing if ``cols['foo']`` is too verbose for you is ``cols.foo``: create an object which will contain the values as instance variables (that's a good use for setattr()).
This is the most Pythonic solution if a dictionary doesn't suffice - it's what most object-relational mappers do.

The third idea is to (ab)use a class statement.  A class statement in Python creates a temporary namespace *during the class definition* (we'll not be defining any methods or using it object-oriented stuff).
And the nice part is that you can put a class statement anywhere, even inside a function:
    def f():
        cols = {'foo': 42}  # however you fetch them...
	class temp_namespace:
            locals().update(cols)
            print(foo / 6)     # prints 7.0
        assert 'foo' not in locals()  # no effect outside the class!
This works both in CPython 2 and 3.  I'm not 100% sure that being able to change locals() in a class is guaranteed in all other implementations.  (Note again that locals() of a *function* are not a real dictionary and you *can't* change them - as I said these are fixed when the function is defined.)

The fourth idea if you must have code that says just ``foo`` to access columns is to use the exec statement - you can pass it a dictionary that will serve as globals and/or locals.  An upside is that the code will be a string and can be dynamic as well.

(BTW, if the code is not dynamic, how come you don't know the names you're accessing?  If you do, you could just set ``foo = cols['foo']`` etc. for every variable you need - tedious but no magic needed.)

Lastly, as you discovered you can dynamically create global variables.  
(As Terry said, just use the dictionary returned by ``globals()``; no need for setattr).
But this is a very last resort (changing globals for a single function is ugly), and somewhat dangerous - e.g. consider what happens if a column names changes and overwrites a function name you had...

----------
nosy: +cben

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10043>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:41:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 20 Nov 2010 22:41:59 +0000
Subject: [issue6007] distutils tricks you into thinking you can build
	extensions with mingw
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <1290292919.59.0.409777976675.issue6007@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The changes look fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6007>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:44:59 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 20 Nov 2010 22:44:59 +0000
Subject: [issue10474] range.count returns boolean
In-Reply-To: <1290292801.6.0.172471353218.issue10474@psf.upfronthosting.co.za>
Message-ID: <AANLkTim+zP+PPBJUirYoNvGa-AR0CS_VFEVV3hGDU6CU@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/11/20 SilentGhost <report at bugs.python.org>:
>
> SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:
>
> Benjamin, the docs say that it's possible to have count more than 1, depending on comparison rules. If that's the case, I'm afraid your solution might need to be adjusted.

Produce a case where that's true, and I'll fix it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10474>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:45:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 22:45:49 +0000
Subject: [issue10474] range.count returns boolean
In-Reply-To: <1290292020.04.0.782370247504.issue10474@psf.upfronthosting.co.za>
Message-ID: <1290293149.29.0.28117740673.issue10474@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

SilentGhost,

Benjamin's fix only affect the optimized path when the argument is int or bool.  Exotic comparison rules are handled in the else clause.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10474>
_______________________________________

From report at bugs.python.org  Sat Nov 20 23:58:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 22:58:09 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290293889.8.0.54883035795.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Invocation without arguments does not work.  I have a fix, I?ll add a test and commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:03:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 23:03:02 +0000
Subject: [issue10292] tarinfo should use relative symlinks
In-Reply-To: <1288677491.56.0.490634807811.issue10292@psf.upfronthosting.co.za>
Message-ID: <1290294182.45.0.91620434102.issue10292@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/issue10292>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:04:16 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sat, 20 Nov 2010 23:04:16 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290294256.52.0.811355635721.issue10453@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Sorry.

----------
Added file: http://bugs.python.org/file19717/issue10453_noargs.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:04:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 23:04:18 +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: <1290294258.2.0.938246747476.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Regarding your fix to copy_script, I will have to ask python-dev about PEP 291 in py3k (i.e., should 3.2 code really be compatible with 2.3?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:19:30 2010
From: report at bugs.python.org (John Keyes)
Date: Sat, 20 Nov 2010 23:19:30 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1290295170.54.0.907448976854.issue809163@psf.upfronthosting.co.za>


John Keyes <johnkeyes at gmail.com> added the comment:

This patch uses TempdirManager to handle the temporary directory and file creation.

----------
Added file: http://bugs.python.org/file19718/issue809163v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:19:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 23:19:42 +0000
Subject: [issue8645] PyUnicode_AsEncodedObject is undocumented
In-Reply-To: <1273247735.73.0.712345896243.issue8645@psf.upfronthosting.co.za>
Message-ID: <1290295182.04.0.846615876691.issue8645@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Document unicode C-API in reST

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8645>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:20:08 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Sat, 20 Nov 2010 23:20:08 +0000
Subject: [issue6007] distutils tricks you into thinking you can build
	extensions with mingw
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <1290295208.9.0.291977527884.issue6007@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

Eric,

This documentation is "Installing Python Modules" which is focused on Distutils, but presumably we would continue to want such a document and account for both Disutils and Disutils2 (once people start using it). 

I think my patch addresses the misleading content regarding the need to use pexports and dlltool and more directly instructs people that want to install the vast majority of current Python packages. If it is pertinent to update the docs for distutils2 I'll look at that as well but I think it is still useful to provide meaningful docs for what exists in distutils.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6007>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:20:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 23:20:12 +0000
Subject: [issue8646] PyUnicode_EncodeDecimal is undocumented
In-Reply-To: <1273247945.7.0.702043835904.issue8646@psf.upfronthosting.co.za>
Message-ID: <1290295212.71.0.504693498061.issue8646@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Document unicode C-API in reST

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8646>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:20:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 20 Nov 2010 23:20:47 +0000
Subject: [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1290295247.2.0.294198589984.issue8647@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> duplicate
superseder:  -> Document unicode C-API in reST

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8647>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:30:39 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 20 Nov 2010 23:30:39 +0000
Subject: [issue10043] UnboundLocalError with local variable set by setattr,
	caused by code run later
In-Reply-To: <1286446430.16.0.85312530766.issue10043@psf.upfronthosting.co.za>
Message-ID: <1290295839.42.0.473856239958.issue10043@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Closing, as I don't think there's any action item here.

----------
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10043>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:31:34 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 20 Nov 2010 23:31:34 +0000
Subject: [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1290295894.29.0.425506724806.issue9746@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Patch is fine.  Go ahead and apply.

----------
nosy: +rhettinger
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9746>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:35:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 20 Nov 2010 23:35:01 +0000
Subject: [issue8647] PyUnicode_GetMax is undocumented
In-Reply-To: <1273248439.66.0.594970239714.issue8647@psf.upfronthosting.co.za>
Message-ID: <1290296101.95.0.254515312764.issue8647@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8647>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:48:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 23:48:15 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290296895.51.0.600887388971.issue3709@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thanks for the patch and test.  They look good.

A doc update is also needed, since the docs are currently written in such a way that buffering the header lines makes the documentation no longer true.

Also, send_response_only writes directly to the output stream, it doesn't call send_header.  This breaks the buffering.  It also means that more test cases are needed, since the added test didn't catch this case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:48:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 23:48:27 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290296907.82.0.47938915849.issue3709@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:56:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 20 Nov 2010 23:56:35 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1290297395.69.0.937241249679.issue809163@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

TempdirManager is new, which is why I forgot about it.  It works with the buildbots because it is a context manager, so if things go badly the cleanup code is still going to run and delete the cruft.  Since the distutils tests are unlikely to hang (which is the only time the cleanup code would not get run), it should be perfectly fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Sun Nov 21 00:59:40 2010
From: report at bugs.python.org (Nicolas Joly)
Date: Sat, 20 Nov 2010 23:59:40 +0000
Subject: [issue10475] hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
In-Reply-To: <1290297580.46.0.357018780785.issue10475@psf.upfronthosting.co.za>
Message-ID: <1290297580.46.0.357018780785.issue10475@psf.upfronthosting.co.za>


New submission from Nicolas Joly <njoly at pasteur.fr>:

The configure script do hardcode compilers for LDSHARED/LDCXXSHARED on NetBSD, which should be avoided.

[...]
checking for gcc... gcc
checking whether gcc accepts -g... yes
[...]
checking SO... .so
checking LDSHARED... cc -shared 
checking CCSHARED... -fPIC
[...]

----------
components: Build
files: python-cc.diff
keywords: patch
messages: 121817
nosy: njoly
priority: normal
severity: normal
status: open
title: hardcoded compilers for LDSHARED/LDCXXSHARED on NetBSD
versions: Python 2.7
Added file: http://bugs.python.org/file19719/python-cc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10475>
_______________________________________

From report at bugs.python.org  Sun Nov 21 01:38:27 2010
From: report at bugs.python.org (Mark Roddy)
Date: Sun, 21 Nov 2010 00:38:27 +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: <1290299907.79.0.770595944106.issue10242@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

Adding patch for py3k which implements Raymond's suggested fix which utilizes collections.Counter.  

Have not changed the name of the assertion method as this seems as though it may be outside the scope of this issue, but I can produce another patch with the name change if desired.  Though how the old name should be deprecated needs to be addressed.

Note that it may make sense to reconsider the current failure message from this test to take into account the fact that the test could be failing due to the number of entries for a single value differing between the two sequences.  In this case the "Expected, bug missing..." or "Unexpected but present..." messages are still utilized but could be miss leading.

Also, holding off on porting to unittest2 until the above issues have been addressed (or at least confirmed to be non-issues).

----------
keywords: +patch
nosy: +MarkRoddy
Added file: http://bugs.python.org/file19720/py3k.10242.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10242>
_______________________________________

From report at bugs.python.org  Sun Nov 21 01:41:19 2010
From: report at bugs.python.org (Mark Roddy)
Date: Sun, 21 Nov 2010 00:41:19 +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: <1290300079.81.0.95754024358.issue10242@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

Adding patch for release27-maint branch which implements Raymond's suggested fix which utilizes collections.Counter.  

Has the same issues addressed with the py3k patch.

----------
Added file: http://bugs.python.org/file19721/py27.10242.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10242>
_______________________________________

From report at bugs.python.org  Sun Nov 21 01:42:45 2010
From: report at bugs.python.org (Julian)
Date: Sun, 21 Nov 2010 00:42:45 +0000
Subject: [issue10476] __iter__ on a byte file object using a method to return
	an iterator
In-Reply-To: <1290300165.3.0.545545019254.issue10476@psf.upfronthosting.co.za>
Message-ID: <1290300165.3.0.545545019254.issue10476@psf.upfronthosting.co.za>


New submission from Julian <Julian+Python.org at GrayVines.com>:

Iterating over a byte file object using __iter__ is rather useless, and a bit confusing perhaps.

It'd be nice to propose two things:

1. Having __iter__ raise an exception if the file was opened with the "b" flag.

2. Adding a new by_bytes() method to file objects, which would return an iterator that yielded the next byte in the file, introducing the ability to write a similar `for byte in byte_file_obj.by_bytes()` that is currently possible when iterating by line over non-byte files.

It's quite easy to do (2) currently, obviously, but perhaps it's worthy of consideration for inclusion.

----------
components: IO
messages: 121820
nosy: Julian
priority: normal
severity: normal
status: open
title: __iter__ on a byte file object using a method to return an iterator
type: feature request
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10476>
_______________________________________

From report at bugs.python.org  Sun Nov 21 01:46:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 00:46:11 +0000
Subject: [issue9746] All sequence types support .index and .count
In-Reply-To: <1283455166.89.0.79459833906.issue9746@psf.upfronthosting.co.za>
Message-ID: <1290300371.69.0.607966739451.issue9746@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch committed in r86625 (py3k), r86627 (3.1) and r86627 (2.7).

Regarding API conformance, I ran this simple test, courtesy of Daniel in msg109784:

>>> for cls in str, bytes, bytearray, list, tuple, range:
...     print(cls, [method for method in set(dir(collections.Sequence)) - set(dir(cls)) if not method.startswith('_')])
... 
<class 'str'> []
<class 'bytes'> []
<class 'bytearray'> []
<class 'list'> []
<class 'tuple'> []
<class 'range'> []

Which means we can close this.  Thanks everyone!

----------
resolution: accepted -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9746>
_______________________________________

From report at bugs.python.org  Sun Nov 21 01:51:52 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 00:51:52 +0000
Subject: [issue10476] __iter__ on a byte file object using a method to return
	an iterator
In-Reply-To: <1290300165.3.0.545545019254.issue10476@psf.upfronthosting.co.za>
Message-ID: <1290300712.29.0.897529716446.issue10476@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, an idiom I use in Py2.x is:

   for block in iter(partial(f.read, BLKSIZ), ''):
        . . .

This works with both single bytes at time and multiple bytes at a time.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10476>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:02:16 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 21 Nov 2010 01:02:16 +0000
Subject: [issue10476] __iter__ on a byte file object using a method to return
	an iterator
In-Reply-To: <1290300165.3.0.545545019254.issue10476@psf.upfronthosting.co.za>
Message-ID: <1290301336.91.0.195103483176.issue10476@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

BufferedIOBase readline and __iter__ has to stay for backwards compatibility (especially with python 2). As for by_bytes(), I suggest you post it to python-ideas.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10476>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:02:52 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 01:02:52 +0000
Subject: [issue9909] request for calendar.dayofyear() function
In-Reply-To: <1285039663.27.0.59327234025.issue9909@psf.upfronthosting.co.za>
Message-ID: <1290301372.15.0.242430720184.issue9909@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

"We already got one, and it's very nice-a"

ISTM, this should be done with regular date arithmetic in the datetime module.

>>> date(1964, 7, 31) - date(1963, 12, 31)
datetime.timedelta(213)

I don't see why we need a new function for this or why it would be put in the calendar module (where some of its functions have been supplanted by the datetime module).

----------
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9909>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:14:54 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Sun, 21 Nov 2010 01:14:54 +0000
Subject: [issue6799] mimetypes does not give cannonical extension for
	guess_extension with text/plain
In-Reply-To: <1251504611.25.0.614751141151.issue6799@psf.upfronthosting.co.za>
Message-ID: <1290302094.6.0.937079583185.issue6799@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

This is a dup of #1043134

----------
nosy: +lambacck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6799>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:15:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 01:15:53 +0000
Subject: [issue6799] mimetypes does not give canonical extension for
	guess_extension with text/plain
In-Reply-To: <1251504611.25.0.614751141151.issue6799@psf.upfronthosting.co.za>
Message-ID: <1290302153.77.0.136634164515.issue6799@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage: needs patch -> committed/rejected
status: open -> closed
superseder:  -> mimetypes.guess_extension('text/plain') == '.ksh' ???
title: mimetypes does not give cannonical extension for guess_extension with text/plain -> mimetypes does not give canonical extension for guess_extension with text/plain

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6799>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:20:41 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Sun, 21 Nov 2010 01:20:41 +0000
Subject: [issue6434] buffer overflow in Zipfile when wrinting more than 2gig
	file
In-Reply-To: <1246986659.26.0.972556799924.issue6434@psf.upfronthosting.co.za>
Message-ID: <1290302441.7.0.0268686191913.issue6434@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

This should be closed as a dup of #1182788 which the OP identified as being the same bug and which is now fixed due to the implementation. of ZIP64.

----------
nosy: +lambacck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6434>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:21:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 01:21:17 +0000
Subject: [issue9435] test_distutils fails without zlib
In-Reply-To: <1280590585.97.0.266735291444.issue9435@psf.upfronthosting.co.za>
Message-ID: <1290302477.76.0.36290403485.issue9435@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This can be kept open as a separate report, since it was caused by the Big Distutils Revert in 3.2.  We?ve already discussed how to fix that in private email and IRC thanks to Ezio.  Because of compat requirements, we?ll probably have to use if+return instead of skipIf.

----------
assignee: tarek -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9435>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:23:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 01:23:39 +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: <1290302619.07.0.900856743415.issue10367@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
superseder: distutils upload command crashes when displaying server response -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10367>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:39:55 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 21 Nov 2010 01:39:55 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290303595.9.0.1650072349.issue7094@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This is the patch developed today at the DCPython sprint. I have not reviewed it very well. I know that at least:
- formatting is not consistent
- the docs need reviewing
- I want to add more tests
- Misc/NEWS and Misc/ACKS need updating

But I'm uploading it here anyway so that it doesn't get lost. I'll be refining the patch over the next several days. The patch covers float, complex, and decimal.

Thanks to:
Eric Groo
Vlad Korolev
Bob Schmertz
Owen Martin

----------
keywords: +patch
Added file: http://bugs.python.org/file19722/issue7094.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:40:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 01:40:32 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290303632.22.0.852558695469.issue5800@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, note that ?svn diff file1 file2...? will give you one file for many edits.  It?s easier to review and apply.

Regarding the change, I don?t know if wsgiref 3.2 has to be compatible with Python 2.1, which would exclude using the ternary operation.

The change from type to isinstance will probably be rejected, since WSGI does not accept subclasses for the things it defines.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:42:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 01:42:28 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290303748.3.0.72288268385.issue7094@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/issue7094>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:46:41 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 01:46:41 +0000
Subject: [issue10473] Strange behavior for socket.timeout
In-Reply-To: <1290286456.52.0.376414349457.issue10473@psf.upfronthosting.co.za>
Message-ID: <1290304001.35.0.619514711074.issue10473@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

There is a difference in behavior in the accept() socket call between Linux and BSD systems (including OS X). As documented in the Debian Linux man page for accept(2):  "On Linux, the new socket returned by accept() does not inherit file status flags such as O_NONBLOCK and O_ASYNC from the listening socket.  This behavior differs from the canonical BSD sockets implementation.   Portable  programs should not rely on inheritance or noninheritance of file status flags and always explicitly set all required flags on the socket returned from accept()."

Calling the settimeout method with a positive, non-zero value causes Modules/setsocketmodule.c to set O_NONBLOCK on the listening socket.  On BSDish systems, the accepted socket for the incoming connection inherits that attribute, which causes the recv(2) socket call to return EAGAIN when the received bytes are consumed rather than block, which causes the socket modules SocketIO.readinto() to return None up the chain, which ultimately causes io.TextIOWrapper.readline() to return all that it has received regardless of whether a newline character was received.

It is for that reason that socket.makefile() is documented: "The socket must be in blocking mode (it can not have a timeout)."  Because of the inheritance behavior, the test case fails to adhere to that.
 
http://docs.python.org/py3k/library/socket.html#socket.socket.makefile

----------
nosy: +ned.deily
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10473>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:52:54 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Sun, 21 Nov 2010 01:52:54 +0000
Subject: [issue3636] Managing dual 2.x and 3.0 installations on Windows
In-Reply-To: <1219350265.84.0.067322027975.issue3636@psf.upfronthosting.co.za>
Message-ID: <1290304374.32.0.406342469298.issue3636@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

This seems like a normal file association fight, no different than not being able to have both IE and Firefox associated with .html files.

#2375 has been rejected, so I don't think it is a relevant superseder.

I don't see how this is any different than having multiple 2.x installations and needing to pick the current one to work with. If 2.3 were the default and I tried to run a script with decorators I would end up with the same result.

----------
nosy: +lambacck

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3636>
_______________________________________

From report at bugs.python.org  Sun Nov 21 02:54:32 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sun, 21 Nov 2010 01:54: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: <1290304472.7.0.149017161043.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101121.zip is a new version of the regex module.

The captures didn't work properly with lookarounds or atomic groups.

----------
Added file: http://bugs.python.org/file19723/issue2636-20101121.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:05:03 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 02:05:03 +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: <1290305103.54.0.960823037235.issue7322@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This would seem to be an invalid test case.  It is specifically documented that socket.makefile does not support this: "The socket must be in blocking mode (it can not have a timeout)".

http://docs.python.org/py3k/library/socket.html#socket.socket.makefile

I suppose socket.makefile could initially check the socket and throw an exception if the socket is non_blocking but the program could later change the socket to non_blocking and the same issue would presumably arise.  

Recommend closing as invalid.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:09:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 02:09:02 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1290305342.0.0.668496482117.issue969718@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> tarek
components: +Distutils2
nosy: +eric.araujo
versions: +3rd party, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue969718>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:12:35 2010
From: report at bugs.python.org (Roy Smith)
Date: Sun, 21 Nov 2010 02:12:35 +0000
Subject: [issue10473] Strange behavior for socket.timeout
In-Reply-To: <1290286456.52.0.376414349457.issue10473@psf.upfronthosting.co.za>
Message-ID: <1290305555.1.0.644740982387.issue10473@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

Thank you for the detailed analysis.  That certainly explains what I observed.

Would it make sense for socket.makefile() to check to see if the socket is in blocking mode (assuming there is some reliable/portable way to perform this check), and raise some exception if it is not?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10473>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:13:43 2010
From: report at bugs.python.org (Mark Roddy)
Date: Sun, 21 Nov 2010 02:13:43 +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: <1290305623.19.0.795739165684.issue7911@psf.upfronthosting.co.za>


Mark Roddy <markroddy at gmail.com> added the comment:

Current patch has grown stale.  Attaching a newer one.

----------
nosy: +MarkRoddy
Added file: http://bugs.python.org/file19724/py3k.7911.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7911>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:19:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Nov 2010 02:19:04 +0000
Subject: [issue10476] __iter__ on a byte file object using a method to return
	an iterator
In-Reply-To: <1290300165.3.0.545545019254.issue10476@psf.upfronthosting.co.za>
Message-ID: <1290305944.15.0.597490434005.issue10476@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For the record, I don't find the behavior of __iter__ on a binary file at all confusing.  It's the same behavior I see if I open the file in, say, vi.  So it is in fact the behavior I expect, and I would be surprised if it didn't work.

Whether it is *useful* is a different story, but I'd be willing to bet that there are or will be python3 programs that do use it.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10476>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:21:12 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 02:21:12 +0000
Subject: [issue10473] Strange behavior for socket.timeout
In-Reply-To: <1290286456.52.0.376414349457.issue10473@psf.upfronthosting.co.za>
Message-ID: <1290306072.12.0.143341095541.issue10473@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

As I commented over on Issue7322, I think any such test would be not perfect since I believe the blocking status of the socket could be changed at any time, at least on Unix-y systems.  So I'm +0 on whether adding a test in makefile() is worth it, presuming it can be done on all platforms.  If you feel like trying it, I'd recommend adding it to Issue7322 and see what others think.  It certainly wouldn't hurt if it can be done.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10473>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:23:06 2010
From: report at bugs.python.org (david)
Date: Sun, 21 Nov 2010 02:23:06 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1290292038.14.0.150569770801.issue10441@psf.upfronthosting.co.za>
Message-ID: <AANLkTimiux1qP3qFJaHUTkyf9DMDhDi0JgvSH1Yt97+d@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

On 21 November 2010 09:27, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Martin,
>
>> You misunderstood. I was not proposing that scripts provide a CA
>> list, but that users might deploy a CA list into their Python
>> installation, which is then picked up in the same way as you are asking
>> for on Ubuntu.
>
> Could you elaborate on what kind of scheme you are proposing?
>
> It should be noted that the default OpenSSL paths can be modified at runtime using environment variables SSL_CERT_FILE and SSL_CERT_DIR. Not sure we should document this, though.

Sorry is this question aimed at me?
No I was saying that if we can't move to a sane default then an
environmental setting or other configuration maybe nice to have to
enforce certificate checking etc.
It had nothing to do with those variables, but perhaps we would use them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:36:06 2010
From: report at bugs.python.org (Roy Smith)
Date: Sun, 21 Nov 2010 02:36:06 +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: <1290306966.59.0.254522733654.issue7322@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

This is kind of ugly.  On the one hand, I'm all for adding a check in makefile() to catch it being called on a non-blocking socket.

On the other hand, you are correct that a user could change the mode leter.  Even if we added checks for this in socket.setblocking(), there's plenty of ways to get around that; it's easy to grab a raw file descriptor and do whatever you want with it behind the library's back.

On the third hand, maybe a check could be added to SocketIO.readinto() to verify that the socket was in blocking mode each time it was called?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:39:08 2010
From: report at bugs.python.org (Savio Sena)
Date: Sun, 21 Nov 2010 02:39:08 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1290307148.12.0.726949402881.issue1745035@psf.upfronthosting.co.za>


Changes by Savio Sena <savio.sena at acm.org>:


----------
nosy: +saviosena

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:45:57 2010
From: report at bugs.python.org (Drakonnen)
Date: Sun, 21 Nov 2010 02:45:57 +0000
Subject: [issue10477] AttributeError: 'NoneType' object has no attribute
	'name' (bonenode.name)
In-Reply-To: <1290307557.36.0.502184693824.issue10477@psf.upfronthosting.co.za>
Message-ID: <1290307557.36.0.502184693824.issue10477@psf.upfronthosting.co.za>


New submission from Drakonnen <drakonnen at yahoo.com>:

Trying to import a .nif into Blender, for Oblivion mod work, I get the following error:

Blender NIF Scripts 2.5.5 (running on Blender 249, PyFFI 2.1.6)
pyffi.toaster:INFO:--- fix_mergeskeletonroots ---
pyffi.toaster:INFO:  ~~~ NiNode [Scene Root] ~~~
pyffi.toaster:INFO:--- fix_sendgeometriestobindposition ---
pyffi.toaster:INFO:  ~~~ NiNode [Scene Root] ~~~
pyffi.toaster:INFO:    sending geometries to bind position
Traceback (most recent call last):
  File "C:\Program Files (x86)\Blender Foundation\Blender\.blender\scripts\bpymo
dules\nif_common.py", line 1227, in gui_button_event
    self.gui_exit()
  File "C:\Program Files (x86)\Blender Foundation\Blender\.blender\scripts\bpymo
dules\nif_common.py", line 1579, in gui_exit
    self.callback(**self.config)
  File "C:\Program Files (x86)\Blender Foundation\Blender\.blender\scripts\impor
t\import_nif.py", line 3750, in config_callback
    importer = NifImport(**config)
  File "C:\Program Files (x86)\Blender Foundation\Blender\.blender\scripts\impor
t\import_nif.py", line 274, in __init__
    self.import_root(root)
  File "C:\Program Files (x86)\Blender Foundation\Blender\.blender\scripts\impor
t\import_nif.py", line 309, in import_root
    pyffi.spells.nif.fix.SpellSendGeometriesToBindPosition(data=data).recurse()
  File "C:\Python26\lib\site-packages\pyffi\spells\__init__.py", line 289, in re
curse
    self.recurse(child)
  File "C:\Python26\lib\site-packages\pyffi\spells\__init__.py", line 298, in re
curse
    if self.branchentry(branch):
  File "C:\Python26\lib\site-packages\pyffi\spells\nif\__init__.py", line 135, i
n branchentry
    self.skelrootentry(branch)
  File "C:\Python26\lib\site-packages\pyffi\spells\nif\fix.py", line 380, in ske
lrootentry
    branch.send_geometries_to_bind_position()
  File "C:\Python26\lib\site-packages\pyffi\formats\nif\__init__.py", line 5106,
 in send_geometries_to_bind_position
    if bonenode.name in bone_bind_transform:
AttributeError: 'NoneType' object has no attribute 'name'

----------
components: Windows
messages: 121840
nosy: Drakonnen
priority: normal
severity: normal
status: open
title: AttributeError: 'NoneType' object has no attribute 'name'  (bonenode.name)
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10477>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:47:39 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 02:47:39 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1290307659.29.0.438268260601.issue7770@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Added a comment to the docstring.
See r86631.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:49:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 02:49:31 +0000
Subject: [issue10477] AttributeError: 'NoneType' object has no attribute
	'name' (bonenode.name)
In-Reply-To: <1290307557.36.0.502184693824.issue10477@psf.upfronthosting.co.za>
Message-ID: <1290307771.95.0.390114715002.issue10477@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is not a bug in Python but in the third-party pyffi project.  Please report it to them.

----------
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10477>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:50:49 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 02:50:49 +0000
Subject: [issue7770] sin/cos function in decimal-docs
In-Reply-To: <1264338591.28.0.648611321802.issue7770@psf.upfronthosting.co.za>
Message-ID: <1290307849.75.0.167877027834.issue7770@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7770>
_______________________________________

From report at bugs.python.org  Sun Nov 21 03:54:05 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 21 Nov 2010 02:54:05 +0000
Subject: [issue9969] tokenize: add support for tokenizing 'str' objects
In-Reply-To: <1285679839.5.0.180278126855.issue9969@psf.upfronthosting.co.za>
Message-ID: <1290308045.29.0.116063750085.issue9969@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The idea is bring the API up a level, and also take care of wrapping the file-like object around the source string/byte sequence.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9969>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:04:02 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 21 Nov 2010 03:04:02 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1290308642.77.0.644083435355.issue10220@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'll actually go with version 1 of the patch as far as the variable initialisation goes. Yes, it is fractionally slower, but you get a maintenance gain from the fact that the enum values are guaranteed to be orthogonal, and this is clearly obvious to the reader.

When you write the assignments out explicitly, the reader has to actually look at the assigned values to determine whether or not the same value is ever assigned twice.

(No need to post a modified patch - I'll fix it before I check it in)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:06:47 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 21 Nov 2010 03:06:47 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1290308807.19.0.794584626411.issue10424@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yeah a new test class is fine.

And I checked the patch and it looks okay to me. My first thought was also "wait does that really work?" but I see that positionals are all marked as required when appropriate (look for the comment starting with "mark positional arguments as required").

I don't have time to test the patch right now, but if someone else does, I'm fine with this after the test for the new behavior is added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:07:54 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Sun, 21 Nov 2010 03:07:54 +0000
Subject: [issue7858] os.utime(file, (0, 0, )) fails on on vfat,
	but doesn't fail immediately
In-Reply-To: <1265386059.32.0.591513195746.issue7858@psf.upfronthosting.co.za>
Message-ID: <1290308874.07.0.911002753338.issue7858@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

win_utime.patch does not apply cleanly on the py3k branch. Adapted, as in the attached win_utime_updated.patch, the solution does fix the problem.

I have not added a test because I don't know how to deal with the fat32 requirement in order to cause failure, though I did test before and after applying the test on fat32 locally.

----------
nosy: +lambacck
Added file: http://bugs.python.org/file19725/win_utime_updated.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7858>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:10:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:10:52 +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: <1290309052.25.0.612104533179.issue9312@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the review.  I agree and committed changes in r86632.

The problem with :option:`-c` is probably that Sphinx wants to find a ?.. cmdoption:: -c? joined with the latest program directive it has seen, and thus can?t find the -c defined with a previous program directive.  I fought hard with that, trying :option:`-c <cmdoption-unittest-c>` and :ref:, but no luck.  I finally just used ```` markup.  When #10470 is implemented the two option lists will be merged and I?ll be able to use :option:`-c`.

Georg, it would be nice if you could confirm or infirm my analysis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:12:57 2010
From: report at bugs.python.org (Duncan Findlay)
Date: Sun, 21 Nov 2010 03:12:57 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290309177.9.0.384270165247.issue10470@psf.upfronthosting.co.za>


Changes by Duncan Findlay <duncan at duncf.ca>:


----------
nosy: +duncf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:13:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:13:59 +0000
Subject: [issue10445] _ast py3k : add lineno back to "args" node
In-Reply-To: <1290003328.01.0.315649649266.issue10445@psf.upfronthosting.co.za>
Message-ID: <1290309239.47.0.270461600099.issue10445@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10445>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:16:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:16:03 +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: <1290309363.17.0.0277998076974.issue10406@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If the release manager agrees, I think the change is okay.

----------
nosy: +benjamin.peterson, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10406>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:17:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:17:32 +0000
Subject: [issue10405] IDLE breakpoint facility undocumented
In-Reply-To: <1289638474.62.0.690259510388.issue10405@psf.upfronthosting.co.za>
Message-ID: <1290309452.72.0.244927755721.issue10405@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you propose a patch, as a diff or even plain English in a reply?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10405>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:17:51 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 21 Nov 2010 03:17:51 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1290309471.65.0.00982197210509.issue9182@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Sorry, I think I confused you, please post that patch here. This issue is for documenting the workarounds, issue 9338 is for actually solving the problem.

I glanced at your patch on that issue, and it looks basically okay, though I'd like to see a few more tests for the help messages to cover things like:

   -x X A                       # no --
   -x [X [X ...]] -y Y [Y ...]  # no --
   -x [X] -- A B                # needs --
   -x X [X ...]                 # needs --
   -x [X [X ...]]               # needs --

It's possible the first two are already covered by the other tests, but at least the last three should all be tested for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:19:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:19:26 +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: <1290309566.28.0.0486146818942.issue10404@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Platform consistency is a worthy criterion for changes, but I suspect such a behavior change can?t make it into stable branches.

----------
nosy: +benjamin.peterson, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:23:39 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 03:23:39 +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: <1290309819.51.0.404367986545.issue10404@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

IMO, it's not s behavior change, it's a serious bug in the OS X version as released in the python.org installer.  Important functionality is broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:28:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:28:17 +0000
Subject: [issue8754] ImportError: quote bad module name in message
In-Reply-To: <1274202200.16.0.392487565261.issue8754@psf.upfronthosting.co.za>
Message-ID: <1290310097.78.0.836254102262.issue8754@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Just for fun, I tried using my tiny understanding of C to write a patch. I am attaching my current result, which passes the test suite except for test_unittest:

FAIL: test_loadTestsFromName__unknown_module_name (unittest.test.test_loader.Test_TestLoader)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/wok/code/hg/cpython/3.2/fix-import-repr/Lib/unittest/test/test_loader.py", line 240, in test_loadTestsFromName__unknown_module_name
    loader.loadTestsFromName('sdasfasfasdf')
ImportError: No module named 0I?


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/wok/code/hg/cpython/3.2/fix-import-repr/Lib/unittest/test/test_loader.py", line 242, in test_loadTestsFromName__unknown_module_name
    self.assertEqual(str(e), "No module named 'sdasfasfasdf'")
AssertionError: 'No module named 0I?\x01' != "No module named 'sdasfasfasdf'"
- No module named 0I?

+ No module named 'sdasfasfasdf'


======================================================================
FAIL: test_loadTestsFromNames__unknown_module_name (unittest.test.test_loader.Test_TestLoader)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/unittest/test/test_loader.py", line 620, in test_loadTestsFromNames__unknown_module_name
    loader.loadTestsFromNames(['sdasfasfasdf'])
ImportError: No module named HB?


During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "Lib/unittest/test/test_loader.py", line 622, in test_loadTestsFromNames__unknown_module_name
    self.assertEqual(str(e), "No module named 'sdasfasfasdf'")
AssertionError: 'No module named HB?\x01' != "No module named 'sdasfasfasdf'"
- No module named HB?

+ No module named 'sdasfasfasdf'

test_imp{,ort,ortlib} pass, though.  Maybe someone will take my patch and fix the PyObject_Repr call and error checking.  It was a fun bit of experimenting with help from kind people on IRC :)

----------
keywords: +patch
Added 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  Sun Nov 21 04:30:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:30:24 +0000
Subject: [issue10370] py3 readlines() reports wrong offset for
	UnicodeDecodeError
In-Reply-To: <1289264715.81.0.326279765732.issue10370@psf.upfronthosting.co.za>
Message-ID: <1290310224.91.0.636603699673.issue10370@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/issue10370>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:30:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:30:47 +0000
Subject: [issue10369] tarfile requires an actual file on disc;
	a file-like object is insufficient
In-Reply-To: <1289259727.33.0.210981520326.issue10369@psf.upfronthosting.co.za>
Message-ID: <1290310247.77.0.218039189716.issue10369@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/issue10369>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:32:37 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 03:32:37 +0000
Subject: [issue10405] IDLE breakpoint facility undocumented
In-Reply-To: <1289638474.62.0.690259510388.issue10405@psf.upfronthosting.co.za>
Message-ID: <1290310357.67.0.0685829935272.issue10405@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I'd rather see the wording come from more experienced users of IDLE and on other platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10405>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:34:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:34:53 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1290310493.36.0.709764801223.issue10362@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

2.6 only gets security fixes.  Can you reproduce the bug with current versions?

----------
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/issue10362>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:46:31 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 21 Nov 2010 03:46:31 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1290311191.79.0.514094042734.issue10220@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Committed in r86633.

I added the missing docs changes, and tweaked the tests a little bit:
- added a helper method to retrieve the generator state in the test case
- this allowed test_running to be simplified a bit
- added an explicit test for the CREATED->CLOSED case
- renamed the test functions to match the existing idiom in test_inspect

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:56:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:56:06 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1290311766.26.0.355455758948.issue809163@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.  You?ll want to use assertEqual here:
    self.assertTrue(1, len(file_list.files))

Do you want to patch filelist.py now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:56:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:56:46 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290311806.34.0.183178873901.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

One buildbot also shows a bug in quiet or test_quiet:

Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows\build\lib\test\test_compileall.py", line 227, in test_quiet
    self.assertTrue(len(noise) > len(quiet))
AssertionError: False is not True

I changed that to assertGreater to get more information in the next failure.

----------
assignee: r.david.murray -> eric.araujo
resolution: accepted -> 
stage: committed/rejected -> needs patch
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sun Nov 21 04:59:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 03:59:27 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290311967.41.0.66261729527.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I hadn?t seen your patch Michele.  I find mine more readable: http://pastealacon.com/26257 . That was just the easy part though; do you want to write a test?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sun Nov 21 05:07:52 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Sun, 21 Nov 2010 04:07:52 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>


New submission from Ilya Sandler <ilya.sandler at gmail.com>:

The following program is misbehaving with python3.2

 import signal, time

 def sighandler( arg1, arg2): print("got sigint");    assert 0

 signal.signal( signal.SIGINT, sighandler)

 for i in range(1000000):
    print(i)

I'd expect Ctrl-C to terminate the program with AssertionError and that's indeed what happens under python2.7.

But with python3.2a, I get "Assertion Error" 1 out ~10 times. The other 9 times, the program locks up (goes to sleep? ps shows process status as "S"). After the program locks up, it does not respond to subsequent "Ctrl-C" presses.

This is on 64-bit Ubuntu 8.04.

----------
components: Interpreter Core
messages: 121860
nosy: isandler
priority: normal
severity: normal
status: open
title: Ctrl-C locks up the interpreter
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10478>
_______________________________________

From report at bugs.python.org  Sun Nov 21 05:14:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 04:14:02 +0000
Subject: [issue9199] distutils upload command crashes when displaying server
	response
In-Reply-To: <1278596334.3.0.531936724428.issue9199@psf.upfronthosting.co.za>
Message-ID: <1290312842.97.0.253840434483.issue9199@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Jes?s: There are a lot of literal \n in the current code, so I will assume that they work for now and change them only if there is a bug report.  Thanks for noticing nonetheless.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9199>
_______________________________________

From report at bugs.python.org  Sun Nov 21 05:26:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 04:26:59 +0000
Subject: [issue6007] distutils tricks you into thinking you can build
	extensions with mingw
In-Reply-To: <1242164743.54.0.266623530621.issue6007@psf.upfronthosting.co.za>
Message-ID: <1290313619.36.0.963054723445.issue6007@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the reply Martin.  Tarek has pronounced in favor of this change, so I will commit it tomorrow.

----------
assignee: tarek -> eric.araujo
components: +Distutils2
resolution:  -> accepted
status: open -> pending
versions: +3rd party, Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6007>
_______________________________________

From report at bugs.python.org  Sun Nov 21 05:32:45 2010
From: report at bugs.python.org (nh2)
Date: Sun, 21 Nov 2010 04:32:45 +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: <1290313965.83.0.889733901892.issue1975@psf.upfronthosting.co.za>


nh2 <nh2 at deditus.de> added the comment:

I think this is still an issue.

If I register signal.signal(signal.SIGINT, handler) in the main thread, I get a race between
- only the main thread receives the signal (everything is fine)
- both the main thread and currently running threads receive the signal => the handler is called multiple times => all kinds of resource-problems like "close failed in file object destructor: IOError: [Errno 9] Bad file descriptor" in thread cleanup functions

Note that I cannot even declare a sigintlock = threading.Lock() and use with sigintlock in the handler - if I print threading.current_thread() and sys.exit() directly afterwards in the locked area, I sometimes get two print outputs which show MainThread and Thread-1 being inside the locked area at the same time!

Is the synchronization broken or am I doing something wrong?

Is synchronization over handlers really the way to cope with this? Disabling signals for non-main threads currently seems more sensible to me.

Can someone please verify the race I get?

----------
nosy: +nh2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Sun Nov 21 06:24:39 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 05:24:39 +0000
Subject: [issue4953] cgi module cannot handle POST with multipart/form-data in
	3.0
In-Reply-To: <1232010166.79.0.972664060868.issue4953@psf.upfronthosting.co.za>
Message-ID: <1290317079.68.0.408295002952.issue4953@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Regarding http://bugs.python.org/issue4953#msg91444 POST with multipart/form-data encoding can use UTF-8, other stuff is restricted to ASCII!

>From http://www.w3.org/TR/html401/interact/forms.html:
Note. The "get" method restricts form data set values to ASCII characters. Only the "post" method (with enctype="multipart/form-data") is specified to cover the entire [ISO10646] character set.

Hence cgi formdata can safely decode text fields using UTF-8 decoding (experimentally, that is the encoding used by Firefox to support the entire ISO10646 character set).

----------
nosy: +v+python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4953>
_______________________________________

From report at bugs.python.org  Sun Nov 21 06:37:17 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 05:37:17 +0000
Subject: [issue10479] cgitb.py should assume a binary stream for output
In-Reply-To: <1290317837.02.0.152908438377.issue10479@psf.upfronthosting.co.za>
Message-ID: <1290317837.02.0.152908438377.issue10479@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

The CGI interface is a binary stream, because it is pumped directly to/from the HTTP protocol, which is a binary stream.

Hence, cgitb.py should produce binary output.  Presently, it produces text output.

When one sets stdout to a binary stream, and then cgitb intercepts an error, cgitb fails.

Demonstration of problem:

import sys
import traceback
sys.stdout = open("sob", "wb")  # WSGI sez data should be binary, so stdout should be binary???
import cgitb
sys.stdout.write(b"out")
fhb = open("fhb", "wb")
cgitb.enable()
fhb.write("abcdef")  # try writing non-binary to binary file.  Expect an error, of course.

----------
components: Unicode
messages: 121865
nosy: v+python
priority: normal
severity: normal
status: open
title: cgitb.py should assume a binary stream for output
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10479>
_______________________________________

From report at bugs.python.org  Sun Nov 21 06:38:06 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Sun, 21 Nov 2010 05:38:06 +0000
Subject: [issue10437] ThreadPoolExecutor should accept max_workers=None
In-Reply-To: <1289936174.35.0.332227808259.issue10437@psf.upfronthosting.co.za>
Message-ID: <1290317886.4.0.306242045554.issue10437@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

I think that using the number of CPUs for max_workers makes sense for you but won't for most users. So I wouldn't make it a default.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10437>
_______________________________________

From report at bugs.python.org  Sun Nov 21 06:43:09 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 05:43:09 +0000
Subject: [issue10480] cgi.py should document the need for binary stdin/stdout
In-Reply-To: <1290318189.86.0.129478140251.issue10480@psf.upfronthosting.co.za>
Message-ID: <1290318189.86.0.129478140251.issue10480@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

CGI is a bytestream protocol.  Python assumes a text mode encoding for stdin and stdout, this is inappropriate for the CGI interface.

CGI should provide an API to "do the right thing" to make stdin and stout binary mode interfaces (including mscvrt setting to binary on Windows).  Failing that, it should document the need to do so in CGI applications.

Failing that, it should be documented somewhere, CGI seems the most appropriate place to me.

----------
components: Library (Lib)
messages: 121868
nosy: v+python
priority: normal
severity: normal
status: open
title: cgi.py should document the need for binary stdin/stdout
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10480>
_______________________________________

From report at bugs.python.org  Sun Nov 21 06:57:04 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 05:57:04 +0000
Subject: [issue10481] subprocess PIPEs are byte streams
In-Reply-To: <1290319024.08.0.519309863324.issue10481@psf.upfronthosting.co.za>
Message-ID: <1290319024.08.0.519309863324.issue10481@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

While http://bugs.python.org/issue2683 did clarify the fact that the .communicate API takes a byte stream as input, it is easy to miss the implication.  Because Python programs start up with stdin as a text stream, it might be good to point out that some action may need to be taken to be sure that the receiving program expects a byte stream, or that the byte stream supplied should be in an encoding that the receiving program is expecting and can decode appropriately.

No mention is presently made in the documentation for .communicate that its output is also a byte stream, and if text will correspond to whatever encoding is used by the sending program.

----------
assignee: docs at python
components: Documentation
messages: 121869
nosy: docs at python, v+python
priority: normal
severity: normal
status: open
title: subprocess PIPEs are byte streams
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10481>
_______________________________________

From report at bugs.python.org  Sun Nov 21 07:00:20 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 06:00:20 +0000
Subject: [issue10481] subprocess PIPEs are byte streams
In-Reply-To: <1290319024.08.0.519309863324.issue10481@psf.upfronthosting.co.za>
Message-ID: <1290319220.3.0.959686329454.issue10481@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Maybe it should also be mentioned that p.stdout and p.stderr and p.stdin, when set to be PIPEs, are also byte streams.  Of course that is the reason that communicate accepts and produces byte streams.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10481>
_______________________________________

From report at bugs.python.org  Sun Nov 21 07:16:02 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 06:16:02 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

.communicate is a nice API for programs that produce little output, and can be buffered.  While that may cover a wide range of uses, it doesn't cover launching CGI programs, such as is done in http.server.  Now there are nice warnings about that issue in the http.server documentation.

However, while .communicate has the building blocks to provide more general solutions, it doesn't expose them to the user, nor does it separate them into building blocks, rather it is a monolith inside ._communicate.

For example, it would be nice to have an API that would "capture a stream using a thread" which could be used for either stdout or stdin, and is what ._communicate does under the covers for both of them.

It would also be nice to have an API that would "pump a bytestream to .stdin as a background thread.  ._communicate doesn't provide that one, but uses the foreground thread for that.  And, it requires that it be fully buffered.  It would be most useful for http.server if this API could connect a file handle and an optional maximum read count to .stdin, yet do it in a background thread.

That would leave the foreground thread able to process stdout.  It is correct (but not what http.server presently does, but I'll be entering that enhancement request soon) for http.server to read the first line from the CGI program, transform it, add a few more headers, and send that to the browser, and then hook up .stdout to the browser (shutil.copyfileobj can be used for the rest of the stream).  However, there is no deadlock free way of achieving this sort of solution, capturing the stderr to be logged, not needing to buffer a potentially large file upload, and transforming the stdout, with the facilities currently provided by subprocess.  Breaking apart some of the existing building blocks, and adding an additional one for .stdin processing would allow a real http.server implementation, as well as being more general for other complex uses.

You see, for http.server, the stdin

----------
components: Library (Lib)
messages: 121871
nosy: v+python
priority: normal
severity: normal
status: open
title: subprocess and deadlock avoidance
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10482>
_______________________________________

From report at bugs.python.org  Sun Nov 21 07:59:11 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 06:59:11 +0000
Subject: [issue5622] wrong error from curses.wrapper if curses initialization
	fails
In-Reply-To: <1238511637.05.0.307555783931.issue5622@psf.upfronthosting.co.za>
Message-ID: <1290322751.8.0.086666025818.issue5622@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
keywords: +easy
nosy:  -BreamoreBoy
stage: unit test needed -> patch review
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5622>
_______________________________________

From report at bugs.python.org  Sun Nov 21 07:59:18 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 06:59:18 +0000
Subject: [issue5622] wrong error from curses.wrapper if curses initialization
	fails
In-Reply-To: <1238511637.05.0.307555783931.issue5622@psf.upfronthosting.co.za>
Message-ID: <1290322758.73.0.808953348666.issue5622@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file18285/issue5622.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5622>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:04:20 2010
From: report at bugs.python.org (ProgVal)
Date: Sun, 21 Nov 2010 07:04:20 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1290323060.41.0.90642661463.issue10362@psf.upfronthosting.co.za>


ProgVal <progval at gmail.com> added the comment:

I also have the bug with Python 2.7.1rc1 (from Debian 'Experimental' repo)

----------
nosy: +ProgVal
versions: +Python 2.6 -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10362>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:15:20 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 07:15:20 +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: <1290323720.95.0.182564304804.issue6135@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +haypo -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6135>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:18:22 2010
From: report at bugs.python.org (Ron Adam)
Date: Sun, 21 Nov 2010 07:18:22 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290323902.69.0.692259113861.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Here is the latest patch with tests.

In order to test the html pages I separated out the URL handler.  So now we have three new functions.

    pydoc._start_server(urlhandler, port)
    pydoc._url_handler(url, content_type="text/html")
    pydoc.browse(port=0, *, open_browser=True)

A css file:   pydoc_data/_pydoc.css

The tests in test_pydoc.py, test that the server can be started and shutdown without an error.  And test that the _url_handler() will send back html pages with the correct title for all the different type of requests that it can handle.

I think this is ready for a final review now.

----------
Added file: http://bugs.python.org/file19727/issue2001_f.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:22:23 2010
From: report at bugs.python.org (Savio Sena)
Date: Sun, 21 Nov 2010 07:22:23 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1290324143.83.0.00798333106969.issue1745035@psf.upfronthosting.co.za>


Savio Sena <savio.sena at acm.org> added the comment:

The definite (and only?) solution would be to implement 'Message Size Declaration[1]' Service Extension[2]. We can limit the size of commands and text lines, but not the message size as a whole[3]. RFC1870 was created exactly with the purpose of solving DoS issues[4].

[1] RFC 1870
[2] RFC 1869
[3] RFC 2821, 4.5.3.1
[4] RFC 1870, 9.0

I'm willing to implement a fix (actually, I'm already working on that :-)) --- but I'd make good use of advices since I'm new to this project.

The minimalistic fix to this issue would be to implement Message Size Extension alone and apart from subclasses awareness --- without any changes to the interface, not even to allow changes in the default maximum message size [once SMPTServer is fully-RFC1869-compliant changing these values will be straightforward].

A second (extensive!) approach is to implement a complete ESMTPServer. That's a way bigger task though. It would be wise in this case to implement all the standard extensions, plus support (parsing/error handling) to all RFC1869.

Any thoughts?
My best regards.

NOTE: In my opinion there's no bug, really. All non-extented SMPT servers are vulnerable to resource exhaustion. Maybe we should take this as a feature request not a bug-fix request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:26:30 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:26:30 +0000
Subject: [issue10483] http.server - what is executable on Windows
In-Reply-To: <1290324390.55.0.445837984524.issue10483@psf.upfronthosting.co.za>
Message-ID: <1290324390.55.0.445837984524.issue10483@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

The def executable for CGIHTTPRequestHandler is simply wrong on Windows.  The Unix executable bits do not apply.

Yet it is not clear what to use instead.  One could check the extension against PATHEXT, perhaps, but Windows doesn't limit itself to that except when not finding the exactly specified executable name.  Or one could require and borrow the unix #! convention.  As an experiment, since I'm mostly dealing the script files, I tried out a hack that implements two #! lines, the first for Unix and the second for Windows, and only consider something executable if the second line exists.  This fails miserably for .exe files, of course.

Another possibility would be to see if there is an association for the extension, but that rule would permit a Word document to be "executable" because there is a way to open it using MS Word.

Another possibility would be to declare a list of extensions in the server source, like the list of directories from which CGIs are found.

Another possibility would be to simply assume that anything found in the CGI directory is executable.

Another possibility is to require the .cgi extension only to be executable, but then it is hard to know how to run it.

Another possibility is to require two "extensions"... the "real" one for Windows, and then .cgi just before it.  So to make a program executable, it would be renamed from file.ext to file.cgi.ext

But the current technique is clearly insufficient.

----------
components: Library (Lib)
messages: 121875
nosy: v+python
priority: normal
severity: normal
status: open
title: http.server - what is executable on Windows
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10483>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:31:57 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:31:57 +0000
Subject: [issue10484] http.server.is_cgi fails to handle CGI URLs containing
	PATH_INFO
In-Reply-To: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za>
Message-ID: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

is_cgi doesn't properly handle PATH_INFO parts of the path.  The Python2.x CGIHTTPServer.py had this right, but the introduction and use of _url_collapse_path_split broke it.

_url_collapse_path_split splits the URL into a two parts, the second part is guaranteed to be a single path component, and the first part is the rest.  However, URLs such as

/cgi-bin/foo.exe/this/is/PATH_INFO/parameters

can and do want to exist, but the code in is_cgi will never properly detect that /cgi-bin/foo.exe is the appropriate executable, and the rest should be PATH_INFO.

This used to work correctly in the precedecessor CGIHTTPServer.py code in Python 2.6, so is a regression.

----------
components: Library (Lib)
messages: 121876
nosy: v+python
priority: normal
severity: normal
status: open
title: http.server.is_cgi fails to handle CGI URLs containing PATH_INFO
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10484>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:38:14 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:38:14 +0000
Subject: [issue10485] http.server fails when query string contains addition
	'?' characters
In-Reply-To: <1290325094.43.0.114667735532.issue10485@psf.upfronthosting.co.za>
Message-ID: <1290325094.43.0.114667735532.issue10485@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

http.server on Python 3 and CGIHTTPServer on Python 2 both contain the same code with the same bug.  In run_cgi, rest.rfind('?') is used to separate the path from the query string.  However, it should be rest.find('?') as the query string starts with '?' but may also contain '?'.  It is required that '?' not be used in URL path part without escaping.

Apache, for example, separates the following URL:

/testing?foo=bar?&baz=3

into path part /testing  and query string part  foo=bar?&baz=3 but http.server does not.

----------
components: Library (Lib)
messages: 121877
nosy: v+python
priority: normal
severity: normal
status: open
title: http.server fails when query string contains addition '?' characters
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10485>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:38:31 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:38:31 +0000
Subject: [issue10485] http.server fails when query string contains addition
	'?' characters
In-Reply-To: <1290325094.43.0.114667735532.issue10485@psf.upfronthosting.co.za>
Message-ID: <1290325111.56.0.377695856219.issue10485@psf.upfronthosting.co.za>


Changes by Glenn Linderman <v+python at g.nevcal.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10485>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:41:35 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:41:35 +0000
Subject: [issue10486] http.server doesn't set all CGI environment variables
In-Reply-To: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za>
Message-ID: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

HTTP_HOST HTTP_PORT REQUEST_URI are variables that my CGI scripts use, but which are not available from http.server or CGIHTTPServer (until I added them).

There may be more standard variables that are not set, I didn't attempt to enumerate the whole list.

----------
components: Library (Lib)
messages: 121878
nosy: v+python
priority: normal
severity: normal
status: open
title: http.server doesn't set all CGI environment variables
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10486>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:47:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 07:47:33 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1290325653.43.0.414902374211.issue10441@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Antoine,

I was proposing that the Windows installation should have a folder where OpenSSL looks for certificates, and that users put trusted certificates into that folder. These should be the ones that set_default_verify_paths will use. Unfortunately, I don't know where that directory might be in the windows builds we provide. So I think we should find out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:50:42 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 21 Nov 2010 07:50:42 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290325842.18.0.772414547016.issue10453@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Yeah, maybe your is more readable.

I suppose that failure was due to some missing arguments when calling compileall (line 225). The attached patch should fix this issue, but currently I have no Windows machines where to test.

----------
Added file: http://bugs.python.org/file19728/issue10453_quiet.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:50:43 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:50:43 +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: <1290325843.93.0.000870454658653.issue10487@psf.upfronthosting.co.za>


New submission from Glenn Linderman <v+python at g.nevcal.com>:

While it is documented that http.server (and Python 2's CGIHTTPServer) do not process the status header, and limit the usefulness of CGI scripts as a result, that doesn't make it less of a bug, just a documented bug.  But I guess that it might have to be called a feature request; I'll not argue if someone switches this to feature request, but I consider it a bug.

See related issue 10482 for subprocess to provide better features for avoiding deadlock situations.  There seems to be no general way using subprocess to avoid possible deadlock situations.  However, since CGI doesn't really use stderr much, and only for logging, which the scripts can do themselves (the cgi.py module even provides for such), and because CGIs generally slurp stdin before creating stdout, it is possible to tweak sidestep use of subprocess.communicate, drop the stdout PIPE, and sequence the code to process stdin and then stdout, and not generally deadlock (some CGI scripts that don't above the stdin before stdout rule, might deadlock if called with POST and large inputs, but those are few).

By doing this, one can then add code to handle Status: headers, and avoid buffering large files on output (and on input).  The tradeoff is losing the stderr log; when that is hooked up, some error cases can trigger deadlocks by writing to stderr -- hence the subprocess issue mentioned above.

----------
components: Library (Lib)
messages: 121881
nosy: v+python
priority: normal
severity: normal
status: open
title: http.server - doesn't process Status: header from CGI scripts
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10487>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:54:24 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:54:24 +0000
Subject: [issue10479] cgitb.py should assume a binary stream for output
In-Reply-To: <1290317837.02.0.152908438377.issue10479@psf.upfronthosting.co.za>
Message-ID: <1290326064.07.0.933674434488.issue10479@psf.upfronthosting.co.za>


Changes by Glenn Linderman <v+python at g.nevcal.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10479>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:55:03 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Sun, 21 Nov 2010 07:55:03 +0000
Subject: [issue10480] cgi.py should document the need for binary stdin/stdout
In-Reply-To: <1290318189.86.0.129478140251.issue10480@psf.upfronthosting.co.za>
Message-ID: <1290326103.71.0.323016285615.issue10480@psf.upfronthosting.co.za>


Changes by Glenn Linderman <v+python at g.nevcal.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10480>
_______________________________________

From report at bugs.python.org  Sun Nov 21 08:58:37 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 07:58:37 +0000
Subject: [issue7226] IDLE right-clicks don't work on Mac OS 10.5
In-Reply-To: <1256693718.71.0.813168523679.issue7226@psf.upfronthosting.co.za>
Message-ID: <1290326317.6.0.27819683216.issue7226@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Surprisingly, this had apparently not been reported before.  Thanks for doing so!  Recently, some one else reported the problem on one of the newsgroups.  Overlooking this issue, I unnecessarily opened Issue10404 for it and supplied a patch there.

----------
nosy: +ned.deily
resolution: accepted -> duplicate
status: open -> closed
superseder:  -> IDLE on OS X popup menus do not work: cannot set/clear breakpoints
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7226>
_______________________________________

From report at bugs.python.org  Sun Nov 21 09:01:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 08:01:39 +0000
Subject: [issue10483] http.server - what is executable on Windows
In-Reply-To: <1290324390.55.0.445837984524.issue10483@psf.upfronthosting.co.za>
Message-ID: <1290326499.36.0.474043361123.issue10483@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think it's fairly clear what should be considered executable in this context: anything that subprocess.Popen is able to launch (because if is_executable succeeds, this is what will happen to the file). This excludes word files, and also excludes files ending in .cgi; only files ending in .exe are executable.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10483>
_______________________________________

From report at bugs.python.org  Sun Nov 21 09:14:06 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 08:14:06 +0000
Subject: [issue7367] pkgutil.walk_packages fails on write-only directory in
	sys.path
In-Reply-To: <1258702285.22.0.207199237354.issue7367@psf.upfronthosting.co.za>
Message-ID: <1290327246.54.0.341686992728.issue7367@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
keywords: +easy
stage:  -> needs patch
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7367>
_______________________________________

From report at bugs.python.org  Sun Nov 21 09:37:38 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 21 Nov 2010 08:37:38 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <1290280198.27.0.333542204475.issue10231@psf.upfronthosting.co.za>
Message-ID: <20101121083727.GA1443@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sat, Nov 20, 2010 at 07:09:58PM +0000, Jeremy Thurgood wrote:
> There are two separate things here: the URL and the filesystem path. 
> The bug is that the fragment and query parameters are stripped in
> translate_path(), but are *not* stripped when manipulating the URL
> for the redirect.

Thanks for the explanation. My understanding of the bug (and the
patch) is same as yours.

> This means that when the URL is "/something?foo" and the cwd is

Now, lets stop here for a moment to reflect the meaning of this URL.

Here is the Query string article from Wikipedia:
http://en.wikipedia.org/wiki/Query_string

It gives a generic definition:

    A typical URL containing a query string is as follows:

    http://server/path/program?query_string

    When a server receives a request for such a page, it runs a
    program (if configured to do so), passing the query_string
    unchanged to the program. The question mark is used as a separator
    and is not part of the query string.

Given this, in the URL /something?foo , can 'something' be a directory
in the filesystem? To which program will query string be sent? ( You
can say that a program by name index{.py,cgi,pl) inside the something
directory *can* handle it, but I don't see such a practical scenario
or CGI server configuration)

- Same argument a #fragment_identifier. This is  portion of webpage
  (anchor tag), a file. It cannot start immediately after a
  file-system directory path.

In the http.server code, you will see that 301 redirection part is
entered only when the last part is directory, but in cases where a?q
and a#f, ('a' wont be a directory, so that redirection part is not
entered at all).

Let's come to some real world scenarios.

Now, what happens when you type "http://bugs.python.org?10231" [1] in
your browser? According to this bug report, the server should 301
redirect it to "http://bugs.python.org/?10231". If you try this, this
does not happen. The browser (client) is in fact, changing it to the
corrected URL (because the original is invalid) and the server is just
ignoring the so called query portion). 

If you use, urllib2 to request the above [1], you will find that it
will fail with 401 error.

These are the reasons, why I consider this report is not really a bug.
Any suggestions or thoughts on the explanation?

In your attached patch, I think we should still be able to use some
tests without any change in the http.server code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Sun Nov 21 09:45:25 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 08:45:25 +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: <1290329125.95.0.0342263679307.issue7322@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I see Issue7995 also addresses the issue of accept sockets inheriting nonblocking status and provides a suggested patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7322>
_______________________________________

From report at bugs.python.org  Sun Nov 21 09:45:56 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 08:45:56 +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: <1290329156.35.0.20563966528.issue7995@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(See also Issue7322)

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 10:17:45 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 21 Nov 2010 09:17:45 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1290331065.21.0.775149466238.issue10424@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Unittest added.

----------
Added file: http://bugs.python.org/file19729/issue10424.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Sun Nov 21 10:17:56 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 21 Nov 2010 09:17:56 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1290331076.22.0.572993337618.issue10424@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Removed file: http://bugs.python.org/file19646/issue10424.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Sun Nov 21 10:25:36 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 21 Nov 2010 09:25:36 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1290331536.35.0.544665734609.issue10478@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I reproduce the problem, see the call stack below.
The issue is in the io module: the function _bufferedwriter_flush_unlocked() runs with the file mutex already acquired, but it calls PyErr_CheckSignals() which may run any code, including flush() on the same file...

In Modules/_io/buffereredio.c, the two callers to PyErr_CheckSignals() should ensure that 'self' is in a stable state, and release the lock while they run PyErr_CheckSignals().


#0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
#1  0x000000000049ac7d in PyThread_acquire_lock_timed (lock=0x21e24d0,
    microseconds=-1) at Python/thread_pthread.h:338
#2  0x00000000004c6486 in bufferedwriter_write (self=0x7f02b649d730,
    args=<value optimized out>) at ./Modules/_io/bufferedio.c:1751
#3  0x00000000004d8e29 in PyObject_Call (func=
    <built-in method write of _io.BufferedWriter object at remote 0x7f02b649d730>, arg=<unknown at remote 0x80>, kw=<value optimized out>)
    at Objects/abstract.c:2149
#4  0x00000000004db093 in PyObject_CallMethodObjArgs (callable=
    <built-in method write of _io.BufferedWriter object at remote 0x7f02b649d730>, name=<value optimized out>) at Objects/abstract.c:2350
#5  0x00000000004c9870 in _textiowrapper_writeflush (self=0x7f02b64a9530)
    at ./Modules/_io/textio.c:1237
#6  0x00000000004ca3be in textiowrapper_write (self=0x7f02b64a9530,
    args=<value optimized out>) at ./Modules/_io/textio.c:1318
#7  0x00000000004d81b7 in PyObject_Call (func=
    <built-in method write of _io.TextIOWrapper object at remote 0x7f02b64a9530>, arg=<unknown at remote 0x80>, kw=0x0) at Objects/abstract.c:2149
#8  0x000000000045e843 in PyEval_CallObjectWithKeywords (func=
    <built-in method write of _io.TextIOWrapper object at remote 0x7f02b64a9530>, arg=('\n',), kw=0x0) at Python/ceval.c:3754
#9  0x00000000004fb696 in PyFile_WriteObject (v=<value optimized out>,
    f=<value optimized out>, flags=<value optimized out>)
    at Objects/fileobject.c:156
#10 0x00000000004fb860 in PyFile_WriteString (s=<value optimized out>, f=
    <_io.TextIOWrapper at remote 0x7f02b64a9530>) at Objects/fileobject.c:181
#11 0x000000000045c49b in builtin_print (self=<value optimized out>, args=
    ('got sigint',), kwds=<value optimized out>) at Python/bltinmodule.c:1510
#12 0x0000000000465ded in call_function (f=
    Frame 0x22f28b0, for file <stdin>, line 1, in sighandler (arg1=2, arg2=Frame 0x22de7f0, for file <stdin>, line 2, in <module> ()),
    throwflag=<value optimized out>) at Python/ceval.c:3874
#13 PyEval_EvalFrameEx (f=
    Frame 0x22f28b0, for file <stdin>, line 1, in sighandler (arg1=2, arg2=Frame 0x22de7f0, for file <stdin>, line 2, in <module> ()),
    throwflag=<value optimized out>) at Python/ceval.c:2673
#14 0x0000000000466ee5 in PyEval_EvalCodeEx (co=0x7f02b5770cf0,
    globals=<value optimized out>, locals=<value optimized out>, args=0x2,
    argcount=<value optimized out>, kws=<value optimized out>, kwcount=0,
    defs=0x0, defcount=0, kwdefs=0x0, closure=0x0) at Python/ceval.c:3310
#15 0x00000000005027f4 in function_call (func=
    <function at remote 0x7f02b52e71e8>, arg=
    (2, Frame 0x22de7f0, for file <stdin>, line 2, in <module> ()), kw=0x0)
    at Objects/funcobject.c:630
#16 0x00000000004d81b7 in PyObject_Call (func=
    <function at remote 0x7f02b52e71e8>, arg=<unknown at remote 0x80>, kw=0x0)
    at Objects/abstract.c:2149
#17 0x000000000045e843 in PyEval_CallObjectWithKeywords (func=
    <function at remote 0x7f02b52e71e8>, arg=
    (2, Frame 0x22de7f0, for file <stdin>, line 2, in <module> ()), kw=0x0)
    at Python/ceval.c:3754
#18 0x00000000004a04cf in PyErr_CheckSignals ()
    at ./Modules/signalmodule.c:929
#19 0x00000000004c56cd in _bufferedwriter_flush_unlocked (self=
    0x7f02b649d730, restore_pos=0) at ./Modules/_io/bufferedio.c:1709
#20 0x00000000004c5b3e in buffered_flush (self=0x7f02b649d730,
    args=<value optimized out>) at ./Modules/_io/bufferedio.c:709

----------
assignee:  -> pitrou
nosy: +amaury.forgeotdarc, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10478>
_______________________________________

From report at bugs.python.org  Sun Nov 21 10:28:24 2010
From: report at bugs.python.org (david)
Date: Sun, 21 Nov 2010 09:28:24 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1290325653.43.0.414902374211.issue10441@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=1w_Q2536q8_zkPdU9zvKA=SciO28_fooMupyW@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

Back to the main issue here :

So for python3 is it possible to make attempting to use capath(some
common ones OR the openssl location capath if this is ok for use) the
default(with failure to find a valid capath result in an exception
being raised) ?

Obviously if cafile or capath is provided by the caller then --> do
not follow this behaviour.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 10:31:33 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 09:31:33 +0000
Subject: [issue8381] IDLE 2.6 freezes on OS X 10.6
In-Reply-To: <1271112528.95.0.966124391171.issue8381@psf.upfronthosting.co.za>
Message-ID: <1290331893.16.0.283088202402.issue8381@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Consolidating with Issue6864

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> IDLE 2.6.1 locks up on Mac OS 10.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8381>
_______________________________________

From report at bugs.python.org  Sun Nov 21 10:44:09 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sun, 21 Nov 2010 09:44:09 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1290332649.05.0.306123080407.issue9182@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

Steven: From msg121850 I think the last two examples do not need the "--". Since there are no positional arguments, the "--" is not needed. However the following additional cases exist:

-x X [X ...] -y Y -- A B # since optionals might come in other order

Basically every of the three variable length classes need to be tested: ZeroOrOne, ZeroOrMore and OneOrMore. This might always come in a conflict with positional arguments needed afterward (even with optional positional arguments!).

BTW - I recognized the following seem to be supported:

for [-x [X ...]] -- [y ...] 
the following input: a -x -- b

I would expect to be 'a' and 'b' positional arguments and the optional '-x' has no argument. However this seem not to work. Another issue or desired behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Sun Nov 21 10:44:50 2010
From: report at bugs.python.org (John Keyes)
Date: Sun, 21 Nov 2010 09:44:50 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1290332690.36.0.958286058673.issue809163@psf.upfronthosting.co.za>


John Keyes <johnkeyes at gmail.com> added the comment:

Gah! Silly mistake with the assert.

What filelist.py patch are you referring to? I've tested this on py3k with no changes to filelist.py.

Thanks for your patience.

----------
Added file: http://bugs.python.org/file19730/issue809163v3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Sun Nov 21 10:46:59 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sun, 21 Nov 2010 09:46:59 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1290332819.66.0.924313374829.issue9182@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

Added more unit tests for testing the help text as well as the functionality of the "--" separator.

----------
keywords: +patch
Added file: http://bugs.python.org/file19731/issue9182.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Sun Nov 21 10:48:59 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sun, 21 Nov 2010 09:48:59 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1290332939.26.0.861915855445.issue9182@psf.upfronthosting.co.za>


Changes by Daniel Albeseder <kotan at gmx.at>:


Removed file: http://bugs.python.org/file19731/issue9182.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Sun Nov 21 10:49:05 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sun, 21 Nov 2010 09:49:05 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1290332945.57.0.366714509671.issue9182@psf.upfronthosting.co.za>


Changes by Daniel Albeseder <kotan at gmx.at>:


Added file: http://bugs.python.org/file19732/issue9182.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Sun Nov 21 10:50:03 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 09:50:03 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle
	SSL	certificate validation
In-Reply-To: <AANLkTi=1w_Q2536q8_zkPdU9zvKA=SciO28_fooMupyW@mail.gmail.com>
Message-ID: <4CE8EB47.6050009@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> So for python3 is it possible to make attempting to use capath(some
> common ones OR the openssl location capath if this is ok for use) the
> default(with failure to find a valid capath result in an exception
> being raised) ?

The default? That would be an incompatible change, and cause many
complaints. So I'm very skeptical that this can be done.

Having applications/scripts explicitly opt-in to a default CA
certificate list would be an option (then making those applications
break in installations where the default CA list is empty).

----------
title: some stdlib modules need to be updated to handle SSL certificate validation -> some stdlib modules need to be updated to handle SSL	certificate validation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 11:10:26 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 10:10:26 +0000
Subject: [issue9574] allow whitespace around central '+' in complex constructor
In-Reply-To: <1281597162.74.0.823446392009.issue9574@psf.upfronthosting.co.za>
Message-ID: <1290334226.3.0.546421469075.issue9574@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch (targeting 3.3) for allowing whitespace around the central binary operator; it implements the grammar suggested in msg115163.

----------
assignee:  -> mark.dickinson
Added file: http://bugs.python.org/file19733/issue9574.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9574>
_______________________________________

From report at bugs.python.org  Sun Nov 21 11:13:06 2010
From: report at bugs.python.org (david)
Date: Sun, 21 Nov 2010 10:13:06 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <4CE8EB47.6050009@v.loewis.de>
Message-ID: <AANLkTi=X7kP_mk=zudwwcKeDeW_Q8t4fEU3W+-iXooop@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

On 21 November 2010 20:50, Martin v. L?wis <report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>> So for python3 is it possible to make attempting to use capath(some
>> common ones OR the openssl location capath if this is ok for use) the
>> default(with failure to find a valid capath result in an exception
>> being raised) ?
>
> The default? That would be an incompatible change, and cause many
> complaints. So I'm very skeptical that this can be done.
>
> Having applications/scripts explicitly opt-in to a default CA
> certificate list would be an option (then making those applications
> break in installations where the default CA list is empty).

"Errors should never pass silently."
IMHO it is an error not to check by default.
No it wouldn't break anything that shouldn't break.
Users can then pass in None for the capath (as an example).

----------
title: some stdlib modules need to be updated to handle SSL	certificate validation -> some stdlib modules need to be updated to handle SSL certificate validation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 11:46:07 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 21 Nov 2010 10:46:07 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290336367.12.0.974203538818.issue10470@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

@Eric

No. "python -m unittest discover ..." will still be needed where you want to pass arguments to discovery ("python -m unittest ..." still has a different meaning where you pass arguments). All this will do is give the previously useless "python -m unittest" the same meaning as "python -m unittest discover".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 11:47:12 2010
From: report at bugs.python.org (Iuri Diniz)
Date: Sun, 21 Nov 2010 10:47:12 +0000
Subject: [issue8943] Bug in InteractiveConsole
In-Reply-To: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za>
Message-ID: <1290336432.68.0.00904957682314.issue8943@psf.upfronthosting.co.za>


Iuri Diniz <iuridiniz at gmail.com> added the comment:

Bug stills on branch 
http://svn.python.org/projects/python/branches/py3k 
branch http://svn.python.org/projects/python/branches/release27-maint is OK

doing some gdb on 3.2, I have discovered that the problem occurs when trying to dump global Example from module __console__ on py3k/Modules/_pickle.c:save_global:2536

Python 2.7 never calls save_global (why?)

in annex: an update test

----------
nosy: +iuridiniz
Added file: http://bugs.python.org/file19734/interative.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8943>
_______________________________________

From report at bugs.python.org  Sun Nov 21 11:48:44 2010
From: report at bugs.python.org (Iuri Diniz)
Date: Sun, 21 Nov 2010 10:48:44 +0000
Subject: [issue8943] Bug in InteractiveConsole
In-Reply-To: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za>
Message-ID: <1290336524.48.0.505893071466.issue8943@psf.upfronthosting.co.za>


Iuri Diniz <iuridiniz at gmail.com> added the comment:

preliminary gdb backtrace

----------
Added file: http://bugs.python.org/file19735/backtrace-py3k-8943.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8943>
_______________________________________

From report at bugs.python.org  Sun Nov 21 11:49:50 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 10:49:50 +0000
Subject: [issue8590] test_httpservers.CGIHTTPServerTestCase failure on
	3.1-maint Mac OS X
In-Reply-To: <1272713768.56.0.588560261666.issue8590@psf.upfronthosting.co.za>
Message-ID: <1290336590.45.0.307055759032.issue8590@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Duplicate of Issue8447 ?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8590>
_______________________________________

From report at bugs.python.org  Sun Nov 21 12:00:22 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 21 Nov 2010 11:00:22 +0000
Subject: [issue8590] test_httpservers.CGIHTTPServerTestCase failure on
	3.1-maint Mac OS X
In-Reply-To: <1272713768.56.0.588560261666.issue8590@psf.upfronthosting.co.za>
Message-ID: <1290337222.45.0.143655166319.issue8590@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The test now passes for me on Mac OS X and yes - looks like the same issue as issue 8447.

----------
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8590>
_______________________________________

From report at bugs.python.org  Sun Nov 21 12:04:46 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 11:04:46 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1290337486.21.0.212895023292.issue2986@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Simon's patch fix for 3.2 looks good to me - applies cleanly to py3k and tests pass.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Sun Nov 21 12:16:56 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 11:16:56 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290338216.47.0.236884676579.issue10470@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I will take a shot at this now. If there's anything special I should look out for, let me know :)

----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 12:24:16 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 21 Nov 2010 11:24:16 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1290338656.9.0.906443296567.issue10424@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Ezio reviewed my patch; here there's the new version with some improvements.

----------
Added file: http://bugs.python.org/file19736/issue10424.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Sun Nov 21 12:24:32 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Sun, 21 Nov 2010 11:24:32 +0000
Subject: [issue10424] better error message from argparse when positionals
	missing
In-Reply-To: <1289817524.15.0.471223912613.issue10424@psf.upfronthosting.co.za>
Message-ID: <1290338672.08.0.717261821665.issue10424@psf.upfronthosting.co.za>


Changes by Michele Orr? <maker.py at gmail.com>:


Removed file: http://bugs.python.org/file19729/issue10424.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10424>
_______________________________________

From report at bugs.python.org  Sun Nov 21 12:39:12 2010
From: report at bugs.python.org (Iuri Diniz)
Date: Sun, 21 Nov 2010 11:39:12 +0000
Subject: [issue8943] Bug in InteractiveConsole
In-Reply-To: <1276014263.34.0.524334073977.issue8943@psf.upfronthosting.co.za>
Message-ID: <1290339552.27.0.783637129472.issue8943@psf.upfronthosting.co.za>


Iuri Diniz <iuridiniz at gmail.com> added the comment:

Well, this is a pickle problem or a Interactive console problem?

on python 2.7 does not save a type "type" (like Example class is)
2: type->tp_name = 0x58a87c "instance"
2: type->tp_name = 0x590391 "dict"
2: type->tp_name = 0x5943b6 "str"
2: type->tp_name = 0x5943b6 "str"

on python 3.2 does and when saving a type, it tries to save a global.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8943>
_______________________________________

From report at bugs.python.org  Sun Nov 21 12:59:09 2010
From: report at bugs.python.org (=?utf-8?q?Rafael_dos_Santos_Gon=C3=A7alves?=)
Date: Sun, 21 Nov 2010 11:59:09 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	relative dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1290340749.77.0.416412520623.issue7325@psf.upfronthosting.co.za>


Changes by Rafael dos Santos Gon?alves <rafaelsantosg at gmail.com>:


Removed file: http://bugs.python.org/file19699/issue7325.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:00:32 2010
From: report at bugs.python.org (=?utf-8?q?Rafael_dos_Santos_Gon=C3=A7alves?=)
Date: Sun, 21 Nov 2010 12:00:32 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	relative dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1290340832.44.0.218180653802.issue7325@psf.upfronthosting.co.za>


Rafael dos Santos Gon?alves <rafaelsantosg at gmail.com> added the comment:

You is right, i put this command on test and not the test.
thankss

----------
Added file: http://bugs.python.org/file19737/issue7325.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:06:30 2010
From: report at bugs.python.org (Sibylle Koczian)
Date: Sun, 21 Nov 2010 12:06:30 +0000
Subject: [issue10466] locale.py throws exception on Windows / Non-UTF8 system
In-Reply-To: <1290263848.43.0.227530094029.issue10466@psf.upfronthosting.co.za>
Message-ID: <26570674.6145491.1290341187511.JavaMail.fmail@mwmweb080>


Sibylle Koczian <nulla.epistola at web.de> added the comment:

-----Urspr?ngliche Nachricht-----
Von: "R. David Murray" <report at bugs.python.org>
Gesendet: 20.11.2010 15:37:28
An: nulla.epistola at web.de
Betreff: [issue10466] locale.py throws exception on Windows / Non-UTF8 system

>
>R. David Murray <rdmurray at bitdance.com> added the comment:
>
>unsupported locale setting is a message that comes from the C runtime, IIUC.  Does it work on windows with 2.6?
>

No, it doesn't. I installed 2.6.6, and I found an old 2.3 (installed by some application). Both of them throw the same exception if locale is run as a script.
___________________________________________________________
GRATIS! Movie-FLAT mit ?ber 300 Videos. 
Jetzt freischalten unter http://movieflat.web.de

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:12:07 2010
From: report at bugs.python.org (Jeremy Thurgood)
Date: Sun, 21 Nov 2010 12:12:07 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <20101121083727.GA1443@rubuntu>
Message-ID: <AANLkTinNs_Ts1B+S_Ye6PjGFqx_MihtA8U+t5-Rpsg6+@mail.gmail.com>


Jeremy Thurgood <firxen at gmail.com> added the comment:

On Sun, Nov 21, 2010 at 10:37, Senthil Kumaran <report at bugs.python.org> wrote:
> Now, what happens when you type "http://bugs.python.org?10231" [1] in
> your browser? According to this bug report, the server should 301
> redirect it to "http://bugs.python.org/?10231". If you try this, this
> does not happen. The browser (client) is in fact, changing it to the
> corrected URL (because the original is invalid) and the server is just
> ignoring the so called query portion).

I see your point now, but I don't agree with it completely. It seems
reasonable to allow query parameters to specify things like sort order
for a directory listing or have a fragment to focus the browser on a
particular entry. On the other hand, if we don't want to support the
redirect with a fragment or query parameters, we should instead return
a 400 response. I can't see any situation in which redirecting
"/something?foo" to "/something?foo/" is the correct behaviour.

> If you use, urllib2 to request the above [1], you will find that it
> will fail with 401 error.

A 401 is "Unauthorized", which means the server is asking for
authentication -- I don't think that's relevant here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:23:00 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 12:23:00 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290342180.37.0.832664583923.issue10470@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
Removed message: http://bugs.python.org/msg121903

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:24:16 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 12:24:16 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290342256.89.0.714658536131.issue10470@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

I'm attaching a patch for unittest/main.py that implements this.

However, something is funny with the tests of the unittest module. When the patch is applied and the tests are run through regrtest.py, it complains that sys.path is modified. I'm investigating this now.

----------
keywords: +patch
Added file: http://bugs.python.org/file19738/unittest.main.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:25:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 12:25:48 +0000
Subject: [issue10488] Improve documentation for 'float' built-in.
In-Reply-To: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>
Message-ID: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The docs for 'float' are outdated, and also not entirely written in English. :-)

Here's a patch.

----------
assignee: docs at python
components: Documentation
files: float_builtin_doc.patch
keywords: patch
messages: 121910
nosy: docs at python, mark.dickinson
priority: normal
severity: normal
status: open
title: Improve documentation for 'float' built-in.
versions: Python 3.2
Added file: http://bugs.python.org/file19739/float_builtin_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10488>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:29:46 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 12:29:46 +0000
Subject: [issue10488] Improve documentation for 'float' built-in.
In-Reply-To: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>
Message-ID: <1290342586.64.0.658027152427.issue10488@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Grr.  Some unintended cut-and-paste duplication there.

----------
Added file: http://bugs.python.org/file19740/float_builtin_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10488>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:29:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 12:29:52 +0000
Subject: [issue10488] Improve documentation for 'float' built-in.
In-Reply-To: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>
Message-ID: <1290342592.17.0.396270054132.issue10488@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file19739/float_builtin_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10488>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:30:55 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 21 Nov 2010 12:30:55 +0000
Subject: [issue10489] configparser: remove broken `__name__` support
In-Reply-To: <1290342654.96.0.351171202849.issue10489@psf.upfronthosting.co.za>
Message-ID: <1290342654.96.0.351171202849.issue10489@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

I want to sum up all strange things about the behaviour of `__name__`, a special key present in every section of a parser instance.

1. There is a special `__name__` key in every section.
2. Except for the DEFAULTSECT.
3. `__name__` key is set for every section read from a file.
4. and not when adding by `add_section()`.
5. if `__name__` does exist, it's not visible in `parser.options('section')`
6. but it is visible here: `parser.has_option('section', '__name__') == True`
7. and can be obtained by `parser.get('section', '__name__')`
8. and can be changed by `parser.set('section', '__name__', 'ANY VALUE')`
9. and can be removed by `parser.remove_option('section', '__name__')`
10. even if the value is changed by `parser.set()`, it won't be written back to a file with `parser.write()`

All this looks like a feature that was not particularly complete and well defined when it was first created. Or possibly, it became rotten with time and now nobody is using it anyway. That way or the other, I couldn't come up with a valid use case for `__name__` with the current implementation. It doesn't serve any internal purpose and the *only* way you can actually get it is to `parser.get('section', '__name__')` which returns 'section' anyway. About as useless as it gets. Of course, one can go and take the internal parser._sections data structure of the parser but that's evil.

I want simply remove all mentions of a special `__name__` key in configparser.py. Backwards compatibility is not a concern here because in this case we have a concept that is so broken that you can't actually use it.

----------
assignee: lukasz.langa
components: Library (Lib)
keywords: easy, needs review
messages: 121912
nosy: lukasz.langa
priority: normal
severity: normal
status: open
title: configparser: remove broken `__name__` support
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10489>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:31:17 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 21 Nov 2010 12:31:17 +0000
Subject: [issue10489] configparser: remove broken `__name__` support
In-Reply-To: <1290342654.96.0.351171202849.issue10489@psf.upfronthosting.co.za>
Message-ID: <1290342677.28.0.0788256085029.issue10489@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
nosy: +eric.araujo, fdrake, georg.brandl, michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10489>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:33:17 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 21 Nov 2010 12:33:17 +0000
Subject: [issue10489] configparser: remove broken `__name__` support
In-Reply-To: <1290342654.96.0.351171202849.issue10489@psf.upfronthosting.co.za>
Message-ID: <1290342797.46.0.812892693209.issue10489@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

For the record, I wrote about this problem in July on the mailing list [1], there were no replies.

[1] http://mail.python.org/pipermail/python-dev/2010-July/102556.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10489>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:37:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 21 Nov 2010 12:37:53 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290343073.87.0.0172153615317.issue1859@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1 for applying the doc patch.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:44:30 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 21 Nov 2010 12:44:30 +0000
Subject: [issue10488] Improve documentation for 'float' built-in.
In-Reply-To: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>
Message-ID: <1290343470.77.0.313464961469.issue10488@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This is clearly an improvement. Do we want mention __float__?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10488>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:47:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 12:47:58 +0000
Subject: [issue10488] Improve documentation for 'float' built-in.
In-Reply-To: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>
Message-ID: <1290343678.31.0.759991287213.issue10488@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah yes;  good point about __float__. I'll revise.

Ezio Melotti also suggested (on #python-dev) that it would be useful to have some examples here.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10488>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:48:24 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 21 Nov 2010 12:48:24 +0000
Subject: [issue10488] Improve documentation for 'float' built-in.
In-Reply-To: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>
Message-ID: <1290343704.11.0.80030048194.issue10488@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I would prefer to keep the doc for float() simple, including what it accepts (numbers and strings) and a few examples like ``'1.2'``, ``'.5'``, ``' +3 '``, ``'inf'``, ``'NaN'``.
Even if the other information is still valuable, I'm not sure this is the best place where to include it, and I think it might be confusing for unexperienced users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10488>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:49:20 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 12:49:20 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290343760.57.0.451997474215.issue10470@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a patch to unittest/test/test_program.py that fixes the sys.path warning in regrtest

What happens is that with the new capability added to unittest (running discovery when called as -m without args), a few tests in test_program now cause discovery to run. It's not a problem, but discovery plays with sys.path, which regrtest doesn't like. So I added restoration of sys.path to these tests in a manner similar to what the test/test_discovery.py test does.

----------
Added file: http://bugs.python.org/file19741/unittest.test.test_program.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 13:50:23 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 12:50:23 +0000
Subject: [issue10488] Improve documentation for 'float' built-in.
In-Reply-To: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>
Message-ID: <1290343823.06.0.960912179762.issue10488@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ezio:  can you suggest a better place for a specification of what float accepts?  I think it's necessary (especially for people working on alternative implementations) to have the information *somewhere*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10488>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:06:55 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 21 Nov 2010 13:06:55 +0000
Subject: [issue10489] configparser: remove broken `__name__` support
In-Reply-To: <1290342654.96.0.351171202849.issue10489@psf.upfronthosting.co.za>
Message-ID: <1290344815.86.0.845620477228.issue10489@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Patch for the cleanup attached. 47 lines removed, about a half of these were in tests explicitly made to check for these inconsistencies. 4 lines added, all of them are reformattings due to removal of the other lines.

Syntax highlighted view of the patch:
http://bpaste.net/show/11395/

----------
keywords: +patch
Added file: http://bugs.python.org/file19742/issue10489.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10489>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:17:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 13:17:20 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <AANLkTi=X7kP_mk=zudwwcKeDeW_Q8t4fEU3W+-iXooop@mail.gmail.com>
Message-ID: <1290345435.3620.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Having applications/scripts explicitly opt-in to a default CA
> > certificate list would be an option (then making those applications
> > break in installations where the default CA list is empty).
> 
> "Errors should never pass silently."
> IMHO it is an error not to check by default.
> No it wouldn't break anything that shouldn't break.
> Users can then pass in None for the capath (as an example).

Well, can you stop insisting? It is probably the third time that we
explain you we can't break compatibility on this.

(also, many SSL sites are not covered by "default" CA certificates
shipped by most vendors, e.g. self-signed certificates or certificates
signed by CAcert)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:19:27 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 13:19:27 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290345567.01.0.121431747897.issue10470@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Submitting a complete patch file for this:

1. Modified Lib/unittest/main.py to implement the change
2. Modified Lib/unittest/test/test_program.py to make the tests pass without warnings from regrtest.py
3. Updated the documentation in Doc/library/unittest.rst
4. Updated Misc/NEWS

----------
Added file: http://bugs.python.org/file19743/issue10470.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:19:33 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 13:19:33 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290345573.1.0.298013702477.issue10470@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file19738/unittest.main.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:19:36 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 13:19:36 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290345576.25.0.964797206786.issue10470@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file19741/unittest.test.test_program.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:22:19 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 13:22:19 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290345739.47.0.0547780375388.issue10470@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
Removed message: http://bugs.python.org/msg121909

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:22:23 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 13:22:23 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290345743.98.0.485791036003.issue10470@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
Removed message: http://bugs.python.org/msg121918

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:25:30 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sun, 21 Nov 2010 13:25:30 +0000
Subject: [issue10351] Add autocompletion for keys in dictionaries
In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>
Message-ID: <1290345930.48.0.953587083955.issue10351@psf.upfronthosting.co.za>


Changes by Rodrigo Bernardo Pimentel <rbp at isnomore.net>:


----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10351>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:29:36 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 13:29:36 +0000
Subject: [issue10488] Improve documentation for 'float' built-in.
In-Reply-To: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>
Message-ID: <1290346176.64.0.910528920413.issue10488@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Updated patch:

 - add some examples
 - mention __float__
 - mention that large numeric arguments can result in an OverflowError

----------
Added file: http://bugs.python.org/file19744/float_builtin_doc_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10488>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:36:19 2010
From: report at bugs.python.org (Roy Smith)
Date: Sun, 21 Nov 2010 13:36:19 +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: <1290346579.13.0.134837546765.issue7995@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

The answer depends on what the socket module is trying to do.  Is the goal simply to provide a pythonic thin wrapper over the underlying OS interfaces without altering their semantics, or to provide a completely homogeneous abstraction?  Having attempted the latter before, I'm aware of just how difficult a job it can be.

The docs have a big bold note right up top, "Note Some behavior may be platform dependent, since calls are made to the operating system socket APIs".  This is followed up by, "The platform-specific reference material for the various socket-related system calls are also a valuable source of information on the details of socket semantics."

What's not clear, however, is the intent.  If the intent is to hide the platform differences, then the notes in the docs are simply warnings that we're not always successful at doing that.  If so, then exposing the different behaviors of listen/accept is a bug which should be fixed.

Anyway, my personal opinion is that we should consider the current behavior a bug and fix it.  I like the idea of setting all accepted sockets to blocking mode (and documenting it clearly).  I think it is what most people would expect.  I understand that this would break code of people who were relying on the "accept inherits non-blocking mode" behavior on some OS's, but I suspect the number of people who are relying on that behavior is extremely close to zero, and they are relying on a non-portable feature of a specific OS.

I leave it to others to figure out which versions it is reasonable to apply this to.

----------
nosy: +roysmith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:38:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 13:38:30 +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: <1290346710.97.0.279160067394.issue7995@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/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:43:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 13:43:11 +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: <1290346991.84.0.0347353957549.issue7995@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It seems to me that it's a reasonable request. There is indeed a bug, since Python uses non-blocking sockets to implement its "timeout" feature, and flags inheritance means Python's view of whether the socket is non-blocking is not in sync with reality on the OS side.

I think the patch should be opt-out rather than opt-in: that code path should probably be enabled for everything but Linux (and Windows?).

Another possibility is to force inheritance of flags, such that an accept()ed socket inherits the timeout settings of its parent (even under Linux).

----------
nosy: +pitrou
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:44:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 13:44:00 +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: <1290347040.02.0.0960944439767.issue7995@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oh, and a test should be added of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 14:50:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 13:50:11 +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: <1290347411.64.0.633902335145.issue1975@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

nh2, your issue looks slightly different. In any case, can you tell us what your system is, and post a simple script to reproduce the issue?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Sun Nov 21 15:00:38 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sun, 21 Nov 2010 14:00:38 +0000
Subject: [issue10489] configparser: remove broken `__name__` support
In-Reply-To: <1290342654.96.0.351171202849.issue10489@psf.upfronthosting.co.za>
Message-ID: <1290348038.38.0.741350013949.issue10489@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Committed in rev 86638. A public API for getting the name of the section from a SectionProxy instance was introduced in 86639. This is useful because you can assing a section proxy to a variable and pass it around:

>>> from configparser import SafeConfigParser
>>> parser = SafeConfigParser()
>>> parser.read_string("""
... [section1]
... value = A
... value2 = B
... 
... [section2]
... value = C
... value2 = D
... """)
>>> section1 = parser['section1']
>>> section1['value']
'A'
>>> section1.name
'section1'
>>> section2 = parser['section2']
>>> section2['value']
'C'
>>> section2.name
'section2'
>>> section2.name = 'cannot do that, this attribute is read-only on a SectionProxy'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: can't set attribute

----------
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10489>
_______________________________________

From report at bugs.python.org  Sun Nov 21 15:10:25 2010
From: report at bugs.python.org (And Clover)
Date: Sun, 21 Nov 2010 14:10:25 +0000
Subject: [issue10490] mimetypes read_windows_registry fails for non-ASCII keys
In-Reply-To: <1290348624.99.0.246792937165.issue10490@psf.upfronthosting.co.za>
Message-ID: <1290348624.99.0.246792937165.issue10490@psf.upfronthosting.co.za>


New submission from And Clover <and at doxdesk.com>:

The `enum_types` function in `MimeTypes.read_windows_registry` tries to `.encode` the results of `EnumKey`, assuming it to be a Unicode string.

However, `_winreg.EnumKey` in Python 2.x actually returns a byte string (straight from the ANSI version of the registry interface). Consequently, if there is a MIME type registered with a non-ASCII character in its name (invalid, but not unheard of), initialising `MimeTypes` will raise a `UnicodeDecodeError`. This is not caught (it is only expecting a `UnicodeEncodeError`), so it bombs out whatever module indirectly caused `mimetypes.init()` to be called.

This attempt to `.encode` the `ctype` should simply be removed.

----------
components: Library (Lib)
files: mimetypes-patch2-2.7.patch
keywords: patch
messages: 121929
nosy: aclover
priority: normal
severity: normal
status: open
title: mimetypes read_windows_registry fails for non-ASCII keys
versions: Python 2.7
Added file: http://bugs.python.org/file19745/mimetypes-patch2-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10490>
_______________________________________

From report at bugs.python.org  Sun Nov 21 15:12:52 2010
From: report at bugs.python.org (And Clover)
Date: Sun, 21 Nov 2010 14:12:52 +0000
Subject: [issue10490] mimetypes read_windows_registry fails for non-ASCII keys
In-Reply-To: <1290348624.99.0.246792937165.issue10490@psf.upfronthosting.co.za>
Message-ID: <1290348772.73.0.746287056221.issue10490@psf.upfronthosting.co.za>


Changes by And Clover <and at doxdesk.com>:


Removed file: http://bugs.python.org/file19745/mimetypes-patch2-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10490>
_______________________________________

From report at bugs.python.org  Sun Nov 21 15:13:08 2010
From: report at bugs.python.org (And Clover)
Date: Sun, 21 Nov 2010 14:13:08 +0000
Subject: [issue10490] mimetypes read_windows_registry fails for non-ASCII keys
In-Reply-To: <1290348624.99.0.246792937165.issue10490@psf.upfronthosting.co.za>
Message-ID: <1290348788.19.0.737934904599.issue10490@psf.upfronthosting.co.za>


Changes by And Clover <and at doxdesk.com>:


Added file: http://bugs.python.org/file19746/mimetypes-patch2-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10490>
_______________________________________

From report at bugs.python.org  Sun Nov 21 15:27:29 2010
From: report at bugs.python.org (david)
Date: Sun, 21 Nov 2010 14:27:29 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1290345435.3620.2.camel@localhost.localdomain>
Message-ID: <AANLkTim4Rv5QP_dHeHKTzS5X3WdgK8ig6fiSPO49t=Ut@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

Fine.
So if not in the ssl module what about for urllib etc.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 15:28:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 14:28:25 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <AANLkTim4Rv5QP_dHeHKTzS5X3WdgK8ig6fiSPO49t=Ut@mail.gmail.com>
Message-ID: <1290349699.3620.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Fine.
> So if not in the ssl module what about for urllib etc.?

The same answer really... We can't change default settings without
breaking compatibility.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 15:29:53 2010
From: report at bugs.python.org (david)
Date: Sun, 21 Nov 2010 14:29:53 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1290349699.3620.6.camel@localhost.localdomain>
Message-ID: <AANLkTinjfrDzCk2xpGQ7mDwQSEQvoBUXttctevoWCo8=@mail.gmail.com>


david <db.pub.mail at gmail.com> added the comment:

So please close this bug.
Apparently making things secure by default is to much to ask.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 15:36:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 14:36:47 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1290350207.98.0.0571694974363.issue10441@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -db

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 15:39:14 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 21 Nov 2010 14:39:14 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290350354.17.0.648079581389.issue3709@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed this revision 86640.

- Even though this is an internal optimization,I don't think back-porting is a good idea, because it changes the behavior of certain methods like send_header and end_headers

- Added the Documentation and other test scenario which was suggested by RDM.

'endian': In the NEWS entry, I have added your handle. If you want me to mention your Real Name, let me know.

----------
assignee: gregory.p.smith -> orsenthil
resolution:  -> fixed
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/issue3709>
_______________________________________

From report at bugs.python.org  Sun Nov 21 15:51:56 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 14:51:56 +0000
Subject: [issue10468] Document UnicodeError access functions
In-Reply-To: <1290260862.46.0.923226351306.issue10468@psf.upfronthosting.co.za>
Message-ID: <1290351116.34.0.0135713235784.issue10468@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a patch for Doc/c-api/exceptions.rst

Added a new section named "Unicode exceptions", and documented the relevant functions from Include/pyerrors.h

----------
keywords: +patch
Added file: http://bugs.python.org/file19747/issue10468.1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10468>
_______________________________________

From report at bugs.python.org  Sun Nov 21 15:54:50 2010
From: report at bugs.python.org (david)
Date: Sun, 21 Nov 2010 14:54:50 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1290351290.82.0.104643648723.issue10441@psf.upfronthosting.co.za>


Changes by david <db.pub.mail at gmail.com>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:05:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 15:05:11 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1290351911.79.0.565170753622.issue10441@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution: rejected -> 
stage: needs patch -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:11:23 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 21 Nov 2010 15:11:23 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1290352283.26.0.806642982792.issue9182@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Yeah, sorry, those last two should have had arguments after them.

I think we have to stick with the current behavior - otherwise there's no way to do something like -x -A -B, where you want -A and -B to be arguments to -x. (You can get that now with -x -- -A -B.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:11:25 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 21 Nov 2010 15:11:25 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <AANLkTinNs_Ts1B+S_Ye6PjGFqx_MihtA8U+t5-Rpsg6+@mail.gmail.com>
Message-ID: <20101121150949.GA1584@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sun, Nov 21, 2010 at 12:12:08PM +0000, Jeremy Thurgood wrote:
> I see your point now, but I don't agree with it completely. It seems
> reasonable to allow query parameters to specify things like sort
> order for a directory listing or have a fragment to focus the
> browser on a particular entry.

Can you please point me to some examples where such a kind of behavior
is exhibited or designed?

> On the other hand, if we don't want to support the
> redirect with a fragment or query parameters, we should instead return
> a 400 response. 

SimpleHTTPRequestHandler does not support REDIRECT on *a path* (any
path, directory or file, for that matter).  This bug was about a
primitive case where directory in the file system is not specified
with '/', it does a Hardcoded 301 redirect and adds a '/'.

>I can't see any situation in which redirecting
> "/something?foo" to "/something?foo/" is the correct behaviour.

As I explained, in the previous post, this would *not happen* in
practical scenarios, because code won't reach that point for valid
URLs.

> A 401 is "Unauthorized", which means the server is asking for
> authentication -- I don't think that's relevant here.

I am sorry, this was a typo.
It fails with -> urllib.error.HTTPError: HTTP Error 400: Bad Request

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:11:46 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sun, 21 Nov 2010 15:11:46 +0000
Subject: [issue10468] Document UnicodeError access functions
In-Reply-To: <1290260862.46.0.923226351306.issue10468@psf.upfronthosting.co.za>
Message-ID: <1290352306.63.0.937906320445.issue10468@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10468>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:15:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Nov 2010 15:15:06 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290352506.83.0.698055530609.issue3709@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Senthil, I didn't clearly express my concern about send_response_only.  It doesn't look to me like, with buffering in place, that it *should* write directly, it looks to me like it should write to the buffer.  Consider specifically the fact that send_response_only is called from send_response_only, which is in turn called from send_error.

So IMO the unit test should at a minimum test that send_response_only buffers, and ideally it should test that send_error buffers (but that would require a somewhat different test harness since it would need to report that its write method was called only once).

I think the code you committed is still valid, it just doesn't quite do full header buffering.

And I agree that this should not be backported.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:15:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 15:15:22 +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: <1290352522.16.0.81395843964.issue10404@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Apologies, I had misread your message: I thought the keybinding was wrong but working.  Your fix should be committed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10404>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:16:25 2010
From: report at bugs.python.org (Henrique Bastos)
Date: Sun, 21 Nov 2010 15:16:25 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1290352585.25.0.785752208777.issue1745035@psf.upfronthosting.co.za>


Changes by Henrique Bastos <henrique at bastos.net>:


----------
nosy: +henriquebastos

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:18:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 15:18:34 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1290352714.82.0.447677956061.issue10362@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks.  Do you want to work on a patch?  We need to had a test to reproduce the error and then fix the code.

----------
nosy: +orsenthil
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/issue10362>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:25:08 2010
From: report at bugs.python.org (Rodolpho Eckhardt)
Date: Sun, 21 Nov 2010 15:25:08 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1290353108.96.0.539770101176.issue8525@psf.upfronthosting.co.za>


Rodolpho Eckhardt <r at rhe.vg> added the comment:

Migrated the patch to the 3.x trunk and added three tests.

----------
keywords: +patch
nosy: +Rodolpho.Eckhardt, henriquebastos
Added file: http://bugs.python.org/file19748/help_8525.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:38:14 2010
From: report at bugs.python.org (Tarsis Azevedo)
Date: Sun, 21 Nov 2010 15:38:14 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290353894.94.0.280010061822.issue9509@psf.upfronthosting.co.za>


Tarsis Azevedo <tarsis.azevedo at gmail.com> added the comment:

Hi Doug,

I catched the IOError exception and used the error function of ArgumentParser class to return a beautful error message.

----------
keywords: +patch
nosy: +Tarsis.Azevedo
Added file: http://bugs.python.org/file19749/issue9509.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:50:02 2010
From: report at bugs.python.org (ProgVal)
Date: Sun, 21 Nov 2010 15:50:02 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1290354602.18.0.284661035766.issue10362@psf.upfronthosting.co.za>


ProgVal <progval at gmail.com> added the comment:

Same result on all tested versions (2.5 -> 2.7) :

------------------------------------------
import urllib2
import tarfile

tarfile.open(fileobj=open('/home/progval/Downloads/GoodFrench.tar'), mode='r:') # Works
tarfile.open(fileobj=urllib2.urlopen(urllib2.Request('http://plugins.supybot-fr.tk/GoodFrench.tar')), mode='r:') # Fails
------------------------------------------

I don't understand, because /home/progval/Downloads/GoodFrench.tar is the same file...


I don't know if I have the skills to do the patch, I use Python for less than 9 months...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10362>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:50:47 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 21 Nov 2010 15:50:47 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1290352506.83.0.698055530609.issue3709@psf.upfronthosting.co.za>
Message-ID: <20101121154915.GA8671@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sun, Nov 21, 2010 at 03:15:06PM +0000, R. David Murray wrote:
> Senthil, I didn't clearly express my concern about
> send_response_only.  It doesn't look to me like, with buffering in
> place, that it *should* write directly, it looks to me like it
> should write to the buffer.

Correct. Now that I re-looked at the code, keeping your above
statement in mind", I tend to agree with you and notice the problem. I
think, the headers_buffer should be moved higher up in the class so
that it buffer the headers from all these methods which atm write
directly to the output stream.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:52:43 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Sun, 21 Nov 2010 15:52:43 +0000
Subject: [issue969718] BASECFLAGS are not passed to module build line
Message-ID: <1290354763.53.0.59366977787.issue969718@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

I am attaching a preliminary patch to allow override of $(OPT). I am not sure this is sufficient, but am wary of breaking packages that depend on the existing behaviour. 

The logic indeed seems wrong, but maybe this is something that has to go in distutils2 rather than distutils.

----------
keywords: +patch
Added file: http://bugs.python.org/file19750/distutils_opt_flag.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue969718>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:53:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 15:53:04 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1290354784.44.0.991603103664.issue10362@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

2.5 and 2.6 don?t get bug fixes anymore, only security fixes.  If you want to try to fix the code, there are some guidelines at http://www.python.org/dev/patches/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10362>
_______________________________________

From report at bugs.python.org  Sun Nov 21 16:56:09 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 21 Nov 2010 15:56:09 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290354969.34.0.298523766523.issue9509@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

Hi, Tarsis,

That patch looks good to me.

Thanks!
Doug

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sun Nov 21 17:00:59 2010
From: report at bugs.python.org (Gynvael Coldwind)
Date: Sun, 21 Nov 2010 16:00:59 +0000
Subject: [issue10491] Insecure Windows python directory permissions
In-Reply-To: <1290355258.56.0.17518339561.issue10491@psf.upfronthosting.co.za>
Message-ID: <1290355258.56.0.17518339561.issue10491@psf.upfronthosting.co.za>


New submission from Gynvael Coldwind <gynvael at gmail.com>:

Hi,

Installers I've tested:
Python 3.1.2 (signed Sunday, March 21, 2010 12:49:44 AM)
Python 2.7 (signed Sunday, July 04, 2010 7:23:45 AM)

It seems that Python's Windows installer doesn't correctly set permissions of Python's directories, allowing any user on the system to create a file inside these directories.

Using DLL Spoofing method (aka DLL Hijaking or Binary Planting) an unprivileged user can create an arbitrary DLL file (e.g. named python31.dll imported by python.exe) inside that directory, which will get loaded and it's code will get executed when some other user launches any python or the interpreter itself (i.e. this may lead to elevation of privileges).
This has been tested and proved to work.

Easiest way to check:
1. Install Python on Windows (with NTFS partition)
2. Create a user without any administrative permissions
3. Run a command shell in the context of that user
4. Type: echo.>c:\python31\python31.dll (the name of the directory and DLL file may be different)
5. Run c:\python31\python.exe or any python script from any user
You should get the following message:

---------------------------
python.exe - Bad Image
---------------------------
c:\python31\python31.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support. 
---------------------------

This proves that the created DLL file was (tried to be) loaded into the context of the process. 


Main directories ACLs:
C:\Users\test>cacls c:\python31
c:\Python31 NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F
            BUILTIN\Administrators:(OI)(CI)(ID)F
            BUILTIN\Users:(OI)(CI)(ID)R
            BUILTIN\Users:(CI)(ID)(special access:)
                                  FILE_APPEND_DATA

            BUILTIN\Users:(CI)(ID)(special access:)
                                  FILE_WRITE_DATA

            CREATOR OWNER:(OI)(CI)(IO)(ID)F


C:\Users\test>cacls c:\python27
c:\Python27 NT AUTHORITY\SYSTEM:(OI)(CI)(ID)F
            BUILTIN\Administrators:(OI)(CI)(ID)F
            BUILTIN\Users:(OI)(CI)(ID)R
            BUILTIN\Users:(CI)(ID)(special access:)
                                  FILE_APPEND_DATA

            BUILTIN\Users:(CI)(ID)(special access:)
                                  FILE_WRITE_DATA

            CREATOR OWNER:(OI)(CI)(IO)(ID)F

These directories SHOULD NOT allow Users to FILE_APPEND_DATA or FILE_WRITE_DATA.

Suggested fix:
The installer should make sure the FILE_APPEND_DATA and FILE_WRITE_DATA rights are not present in any directories ACLs.

Attached: List of directories found to be insecure (i.e. everyone can create a file there).

----------
components: Installation, Windows
files: Python_dir_list.txt
messages: 121947
nosy: Gynvael.Coldwind
priority: normal
severity: normal
status: open
title: Insecure Windows python directory permissions
type: security
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19751/Python_dir_list.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10491>
_______________________________________

From report at bugs.python.org  Sun Nov 21 17:04:21 2010
From: report at bugs.python.org (Jeremy Thurgood)
Date: Sun, 21 Nov 2010 16:04:21 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <20101121150949.GA1584@rubuntu>
Message-ID: <AANLkTi=GLmjbGnBaxCKM35PfHR2SMdUozib5OG3fq6te@mail.gmail.com>


Jeremy Thurgood <firxen at gmail.com> added the comment:

On Sun, Nov 21, 2010 at 17:11, Senthil Kumaran wrote:

>>I can't see any situation in which redirecting
>> "/something?foo" to "/something?foo/" is the correct behaviour.

> As I explained, in the previous post, this would *not happen* in
> practical scenarios, because code won't reach that point for valid
> URLs.

It reaches that point in the tests I added, and the results confirm
the first two points in the original bug report. Am I mistaken?

"/something?foo" is a valid URL. If "/something" is translated to a
file on the filesystem, the content of that file is returned. If it is
translated to a directory on the filesystem, a 301 to
"/something?foo/" is returned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Sun Nov 21 17:05:04 2010
From: report at bugs.python.org (ProgVal)
Date: Sun, 21 Nov 2010 16:05:04 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1290355504.19.0.847398216743.issue10362@psf.upfronthosting.co.za>


ProgVal <progval at gmail.com> added the comment:

This code :
import urllib2
print urllib2.urlopen('http://plugins.supybot-fr.tk/GoodFrench.tar').read(500)

Prints :
data/0000755000175000017500000000000011466030066011677 5ustar  progvalprogval



If the problem comes from networking libraries, I really don't have the skills :s

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10362>
_______________________________________

From report at bugs.python.org  Sun Nov 21 17:05:25 2010
From: report at bugs.python.org (Daniel Albeseder)
Date: Sun, 21 Nov 2010 16:05:25 +0000
Subject: =?utf-8?q?=5Bissue9182=5D_document_=E2=80=9C--=E2=80=9D_as_a_way_to_disti?=
	=?utf-8?q?nguish_option_w/_narg=3D=27+=27_from_positional_argument_in_arg?=
	=?utf-8?q?parse?=
In-Reply-To: <1278433481.81.0.201692715302.issue9182@psf.upfronthosting.co.za>
Message-ID: <1290355525.62.0.3138418504.issue9182@psf.upfronthosting.co.za>


Daniel Albeseder <kotan at gmx.at> added the comment:

Steven: The last part I guess would belong better in issue 9334. Using a "--" to end all optionals is just a convention but "--" could also be the argument to some option as well. We need to limit this in any way, and the way it is done right now seem very reasonable for me.

Adding some additional unit tests testing this limits might be beneficial but I guess would be best done during issue 9334.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9182>
_______________________________________

From report at bugs.python.org  Sun Nov 21 17:15:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 16:15:39 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1290356139.25.0.866713147269.issue10478@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Wow. 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.

Also, the outer TextIOWrapper (we're talking about sys.stdout here) is not designed to MT-safe at all and is probably in an inconsistent state itself.

I would rather detect that the lock is already taken by the current thread and raise a RuntimeError. I don't think it's a good idea to do buffered I/O in a signal handler. Unbuffered I/O probably works.

(in a more sophisticated version, we could store pending writes so that they get committed at the end of the currently executing write)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10478>
_______________________________________

From report at bugs.python.org  Sun Nov 21 17:49:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 16:49:35 +0000
Subject: [issue10491] Insecure Windows python directory permissions
In-Reply-To: <1290355258.56.0.17518339561.issue10491@psf.upfronthosting.co.za>
Message-ID: <1290358175.89.0.766704722359.issue10491@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10491>
_______________________________________

From report at bugs.python.org  Sun Nov 21 17:57:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Nov 2010 16:57:50 +0000
Subject: [issue10134] test_email failures on Windows: end of line issue?
In-Reply-To: <1287373744.55.0.18095949035.issue10134@psf.upfronthosting.co.za>
Message-ID: <1290358670.75.0.850900085817.issue10134@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is fixed by r86642.  The remaining failing tests were pointing to bugs in the implementation of the linesep argument to generator.flatten.  I had to add an additional test to catch all the related bugs, though.

The tests now run the inversion tests with the source files terminated both with \n and with \r\n, so if there are bugs in this area in the future they should now show up on all platforms.

I've tested this on windows, so I'm closing the bug. Hopefully Brian's buildbot will agree with me :)

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10134>
_______________________________________

From report at bugs.python.org  Sun Nov 21 17:58:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 16:58:07 +0000
Subject: [issue10479] cgitb.py should assume a binary stream for output
In-Reply-To: <1290317837.02.0.152908438377.issue10479@psf.upfronthosting.co.za>
Message-ID: <1290358687.01.0.522204130651.issue10479@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +facundobatista, fdrake, orsenthil
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10479>
_______________________________________

From report at bugs.python.org  Sun Nov 21 17:58:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 16:58:47 +0000
Subject: [issue10486] http.server doesn't set all CGI environment variables
In-Reply-To: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za>
Message-ID: <1290358727.88.0.321911825851.issue10486@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +facundobatista, fdrake, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10486>
_______________________________________

From report at bugs.python.org  Sun Nov 21 17:59:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 16:59:18 +0000
Subject: [issue10485] http.server fails when query string contains addition
	'?' characters
In-Reply-To: <1290325094.43.0.114667735532.issue10485@psf.upfronthosting.co.za>
Message-ID: <1290358758.38.0.470590217593.issue10485@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +facundobatista, fdrake, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10485>
_______________________________________

From report at bugs.python.org  Sun Nov 21 17:59:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 16:59:36 +0000
Subject: [issue10484] http.server.is_cgi fails to handle CGI URLs containing
	PATH_INFO
In-Reply-To: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za>
Message-ID: <1290358776.81.0.30843694908.issue10484@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +facundobatista, fdrake, orsenthil
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10484>
_______________________________________

From report at bugs.python.org  Sun Nov 21 18:00:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 17:00:02 +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: <1290358802.42.0.255679741074.issue10487@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +facundobatista, fdrake, orsenthil
type: behavior -> feature request
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10487>
_______________________________________

From report at bugs.python.org  Sun Nov 21 18:09:20 2010
From: report at bugs.python.org (=?utf-8?q?Rafael_dos_Santos_Gon=C3=A7alves?=)
Date: Sun, 21 Nov 2010 17:09:20 +0000
Subject: [issue1043134] mimetypes.guess_extension('text/plain') == '.ksh' ???
Message-ID: <1290359360.95.0.773050118761.issue1043134@psf.upfronthosting.co.za>


Rafael dos Santos Gon?alves <rafaelsantosg at gmail.com> added the comment:

ksh is a text/plain to, all this extension are text/plain:
'.ksh', '.pl', '.bat', '.h', '.c', '.txt', '.asc', '.text', '.pot', '.brf'.
The problem is: the code return the first of list:
return extensions[0]
So, I add one boolean parameter in method guess_extension called all_exts. Putting True in this parameter the method returns a tuple with all possible extensions.

I hope helped

----------
keywords: +patch
nosy: +elesbom
Added file: http://bugs.python.org/file19752/issue1043134.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1043134>
_______________________________________

From report at bugs.python.org  Sun Nov 21 18:09:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 17:09:28 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1290359368.35.0.646586052769.issue10478@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/issue10478>
_______________________________________

From report at bugs.python.org  Sun Nov 21 18:24:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 17:24:04 +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: <1290360243.96.0.603687934233.issue10492@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

$ LANG=ISO-8859-15 ./python -m test.regrtest test_doctest
[1/1] test_doctest
**********************************************************************
File "/home/antoine/py3k/__svn__/Lib/test/test_doctest.py", line 1676, in test.test_doctest.test_debug
Failed example:
    try: doctest.debug_src(s)
    finally: sys.stdin = real_stdin
Expected:
    > <string>(1)<module>()
    (Pdb) next
    12
    --Return--
    > <string>(1)<module>()->None
    (Pdb) print(x)
    12
    (Pdb) continue
Got:
    > /home/antoine/py3k/__svn__/Lib/encodings/iso8859_15.py(15)decode()
    -> return codecs.charmap_decode(input,errors,decoding_table)
    (Pdb) next
    --Return--
    > /home/antoine/py3k/__svn__/Lib/encodings/iso8859_15.py(15)decode()->('<string>', 8)
    -> return codecs.charmap_decode(input,errors,decoding_table)
    (Pdb) print(x)
    *** NameError: name 'x' is not defined
    (Pdb) continue
    12
**********************************************************************
1 items had failures:
   1 of   4 in test.test_doctest.test_debug
***Test Failed*** 1 failures.
test test_doctest failed -- 1 of 429 doctests failed
1 test failed:
    test_doctest


Also visible on the following buildbot:
http://www.python.org/dev/buildbot/all/builders/x86%20debian%20parallel%203.x/builds/934/steps/test/logs/stdio

----------
components: Library (Lib), Tests
messages: 121954
nosy: haypo, loewis, pitrou, tim_one
priority: normal
severity: normal
stage: needs patch
status: open
title: test_doctest fails with iso-8859-15 locale
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10492>
_______________________________________

From report at bugs.python.org  Sun Nov 21 19:23:27 2010
From: report at bugs.python.org (Mauro Navarro Baraldi)
Date: Sun, 21 Nov 2010 18:23:27 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1290363807.98.0.783240095493.issue8890@psf.upfronthosting.co.za>


Mauro Navarro Baraldi <mauro.baraldi at gmail.com> added the comment:

Reviewing this thread and talking with another friends, I thought that the pythonic way to solve it should be use the tempfile module.

And here is a suggestion using the logging module with tempfile.

> import logging
> import tempfile
> fp, LOG_FILENAME = tempfile.mkstemp(suffix=".log")
> logging.basicConfig(filename=LOG_FILENAME, level=logging.DEBUG)
> logging.debug('This message should go to the log file')
> LOG_FILENAME
'/tmp/tmprBhZz1.log'

----------
components: +Demos and Tools -Documentation

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sun Nov 21 19:24:42 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sun, 21 Nov 2010 18:24:42 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>
Message-ID: <1290363882.13.0.672986752312.issue10427@psf.upfronthosting.co.za>


Rodrigo Bernardo Pimentel <rbp at isnomore.net> added the comment:

I was writing tests for this issue, when something struck me: ok, datetime(year, month, day, 24) is valid. But is datetime(year, month, day, 24, 1) valid? Or datetime(year, month, day, 24, 0, 0, 1)?

I would say those aren't valid, although that makes checking forvalid hour values slightly weird (as in not straightforward): 24 is valid if minutes, seconds and microseconds are all 0, but invalid otherwise.

What do you think?

----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10427>
_______________________________________

From report at bugs.python.org  Sun Nov 21 19:27:01 2010
From: report at bugs.python.org (Bruno Gola)
Date: Sun, 21 Nov 2010 18:27:01 +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: <1290364021.57.0.0127027582601.issue10492@psf.upfronthosting.co.za>


Bruno Gola <brunogola at gmail.com> added the comment:

tests are OK for me

running on ubuntu 10.04 64bits and py3k from svn repository.

----------
nosy: +brunogola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10492>
_______________________________________

From report at bugs.python.org  Sun Nov 21 19:38:54 2010
From: report at bugs.python.org (Phillip J. Eby)
Date: Sun, 21 Nov 2010 18:38:54 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290364734.37.0.470271754533.issue5800@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Yes, please consider the type->isinstance part of the change rejected.  I just got done reverting a bunch of those in 3.2.  Where WSGI specifies types, it means "type() is", not "isinstance".

(The 3.x version of wsgiref does not need to be executable on 2.x versions, but this doesn't mean the protocol itself can be altered in backwards-incompatible ways, just the implementation.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Sun Nov 21 19:41:05 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 21 Nov 2010 18:41:05 +0000
Subject: [issue10491] Insecure Windows python directory permissions
In-Reply-To: <1290355258.56.0.17518339561.issue10491@psf.upfronthosting.co.za>
Message-ID: <1290364865.41.0.176508448533.issue10491@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/issue10491>
_______________________________________

From report at bugs.python.org  Sun Nov 21 19:41:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 18:41:43 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1290364903.16.0.267791333138.issue8890@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> docs at python
components: +Documentation -Demos and Tools

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Sun Nov 21 19:42:57 2010
From: report at bugs.python.org (SilentGhost)
Date: Sun, 21 Nov 2010 18:42:57 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290364977.94.0.436296997475.issue5800@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Do I have to resubmit the patch or can you use the existing one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Sun Nov 21 19:47:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Nov 2010 18:47:01 +0000
Subject: [issue1699853] locale.getlocale() output fails as setlocale() input
Message-ID: <1290365221.91.0.653773509254.issue1699853@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In investigating issue 10466 I find that getlocale on windows returns the value that windows accepts for me.  For example on my US windows system, getlocale returns ('English_United States', '1252'), and that appears to work when passed to setlocale.  So I'm closing this bug as works for me, since I can't reproduce it.  (Tested on 3.2a3 and 2.6.5).

Issue 10466 turns on the fact that getdefaultlocale() does *not* return something that windows can consume, though.

----------
nosy: +r.david.murray
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699853>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:04:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 21 Nov 2010 19:04:43 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1290366283.46.0.982154112833.issue10466@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 1699853.

The problem here is that resetlocale calls getdefaultlocale, and getdefaultlocale returns something that setlocale cannot consume on Windows.  For example, on my US windows system, getlocale returns ('English_United States', '1252'), while getdefaultlocale returns ('en_US', 'cp1252').  The latter results in the 'unsupported locale settting' error message when passed to setlocale.

Since getdefaultlocale contains special-case code for the win32 platform, I wonder if this is a bug in getdefaultlocale.  I suspect it is operating as designed, but is that operation useful if the result isn't recognized by the platform in question?  Or if, as it appears from looking at the Python code (but I haven't looked at the C code) the data is actually coming from the C runtime, perhaps the bug is that setlocale doesn't accept the output of getdefaultlocale on windows?

Hopefully Mark Andre will have an answer, but I've also added our windows experts to nosy to see if they have any insights.

Given the long standing nature of this issue, it seems that the priority isn't very high, especially since the bug is revealed not by user code but by a diagnostic routine in the stdlib.

----------
nosy: +brian.curtin, tim.golden
priority: normal -> low
title: locale.py throws exception on Windows / Non-UTF8 system -> locale.py resetlocale throws exception on Windows
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:05:58 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 19:05:58 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1290346579.13.0.134837546765.issue7995@psf.upfronthosting.co.za>
Message-ID: <4CE96D92.4080207@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The answer depends on what the socket module is trying to do.  Is the
> goal simply to provide a pythonic thin wrapper over the underlying OS
> interfaces without altering their semantics, or to provide a
> completely homogeneous abstraction?

Most definitely the latter. The method called accept must absolutely
always call the same-named underlying system call, and have no other
side effects, unless
a) the system doesn't provide such a system call, or
b) something else is called, but this behaves *as if* the original
   system call was called, or
c) deviating behavior was explicitly requested from the application.

> The docs have a big bold note right up top, "Note Some behavior may
> be platform dependent, since calls are made to the operating system
> socket APIs".

Having such a note is fine with me; it shouldn't be big and bold,
though. There is a strong opposition to big and bold notes; they
should be only used for really serious problems (such as the likely
risk of data loss).

> Anyway, my personal opinion is that we should consider the current
> behavior a bug and fix it.  I like the idea of setting all accepted
> sockets to blocking mode (and documenting it clearly).

-1.

> I think it is what most people would expect.

Apparently, the designers of BSD thought differently. Remember that
it is them who defined the socket API in the first place, so they
have the right that their design decisions are considered.

We should also take issue10115 into account, which proposes changes
to accept on Linux. One solution might to add optional flags to
accept(), asking for certain behavior variations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:07:56 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 21 Nov 2010 19:07:56 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290366476.86.0.416813960248.issue7094@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file19722/issue7094.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:08:23 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 21 Nov 2010 19:08:23 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290366503.94.0.0852335681379.issue7094@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Updated patch. I'm pretty happy with this one and will commit it after review.

----------
Added file: http://bugs.python.org/file19753/issue7094.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:10:52 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 21 Nov 2010 19:10:52 +0000
Subject: [issue9424] Disable unittest.TestCase.assertEquals and assert_ during
	a regrtest run
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1290366652.92.0.259885483763.issue9424@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I merged the patch on 3.1 in r86629 and on 2.7 in r86637.

I would like to propose the following deprecation schedules for the deprecated fail* and assert* methods:

* for the fail* methods:
  add a DeprecationWarning in 3.1 (done in r74096);
  remove them in 3.3 (see msg65142);

* for the assert* methods:
  add a DeprecationWarning in 3.2;
  leave them around for a few more versions;

These deprecations should be documented on whatsnew3.2 too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9424>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:17:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 19:17:20 +0000
Subject: [issue10491] Insecure Windows python directory permissions
In-Reply-To: <1290355258.56.0.17518339561.issue10491@psf.upfronthosting.co.za>
Message-ID: <1290367040.24.0.378801368338.issue10491@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is a duplicate of issue1284316

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Win32: Security problem with default installation directory

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10491>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:18:34 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Sun, 21 Nov 2010 19:18:34 +0000
Subject: [issue1043134] mimetypes.guess_extension('text/plain') == '.ksh' ???
Message-ID: <1290367114.79.0.0164939456176.issue1043134@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

Rafael,

There is already a method which returns all the extensions. What is required is a flag (or separate dict) which provides a canonical extension. The questions is whether it is sufficient to rely on the default provided mimetypes for the default in the face of mimetypes read out of the mimetypes files or windows registry.

I don't see a way to fix the bug, without also providing an API to "pick the winner" for those cases that are not provided in the default list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1043134>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:19:01 2010
From: report at bugs.python.org (ingo janssen)
Date: Sun, 21 Nov 2010 19:19:01 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1290363882.13.0.672986752312.issue10427@psf.upfronthosting.co.za>
Message-ID: <AANLkTikmTAy0+Wj7oT4vP56d7ETAdWLByFpWz5Jdcm1_@mail.gmail.com>


ingo janssen <ingoogni at gmail.com> added the comment:

On Sun, Nov 21, 2010 at 7:24 PM, Rodrigo Bernardo Pimentel wrote:

> I would say those aren't valid, although that makes checking forvalid hour values slightly weird
>(as in not straightforward): 24 is valid if minutes, seconds and microseconds are all 0, but invalid
>otherwise.

Indeed anything beyond 24:0:0 is invalid

ingo

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10427>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:26:18 2010
From: report at bugs.python.org (Justin Cappos)
Date: Sun, 21 Nov 2010 19:26:18 +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: <1290367578.28.0.784774582897.issue7995@psf.upfronthosting.co.za>


Justin Cappos <justincappos at gmail.com> added the comment:

> Apparently, the designers of BSD thought differently. Remember that
> it is them who defined the socket API in the first place, so they
> have the right that their design decisions are considered.

I think there is a bit of confusion here.   The 'bug' isn't with different socket semantics on different OSes.   The bug is that the programmer who wrote the wrapper for sockets on Python assumed the OS semantics weren't the BSD style.   


Here is the issue (put plainly):

Python sockets support a notion of timeout  (note this notion is not reflected in the OS socket API).

The python socket implementation of timeouts uses the underlying OS / socket API to provide this by setting the socket to nonblocking and setting a timeout value in a Python object that holds socket info.

This implementation assumes that the OS sets any socket it receives via accept to nonblocking.   (this is a false assumption on BSD)

The end result is that the OS has a nonblocking socket and the Python object thinks it is blocking.   This is why the socket object in Python has timeout=None yet calling fcntl shows the socket is nonblocking.

Calling code paths that handle timeouts and expect the socket to block causes bugs like I described in my code.   This behavior is clearly wrong under any interpretation!


You can debate whether the right patch is to use what I proposed or instead change new Python sockets to inherit the timeout / blocking setting on BSD.   However, what is implemented now is clearly broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:26:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 19:26:38 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290367598.2.0.278985291625.issue7094@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I haven't done a full review, but this looks good at first glance.

For '#g' formatting on the Decimal type, I wonder whether the patch gives the right semantics.  E.g., should

   format(Decimal('1.23'), '#.6g')

give '1.23' or '1.23000'?  For the float type, the '#.<precision>g' formatting has the property that <precision> digits are always returned, and I think this may be what we want here.  I'm not sure, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:31:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 19:31:34 +0000
Subject: [issue1475523] gettext breaks on plural-forms header
Message-ID: <1290367894.38.0.416973689176.issue1475523@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy:  -BreamoreBoy
resolution: accepted -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1475523>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:31:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 19:31:45 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290367905.1.0.970987342367.issue7094@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think the change below is sufficient if we decide that the '#g' formatting should always have the given number of significant digits.

--- Lib/decimal.py      (revision 86635)
+++ Lib/decimal.py      (working copy)
@@ -3701,7 +3701,8 @@
                 self = self._round(precision+1, rounding)
             elif spec['type'] in 'fF%':
                 self = self._rescale(-precision, rounding)
-            elif spec['type'] in 'gG' and len(self._int) > precision:
+            elif spec['type'] in 'gG' and (len(self._int) > precision or
+                                           spec['alt']):
                 self = self._round(precision, rounding)
         # special case: zeros with a positive exponent can't be
         # represented in fixed point; rescale them to 0e0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:43:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 19:43:22 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290368602.08.0.0230436510133.issue7094@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Gah.  That doesn't work for zeros, though.

Apart from this, the rest of the patch looks good, and all tests pass on my machine.  (Well, except for test_urllib2_localnet, but I'm pretty sure that failure is unrelated.)

I hadn't realized the use_alt_formatting stuff was already present in Python/pystrtod.c.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Sun Nov 21 20:45:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 19:45:45 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <4CE96D92.4080207@v.loewis.de>
Message-ID: <1290368740.3620.37.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Anyway, my personal opinion is that we should consider the current
> > behavior a bug and fix it.  I like the idea of setting all accepted
> > sockets to blocking mode (and documenting it clearly).
> 
> -1.
> 
> > I think it is what most people would expect.
> 
> Apparently, the designers of BSD thought differently. Remember that
> it is them who defined the socket API in the first place, so they
> have the right that their design decisions are considered.

We are talking about the timeout feature, which is a Python feature, not
a BSD (or Linux) sockets feature. It should work properly, even if that
means adding some boilerplate around system calls.

> We should also take issue10115 into account, which proposes changes
> to accept on Linux. One solution might to add optional flags to
> accept(), asking for certain behavior variations.

Adding flags to control inheritance could be done. But here the problem
is that the behaviour is buggy even without assuming the API makes any
promise w.r.t. inheritance.
(in other words, while issue10115 is a feature request, this issue is
really a bug)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:11:15 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 21 Nov 2010 20:11:15 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290370275.09.0.495794681423.issue10470@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Sorry for the late reply. I don't think the patch as provided is sufficient as it would interfere with people causing unittest.main() directly from a test module. Checking that TestProgram.loader is None is the way to detect we have been launched from the command line via "python -m unittest ..".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:14:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 20:14:47 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1290367578.28.0.784774582897.issue7995@psf.upfronthosting.co.za>
Message-ID: <4CE97D30.6020408@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Here is the issue (put plainly):

Unfortunately, I still don't understand it. I go through your plain
elaboration below.

> Python sockets support a notion of timeout  (note this notion is not
> reflected in the OS socket API).

Correct.

> The python socket implementation of timeouts uses the underlying OS /
> socket API to provide this by setting the socket to nonblocking and
> setting a timeout value in a Python object that holds socket info.

Correct.

> This implementation assumes that the OS sets any socket it receives
> via accept to nonblocking.   (this is a false assumption on BSD)

Not true. It doesn't assume that (it doesn't assume the reverse,
either).

> The end result is that the OS has a nonblocking socket and the Python
> object thinks it is blocking.   This is why the socket object in
> Python has timeout=None yet calling fcntl shows the socket is
> nonblocking.

That conclusion is flawed. Python has not associated a timeout with
the socket. It makes no claims as to whether the socket is blocking
or not. So you have created a non-blocking socket without timeout.

I cannot see anything wrong with such a thing. The system explicitly
supports such sockets (and, as you point out, it doesn't even have
the notion of "per-socket timeouts"). And so should Python support
them as well.

> Calling code paths that handle timeouts and expect the socket to
> block causes bugs like I described in my code.   This behavior is
> clearly wrong under any interpretation!

What about my interpretation above?
1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:16:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 20:16:05 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1290368740.3620.37.camel@localhost.localdomain>
Message-ID: <4CE97E02.1040401@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> We are talking about the timeout feature, which is a Python feature, not
> a BSD (or Linux) sockets feature. It should work properly, even if that
> means adding some boilerplate around system calls.

I agree that the semantics of the socket timeout API is confusing (and I
wish it had not been added in the first place). However, making it work
"better" must not cause breakage to other legitimate applications.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:19:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 20:19:29 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1290370769.94.0.0170577513111.issue10441@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Here is a patch that changes SSLContext into a context manager, allowing to write code like

    with ssl.SSLContext(ssl.PROTOCOL_SSLv23):
        ssl.SSLContext.current().set_default_verify_path()
        res = urllib.request.urlopen("https://www.microsoft.com")

If people like this approach, feel free to adjust it; I likely won't have much time to work on it further.

----------
keywords: +patch
Added file: http://bugs.python.org/file19754/ssl.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10441>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:21:10 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 21 Nov 2010 20:21:10 +0000
Subject: [issue10027] os.lstat/os.stat don't set st_nlink on Windows
In-Reply-To: <1286289327.29.0.159315245099.issue10027@psf.upfronthosting.co.za>
Message-ID: <1290370870.57.0.902240739165.issue10027@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you for reply. Could you commit my last patch
instead of me? I cannot commit files for a while.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:24:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 20:24:39 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <4CE97E02.1040401@v.loewis.de>
Message-ID: <1290371074.3620.45.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le dimanche 21 novembre 2010 ? 20:16 +0000, Martin v. L?wis a ?crit :
> 
> > We are talking about the timeout feature, which is a Python feature, not
> > a BSD (or Linux) sockets feature. It should work properly, even if that
> > means adding some boilerplate around system calls.
> 
> I agree that the semantics of the socket timeout API is confusing (and I
> wish it had not been added in the first place). However, making it work
> "better" must not cause breakage to other legitimate applications.

Well, I don't think setting a timeout on a listening socket and then
expecting the socket received through accept() to be non-blocking (but
only on BSD) is a legitimate application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:26:56 2010
From: report at bugs.python.org (Justin Cappos)
Date: Sun, 21 Nov 2010 20:26:56 +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: <1290371216.68.0.900140278132.issue7995@psf.upfronthosting.co.za>


Justin Cappos <justincappos at gmail.com> added the comment:

>> This implementation assumes that the OS sets any socket it receives
>> via accept to nonblocking.   (this is a false assumption on BSD)
>
> Not true. It doesn't assume that (it doesn't assume the reverse,
> either).

The Python implementation sets timeout=None (which implies that the
underlying socket is blocking).


>> The end result is that the OS has a nonblocking socket and the Python
>> object thinks it is blocking.   This is why the socket object in
>> Python has timeout=None yet calling fcntl shows the socket is
>> nonblocking.
>
> That conclusion is flawed. Python has not associated a timeout with
> the socket. It makes no claims as to whether the socket is blocking
> or not. So you have created a non-blocking socket without timeout.

The problem is that it has.   It has created a new Python socket
object with a specific value for timeout (None), but the underlying
socket is nonblocking.

The docs state that timeout = None makes the socket blocking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:29:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 21 Nov 2010 20:29:07 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1290363882.13.0.672986752312.issue10427@psf.upfronthosting.co.za>
Message-ID: <AANLkTikU_qx8c5n5s2RRrEqFqTrWL7TNQQaqraoU-6jA@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 21, 2010 at 1:24 PM, Rodrigo Bernardo Pimentel
<report at bugs.python.org> wrote:
..
> I was writing tests for this issue, when something struck me: ok, datetime(year, month, day, 24) is valid.
> But is datetime(year, month, day, 24, 1) valid? Or datetime(year, month, day, 24, 0, 0, 1)?
>

As you make progress on the patch, you will face more questions.  For
example, what should datetime(y, m, d, 24).date() return?  date(y, m,
d) or date(y, m, d) + timedelta(1)?  Should strptime() parse '24' as a
valid %H field? Similarly, should strftime() produce '24'?  Is
datetime(y, m, d, 24) equal to datetime(y, m, d) + timedelta(1)? If
so, hash calculation should be special cased.

On your original question, I feel that hour=24 should be allowed
regardless of the other values.  I would recommend, however, that you
review python-dev discussion about allowing second=60 (search for
"leap second").  Once you have a reference implementation you will
need to explain motivations behind your choices on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10427>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:34:46 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Sun, 21 Nov 2010 20:34:46 +0000
Subject: [issue9063] TZ examples in datetime.rst are incorrect
In-Reply-To: <1277313287.04.0.19115846548.issue9063@psf.upfronthosting.co.za>
Message-ID: <1290371686.44.0.947431082879.issue9063@psf.upfronthosting.co.za>


Changes by Rodrigo Bernardo Pimentel <rbp at isnomore.net>:


----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9063>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:36:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 20:36:34 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1290371074.3620.45.camel@localhost.localdomain>
Message-ID: <4CE982CE.7020406@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Well, I don't think setting a timeout on a listening socket and then
> expecting the socket received through accept() to be non-blocking (but
> only on BSD) is a legitimate application.

Right. But setting the server socket to nonblocking, and then expecting
the connection socket to also be nonblocking might be.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:36:47 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 21 Nov 2010 20:36:47 +0000
Subject: [issue9424] Disable unittest.TestCase.assertEquals and assert_ during
	a regrtest run
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1290371807.94.0.612951791093.issue9424@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The attached patch (issue9424-2.diff) addresses the point 2) of msg113147.

----------
Added file: http://bugs.python.org/file19755/issue9424-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9424>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:40:35 2010
From: report at bugs.python.org (Justin Cappos)
Date: Sun, 21 Nov 2010 20:40:35 +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: <1290372035.17.0.457676089087.issue7995@psf.upfronthosting.co.za>


Justin Cappos <justincappos at gmail.com> added the comment:

> > Well, I don't think setting a timeout on a listening socket and then
> > expecting the socket received through accept() to be non-blocking (but
> > only on BSD) is a legitimate application.
>
>
> Right. But setting the server socket to nonblocking, and then 
> expecting the connection socket to also be nonblocking might be.

Okay sure.   This is fine.   That is why I suggested that if you don't like my patch, one might instead change new Python sockets to inherit the timeout / blocking setting on BSD.

However, I hope we can all agree that having the Python socket object in a different blocking / non-blocking state than the OS socket descriptor is wrong.   This is what needs to be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:41:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 20:41:41 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1290371216.68.0.900140278132.issue7995@psf.upfronthosting.co.za>
Message-ID: <4CE98403.6080501@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The Python implementation sets timeout=None (which implies that the
> underlying socket is blocking).

No, it doesn't. A socket may be non-blocking without having a timeout;
that's the socket API (on all systems, not just BSD).

> The problem is that it has.   It has created a new Python socket
> object with a specific value for timeout (None), but the underlying
> socket is nonblocking.
> 
> The docs state that timeout = None makes the socket blocking.

What specific wording are you looking at that makes you believe so?
To me, the phrase

# A socket object can be in one of three modes: blocking, non-blocking,
# or timeout

suggests otherwise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:48:54 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 20:48:54 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>
Message-ID: <1290372534.23.0.372628773275.issue10427@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> As you make progress on the patch, you will face more questions.

Well, if all that's wanted is for hour==24 to be legal on input, with the datetime object itself being automatically normalized at creation time, then the choices seem simple:  e.g.,

> For example, what should datetime(y, m, d, 24).date() return?  date(y,
> m, d) or date(y, m, d) + timedelta(1)?

The latter, since the two datetime objects would be indistinguishable...

> Should strptime() parse '24' as a valid %H field?

I'd say yes, provided that any minute, second or subsecond fields are all zero.

FWIW, I'm in the camp that says hour==24 should only be legal if all values for smaller time units are zero.


If a datetime object created with 'hour==24' doesn't immediately normalize itself, then I agree there are going to be a lot of hairy questions...

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10427>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:49:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 20:49:28 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1290372035.17.0.457676089087.issue7995@psf.upfronthosting.co.za>
Message-ID: <4CE985D6.7030408@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> However, I hope we can all agree that having the Python socket object
> in a different blocking / non-blocking state than the OS socket
> descriptor is wrong.   This is what needs to be fixed.

Ok, now I see where your misunderstanding is: you simply can't infer
from calling .gettimeout() whether the socket is blocking or not.
Python does not "think" you can, nor should you. So I don't think
anything needs to be fixed in this respect.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:53:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 20:53:11 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290372791.92.0.955623508124.issue9509@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good to me too.  Steven, does this require a test?

----------
nosy: +eric.araujo
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:55:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 21 Nov 2010 20:55:43 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1290372534.23.0.372628773275.issue10427@psf.upfronthosting.co.za>
Message-ID: <AANLkTin0wbdz2W1GzZW_7aozqS-T=oBf=Nc-VuQ1N-vD@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 21, 2010 at 3:48 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
> Well, if all that's wanted is for hour==24 to be legal on input, with the datetime object
> itself being automatically normalized at creation time, then the choices seem simple:?..

What about time objects? If we take the "normalized at creation time"
approach, time(24) may still be disallowed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10427>
_______________________________________

From report at bugs.python.org  Sun Nov 21 21:58:14 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 20:58:14 +0000
Subject: [issue10427] 24:00 Hour in DateTime
In-Reply-To: <1289831880.43.0.381934582888.issue10427@psf.upfronthosting.co.za>
Message-ID: <1290373094.54.0.207949673488.issue10427@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> What about time objects? If we take the "normalized at creation time"
> approach, time(24) may still be disallowed.

Yes, I guess that would follow.  That wouldn't bother me too much. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10427>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:00:14 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 21:00:14 +0000
Subject: [issue10488] Improve documentation for 'float' built-in.
In-Reply-To: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>
Message-ID: <1290373214.54.0.777204291045.issue10488@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: docs at python -> mark.dickinson
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10488>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:05:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 21:05:22 +0000
Subject: [issue8561] Install .exes generated with distutils to not do a CRC
	check
In-Reply-To: <1272482067.44.0.313764636607.issue8561@psf.upfronthosting.co.za>
Message-ID: <1290373522.85.0.981096918597.issue8561@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

No reply, closing.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8561>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:05:28 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 21 Nov 2010 21:05:28 +0000
Subject: [issue10493] test_strptime failures under OpenIndiana
In-Reply-To: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>
Message-ID: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

Python 3.1 head is reporting failures in test_strptime under OpenIndiana 147. For example http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.1/builds/3/steps/test/logs/stdio


Python 2.7 and 3.2 heads are working fine.

----------
components: Extension Modules
messages: 121991
nosy: jcea
priority: release blocker
severity: normal
stage: needs patch
status: open
title: test_strptime failures under OpenIndiana
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10493>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:10:03 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 21 Nov 2010 21:10:03 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290373803.11.0.783453045865.issue7094@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I didn't realize it either, or I would have done this patch months ago. But of course it's needed for %-formatting.

I'll consider the 'g' case and see what I come up with.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:11:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 21 Nov 2010 21:11:00 +0000
Subject: [issue10488] Improve documentation for 'float' built-in.
In-Reply-To: <1290342348.22.0.717400687136.issue10488@psf.upfronthosting.co.za>
Message-ID: <1290373860.23.0.708703521871.issue10488@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

r86648.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10488>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:12:18 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 21 Nov 2010 21:12:18 +0000
Subject: [issue10493] test_strptime failures under OpenIndiana
In-Reply-To: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>
Message-ID: <1290373938.0.0.0437336049629.issue10493@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I have access to the machine, so if somebody want to do some kind of test, just ask.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10493>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:13:26 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 21 Nov 2010 21:13:26 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290374006.56.0.557093150284.issue9509@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

Oh, yeah, a test is a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:14:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 21 Nov 2010 21:14:18 +0000
Subject: [issue10493] test_strptime failures under OpenIndiana
In-Reply-To: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>
Message-ID: <1290374058.23.0.649238392088.issue10493@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10493>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:18:48 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 21:18:48 +0000
Subject: [issue10345] fcntl.ioctl always fails claiming an invalid fd
In-Reply-To: <1289092604.86.0.0417079814942.issue10345@psf.upfronthosting.co.za>
Message-ID: <1290374328.65.0.538992803576.issue10345@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

If you call ioctl with the mutate_flag True, you need to pass "an object supporting the read-write buffer protocol" as the arg parameter for the results of ioctl to be returned in.  In your example, you pass a bytes object which is immutable.  Try using a bytesarray object instead, which is mutable, or, for instance, an array object as shown in the documentation.

http://docs.python.org/py3k/library/fcntl.html#fcntl.ioctl

http://docs.python.org/py3k/library/stdtypes.html#bytes-and-byte-array-methods

----------
nosy: +ned.deily
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10345>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:19:48 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 21:19:48 +0000
Subject: [issue10345] fcntl.ioctl always fails claiming an invalid fd
In-Reply-To: <1289092604.86.0.0417079814942.issue10345@psf.upfronthosting.co.za>
Message-ID: <1290374388.97.0.22220403683.issue10345@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

If you call ioctl with the mutate_flag True, you need to pass "an object supporting the read-write buffer protocol" as the arg parameter for the results of ioctl to be returned in.  In your example, you pass a bytes object which is immutable.  Try using a bytearray object instead, which is mutable, or, for instance, an array object as shown in the documentation.

http://docs.python.org/py3k/library/fcntl.html#fcntl.ioctl

http://docs.python.org/py3k/library/stdtypes.html#bytes-and-byte-array-methods

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10345>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:19:54 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 21:19:54 +0000
Subject: [issue10345] fcntl.ioctl always fails claiming an invalid fd
In-Reply-To: <1289092604.86.0.0417079814942.issue10345@psf.upfronthosting.co.za>
Message-ID: <1290374394.38.0.604964739273.issue10345@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg121996

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10345>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:22:49 2010
From: report at bugs.python.org (Roy Smith)
Date: Sun, 21 Nov 2010 21:22:49 +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: <1290374569.58.0.968912618321.issue7995@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

I got into this by starting with Issue7322, which reports a scenario where data is lost using makefile().  The docs for makefile() say, "The socket must be in blocking mode (it can not have a timeout)".  So, we've got published documentation which equates non-blocking mode with a timeout set.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:31:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 21 Nov 2010 21:31:20 +0000
Subject: [issue10493] test_strptime failures under OpenIndiana
In-Reply-To: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>
Message-ID: <1290375080.91.0.572669683703.issue10493@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

AssertionError: strftime does not support standard '%d' format (day of month as number (00-31))

Sounds pretty self-explainatory.  I kind of doubt, however, that OpenIndiana's strftime is that broken.  Jes?s, can you test it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10493>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:33:04 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 21 Nov 2010 21:33:04 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290375184.77.0.901267570442.issue10470@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Committed revision 86649.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Sun Nov 21 22:51:59 2010
From: report at bugs.python.org (Sibylle Koczian)
Date: Sun, 21 Nov 2010 21:51:59 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
In-Reply-To: <1290366283.46.0.982154112833.issue10466@psf.upfronthosting.co.za>
Message-ID: <4CE9946E.8040108@t-online.de>


Sibylle Koczian <sibylle.koczian at t-online.de> added the comment:

Am 21.11.2010 20:04, schrieb R. David Murray:
>
> R. David Murray<rdmurray at bitdance.com>  added the comment:
>
> Given the long standing nature of this issue, it seems that the
> priority isn't very high, especially since the bug is revealed not by
> user code but by a diagnostic routine in the stdlib.
>

It's true that the bug is quite old, but first it crashed my 
application, then I found that locale.py doesn't run as a script. I put 
that into the tracker simply because it's so easy to reproduce.

But this is almost as simple (and it's the same bug, isn't it?):

Python 3.1.2 (r312:79149, Mar 20 2010, 22:55:39) [MSC v.1500 64 bit 
(AMD64)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
 >>> import calendar
 >>> kal = calendar.localeHTMLCalendar()
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'localeHTMLCalendar'
 >>> kal = calendar.LocaleHTMLCalendar()
 >>> kal_aus = kal.formatyearpage(2011)
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "C:\Python31\lib\calendar.py", line 478, in formatyearpage
     a(self.formatyear(theyear, width))
   File "C:\Python31\lib\calendar.py", line 454, in formatyear
     a(self.formatmonth(theyear, m, withyear=False))
   File "C:\Python31\lib\calendar.py", line 427, in formatmonth
     a(self.formatmonthname(theyear, themonth, withyear=withyear))
   File "C:\Python31\lib\calendar.py", line 546, in formatmonthname
     with different_locale(self.locale):
   File "C:\Python31\lib\calendar.py", line 489, in __enter__
     self.oldlocale = _locale.setlocale(_locale.LC_TIME, self.locale)
   File "C:\Python31\lib\locale.py", line 527, in setlocale
     return _setlocale(category, locale)
locale.Error: unsupported locale setting
 >>>

This would be quite unfunny if I couldn't run my script on Linux instead.

Sibylle

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:03:46 2010
From: report at bugs.python.org (Kevin Le)
Date: Sun, 21 Nov 2010 22:03:46 +0000
Subject: [issue940286] pydoc.Helper.help() ignores input/output init parameters
Message-ID: <1290377026.63.0.0499743684151.issue940286@psf.upfronthosting.co.za>


Kevin Le <solnovus at gmail.com> added the comment:

This patch redirects output from Helper.help to whatever output stream is passed to the Helper constructor. If no output stream is specified, the fault behavior is to pass the output to the OS pager.

----------
keywords: +patch
nosy: +bkad
versions: +Python 3.2
Added file: http://bugs.python.org/file19756/helpredirect.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue940286>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:20:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 22:20:21 +0000
Subject: [issue1560032] confusing error msg from random.randint
Message-ID: <1290378021.68.0.688272399207.issue1560032@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is related to the more general issue of how to report a wrong number of arguments in a method call; I don?t remember if it was a python-dev discussion, a python-ideas one or a bug report.

random is not the only module where instance methods are used as module functions; I don?t know what is more important between slightly better error messages and performance.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1560032>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:31:03 2010
From: report at bugs.python.org (Kevin Le)
Date: Sun, 21 Nov 2010 22:31:03 +0000
Subject: [issue940286] pydoc.Helper.help() ignores input/output init parameters
Message-ID: <1290378663.21.0.520143086425.issue940286@psf.upfronthosting.co.za>


Kevin Le <solnovus at gmail.com> added the comment:

Created a rietveld review
http://codereview.appspot.com/3202042

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue940286>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:32:34 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 21 Nov 2010 22:32:34 +0000
Subject: [issue9099] multiprocessing/win32: WindowsError: [Error 0] Success on
	Pipe()
In-Reply-To: <1277729700.77.0.590017326086.issue9099@psf.upfronthosting.co.za>
Message-ID: <1290378754.18.0.338029135475.issue9099@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Can you provide a test case for this?

----------
nosy: +asksol, brian.curtin
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9099>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:33:04 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 22:33:04 +0000
Subject: [issue1560032] confusing error msg from random.randint
Message-ID: <1290378784.84.0.125431707631.issue1560032@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Sorry, it's time to close this one.  The code is not buggy, it is documented as being a bound method and that is a perfectly acceptable python coding style to use bound methods as callables.  It's also been around for a *very* long without causing issues beyond Python's usual irritation with the number of arguments messages (that happened when Python became object oriented and that artifact still survives).

When it comes to the random module, people are performance sensitive and it would be a total waste to wrap these bound methods in another layer just to get different error message reporting.  Anyone whose Monte Carlo simulation run time doubles because of this would be rightfully irritated.

----------
assignee:  -> rhettinger
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1560032>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:44:54 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 22:44:54 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290379494.62.0.621146237723.issue10461@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

?ric, please apply most of these.

In the atexit patch, the first change is wrong.  Change it to a try/except/finally or skip it altogether.

In the collections patch, only include the change for the tail example; the other two should remain unchanged.

Skip the difflib patch entirely.  It unnecessarily makes the example confusing and hard to follow.

Change the cmd patch to:
+            with open(arg) as f:
+                self.cmdqueue.extend(f.read().splitlines())

----------
assignee: rhettinger -> eric.araujo
resolution:  -> accepted
stage: needs patch -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:46:34 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 22:46:34 +0000
Subject: [issue10356] decimal.py: hash of -1
In-Reply-To: <1289219643.76.0.519336821084.issue10356@psf.upfronthosting.co.za>
Message-ID: <1290379594.06.0.282726272105.issue10356@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> Committed the ValueError in r86517 (py3k)

As discussed on IRC, I've reverted this change.

----------
resolution: fixed -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10356>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:48:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 22:48:23 +0000
Subject: [issue940286] pydoc.Helper.help() ignores input/output init parameters
Message-ID: <1290379703.46.0.759905199401.issue940286@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch.  I commented there.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue940286>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:48:28 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 22:48:28 +0000
Subject: [issue9802] Document 'stability' of builtin min() and max()
In-Reply-To: <1283974231.16.0.73129931792.issue9802@psf.upfronthosting.co.za>
Message-ID: <1290379708.13.0.936857310164.issue9802@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

As discussed with Mark, am closing this one after having applied documentation changes.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9802>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:49:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 22:49:40 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290379780.51.0.122179151445.issue10461@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19696/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:52:51 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 22:52:51 +0000
Subject: [issue5353] Improve IndexError messages with actual values
In-Reply-To: <1235414311.83.0.833112713041.issue5353@psf.upfronthosting.co.za>
Message-ID: <1290379971.56.0.410402905687.issue5353@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm abandoning this one since I couldn't find a way to do it that didn't impair performance.  Unlike C++, it is not uncommon in Python to use exceptions such as IndexError for control flow.  There was too little added value in building-out this message to warrant the change (the current message is very clear about what the problem is, it just doesn't dump all the variables involved -- this is not uncommon for python error messages).

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5353>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:54:23 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 21 Nov 2010 22:54:23 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290380063.16.0.982334577522.issue7094@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree that:
   format(Decimal('1.23'), '#.6g')
should give '1.23000', just as:
   format(1.23, '#.6g')
does.

I'll work on fixing the patch, although if I don't get to it in the next few days I'll commit the existing patch and open another issue, just to make sure this gets in before the beta.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Sun Nov 21 23:57:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 21 Nov 2010 22:57:18 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1290374569.58.0.968912618321.issue7995@psf.upfronthosting.co.za>
Message-ID: <4CE9A3CC.3080301@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I got into this by starting with Issue7322, which reports a scenario
> where data is lost using makefile().  The docs for makefile() say,
> "The socket must be in blocking mode (it can not have a timeout)".
> So, we've got published documentation which equates non-blocking mode
> with a timeout set.

This wording goes back to r54491, from issue882297. Facundo writes

# If the socket is in blocking mode, it can NOT have a timeout.
# I fixed the docs, and made that explicit.

so I don't think he really meant to equate the two. I'm not a native
speaker (of English), so I'll refrain from proposing an alternative
wording.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:02:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 23:02:02 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1290380522.64.0.319818609359.issue9877@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I noticed in the output of pydoc that get_makefile_filename does not have a docstring.  I added one in my local copy (?Return the path of the Makefile.?) and also removed ?s? in verbs in other docstrings to comply with PEP 257.  Shall I commit it?

----------
Added file: http://bugs.python.org/file19757/docstrings.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:11:51 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 21 Nov 2010 23:11:51 +0000
Subject: [issue1544102] ctypes unit test fails (test_macholib.py) under MacOS
	10.4.7
Message-ID: <1290381111.7.0.993798423678.issue1544102@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Verified that the ctypes test_macholib tests in current Python 2.7, 2.6.6, and even 2.5.3 run without failure on OS X 10.4.11 PPC.

----------
nosy: +ned.deily -BreamoreBoy
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1544102>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:20:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 23:20:07 +0000
Subject: [issue9338] argparse optionals with nargs='+' can't be followed by
	positionals
In-Reply-To: <1279881989.28.0.725806934086.issue9338@psf.upfronthosting.co.za>
Message-ID: <1290381607.25.0.318491838374.issue9338@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good, thanks!  Does it integrate Catherine?s tests?

----------
components: +Library (Lib)
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9338>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:23:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 23:23:13 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290381793.76.0.732342854215.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch for test_quiet looks good, thanks.

Do you want to write test_noargs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:24:11 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 23:24:11 +0000
Subject: [issue6722] collections.namedtuple: confusing example
In-Reply-To: <1250591925.23.0.269848636465.issue6722@psf.upfronthosting.co.za>
Message-ID: <1290381851.91.0.195342107558.issue6722@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r86650

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6, Python 2.7, Python 3.0, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6722>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:26:24 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 23:26:24 +0000
Subject: [issue7212] Retrieve an arbitrary element from a set without removing
	it
In-Reply-To: <1256591239.7.0.409642892772.issue7212@psf.upfronthosting.co.za>
Message-ID: <1290381984.48.0.553157503766.issue7212@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7212>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:29:23 2010
From: report at bugs.python.org (akira)
Date: Sun, 21 Nov 2010 23:29:23 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290382163.38.0.23234569746.issue9509@psf.upfronthosting.co.za>


akira <4kir4.1i at gmail.com> added the comment:

Simplified the patch and added test for a non-existent file in issue9509.patch

The test `py3k/python -m test.regrtest test_argparse` fails without the patch and succeeds with it.

The docs in Doc/library/argparse.rst and Lib/argparse.py  don't need to be changed (neither mention IOError and it is a buf fix).

Misc/NEWS and Misc/ACKS don't need to be changed (?).

I've uploaded the patch to Rietveld http://codereview.appspot.com/3251041/

----------
nosy: +akira
type:  -> behavior
Added file: http://bugs.python.org/file19758/issue9509.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:29:29 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 23:29:29 +0000
Subject: [issue7257] Improve documentation of list.sort and sorted()
In-Reply-To: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>
Message-ID: <1290382169.8.0.950090967835.issue7257@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

After more thought, am leaving the doc strings as-is.  They are succinct and accurate.  I have updated the sorting how-to to more thoroughly cover the basics of sorting.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7257>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:35:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 23:35:00 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1290382500.21.0.134793519955.issue809163@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

assertEquals is deprecated, I?ll change to assertEqual.

> What filelist.py patch are you referring to? I've tested this on py3k
> with no changes to filelist.py.
The goal of a test is to show an error so that it can be fixed.  In this case, the test is still useful to make sure things work, especially in distutils2 where we are changing the filelist (now manifest) module a lot.

I think now that my comment ?forget RPM? was wrong.  This is not a problem with RPM, but with bdist_rpm, so even if filelist behaves correctly with spaces, bdist_rpm does not.  If there is a way to make rpm read one line at a time, we should use it.

Toshio: Do you have an idea how to do that?  Otherwise we?ll close as wontfix and forward to the bdist_rpm2 project, where they have more freedom to change code.

----------
nosy: +a.badger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:50:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 23:50:48 +0000
Subject: [issue3292] Position index limit; s.insert(i,x) not same as s[i:i]=[x]
In-Reply-To: <1215293854.95.0.622305572735.issue3292@psf.upfronthosting.co.za>
Message-ID: <1290383448.45.0.119249575182.issue3292@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Added the i,j,k notes

Left out the processor word size and C-type specifications in-part because it is an implementation detail subject to change.  Another reason is that it doesn't apply to necessarily to all sequences.  Slices take arbitrary objects and with applied to an object's __getitem__, the object itself is responsible for handling it.  Also, the size limits are already reflected in the maximum sizes for the object (a list can't get bigger that Py_ssize_t, so of course, its indicies are similarly bounded).  Adding more text here is leaning towards over-specification of implementation specific details and make the docs harder to read while not adding anything truly helpful.

In particular, it is more harmful than helpful to focus on the edge case where "s.insert(i, x) is not the same as s[i:i] = [x]" when i==sys.maxsize-1.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3292>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:51:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 23:51:53 +0000
Subject: [issue3292] Position index limit; s.insert(i,x) not same as s[i:i]=[x]
In-Reply-To: <1215293854.95.0.622305572735.issue3292@psf.upfronthosting.co.za>
Message-ID: <1290383513.21.0.810529411017.issue3292@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r3292.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3292>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:55:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 21 Nov 2010 23:55:20 +0000
Subject: [issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate
	Python interpreter (so 3.1's idle.bat does not accidently use
	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <1290383720.23.0.925770239889.issue6378@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I don't think this is a feature request. This batch file should always run the version of the file for which the batch is installed. For it to be generic and end up using another installed version is incorrect. With that said...

Fixed in r86651, r86652, and r86653. Thanks for the patch.

----------
assignee:  -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: feature request -> behavior
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6378>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:55:33 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 21 Nov 2010 23:55:33 +0000
Subject: [issue7049] decimal.py: Three argument power issues
In-Reply-To: <1254578364.09.0.56728742883.issue7049@psf.upfronthosting.co.za>
Message-ID: <1290383733.36.0.618232162951.issue7049@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 for deprecating three-arg pow for the reasons given.
A user is much better-off composing well-defined operations
than using our short-cut, with our chosen assumptions.
Apologies for taking so long to think this one through.

----------
assignee: rhettinger -> mark.dickinson
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7049>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:57:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 21 Nov 2010 23:57:20 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290383840.49.0.731777028133.issue9509@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t know enough of the test_argparse magic to assess the new test, but Stephan, the author and maintainer of argparse, will certainly comment when he gets some time.  Thanks for the patch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:57:26 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Sun, 21 Nov 2010 23:57:26 +0000
Subject: [issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate
	Python interpreter (so 3.1's idle.bat does not accidently use
	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <1290383846.34.0.542311937699.issue6378@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

Brian,

The following line:

  start %CURRDIR%..\..\pythonw.exe %CURRDIR%idle.pyw %1 %2 %3 %4 %5 %6 %7 %8 %9

should be changed to:

  start "%CURRDIR%..\..\pythonw.exe" "%CURRDIR%idle.pyw" %1 %2 %3 %4 %5 %6 %7 %8 %9

This is required if Python is installed into a directory with whitespace in its path.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6378>
_______________________________________

From report at bugs.python.org  Mon Nov 22 00:59:11 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 21 Nov 2010 23:59:11 +0000
Subject: [issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate
	Python interpreter (so 3.1's idle.bat does not accidently use
	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <1290383951.47.0.863045330891.issue6378@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

True. I'll correct it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6378>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:04:19 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Nov 2010 00:04:19 +0000
Subject: [issue6378] Patch to make 'idle.bat' run idle.pyw using appropriate
	Python interpreter (so 3.1's idle.bat does not accidently use
	python26.exe)
In-Reply-To: <1246308322.32.0.750084238969.issue6378@psf.upfronthosting.co.za>
Message-ID: <1290384259.68.0.796945129522.issue6378@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Corrected in r86655, r86656, and r86657.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6378>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:07:14 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Nov 2010 00:07:14 +0000
Subject: [issue10164] Add an assertBytesEqual to unittest and use it for bytes
	assertEqual
In-Reply-To: <1287665297.21.0.48545376383.issue10164@psf.upfronthosting.co.za>
Message-ID: <1290384434.98.0.000457945481834.issue10164@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Rejecting this one for reasons we discussed earlier.  The assertEqual() method needs to be the primary interface.  Everything else is starting to mix content and presentation (i.e. passing in separators).  The existing repr() works fine with bytes and Michael's suggested ascii() cast would be the preferred technique in the common cases.

What might be useful is a less specialized patch letting assertEqual() take an argument pointing to some repr or pre-processing function that would be called after an equality test fails but before it is diffed.  That would support a clear separation of concerns and be easily extendable by users would need something more than an ascii() cast.

----------
resolution: later -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10164>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:07:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 00:07:18 +0000
Subject: [issue9399] Provide a 'print' action for argparse
In-Reply-To: <1280329840.94.0.288179215378.issue9399@psf.upfronthosting.co.za>
Message-ID: <1290384438.15.0.23263167525.issue9399@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

sys.std* should not be used as default values in a function definition, because they may be rebound to other objects.  The usual idiom is to have None as default value and check it at call time.

The patch also needs tests and docs.

(FTR, the example for callable in this report was wrong: First, the message argument was missing in the lambda, second, there was no need for a lambda in the first place :)

----------
nosy: +eric.araujo
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9399>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:09:58 2010
From: report at bugs.python.org (Ramiro Batista da Luz)
Date: Mon, 22 Nov 2010 00:09:58 +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: <1290384598.34.0.211944890611.issue10494@psf.upfronthosting.co.za>


New submission from Ramiro Batista da Luz <ramiroluz at gmail.com>:

When someone run Demo/comparisons/regextest.py without arguments it waits for lines to be inserted in the command line silently, until the EOF, or Ctrl-D in Linux, is entered.

If the user read the file, editing or using cat Demo/comparisons/regextest.py he have to understand the code to figure out how to use it.

My suggestion is to add an usage message.

----------
components: Demos and Tools
messages: 122032
nosy: ramiroluz
priority: normal
severity: normal
status: open
title: Demo/comparisons/regextest.py needs some usage information.
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10494>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:10:23 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Nov 2010 00:10:23 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1290384623.01.0.932130476618.issue10360@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I don't have any other insights on this one.  Assigned by to Antoine who appears to have put some thought into it.

----------
assignee: rhettinger -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:12:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 00:12:02 +0000
Subject: [issue10366] Remove unneeded '(object)' from 3.x class examples
In-Reply-To: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>
Message-ID: <1290384722.77.0.164775024233.issue10366@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I will commit the patch this week unless someone opposes to it.

We still need a doc change as described in Terry?s original message.

----------
assignee: docs at python -> eric.araujo
resolution:  -> accepted
stage: needs patch -> patch review
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10366>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:12:22 2010
From: report at bugs.python.org (Ramiro Batista da Luz)
Date: Mon, 22 Nov 2010 00:12:22 +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: <1290384742.16.0.943532655696.issue10494@psf.upfronthosting.co.za>


Ramiro Batista da Luz <ramiroluz at gmail.com> added the comment:

Suggested patch.

----------
keywords: +patch
Added file: http://bugs.python.org/file19759/issue10494_demo_regextest_usage_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10494>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:13:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Nov 2010 00:13:43 +0000
Subject: [issue10360] _weakrefset.WeakSet.__contains__ should not propagate
	TypeErrors
In-Reply-To: <1289225563.5.0.586847358991.issue10360@psf.upfronthosting.co.za>
Message-ID: <1290384823.58.0.104105912749.issue10360@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well if WeakKeyDictionary silences the TypeError from ref(), it sounds consistent for WeakSet to silence it too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10360>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:14:05 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Nov 2010 00:14:05 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1290384845.41.0.622877552297.issue7434@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Deferring the general rewrite until 3.3.
It would need to have a lot of people look
at it and evaluate it.  I no longer think
there is time for that before the 3.2 beta.

----------
resolution:  -> later
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7434>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:14:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 00:14:57 +0000
Subject: [issue7325] tempfile.mkdtemp() does not return absolute pathname when
	relative dir is specified
In-Reply-To: <1258226856.45.0.72736645389.issue7325@psf.upfronthosting.co.za>
Message-ID: <1290384897.12.0.333888704236.issue7325@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

os.path.abspath actually checks for isabs first, so I think you can leave the test out and always call abspath.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7325>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:15:15 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 22 Nov 2010 00:15:15 +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: <1290384915.08.0.0768166392917.issue7995@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The notes in the documentation under socket.gettimeout() do go into more detail than elsewhere.  But at least one thing there is at best misleading: "Sockets are always created in blocking mode" is, as we've seen, not correct for BSD-ish systems for sockets returned by accept().  So, at a minimum, this section and the documentation for socket.accept() should be expanded, along with any other changes.

http://docs.python.org/py3k/library/socket.html#socket.socket.gettimeout
http://docs.python.org/py3k/library/socket.html#socket.socket.accept

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:23:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 22 Nov 2010 00:23:57 +0000
Subject: [issue1178] IDLE - add "paste code" functionality
In-Reply-To: <1190153010.77.0.038299898053.issue1178@psf.upfronthosting.co.za>
Message-ID: <1290385437.57.0.163492016721.issue1178@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Reopening as the previous message appears to be incorrect.)

----------
assignee: nobody -> 
nosy: +ned.deily -BreamoreBoy
resolution: fixed -> 
stage:  -> patch review
status: closed -> open
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1178>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:24:31 2010
From: report at bugs.python.org (Roy Smith)
Date: Mon, 22 Nov 2010 00:24:31 +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: <1290385471.99.0.532583918386.issue7995@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

Responding to msg122013:

I think he exactly meant to equate the two.

The original problem described in issue882297 is that the makefile() documentation only stated that the socket could not be in non-blocking mode.  The test case presented didn't appear to set non-blocking mode, it only set a timeout.

The explanation by facundobatista was that setting a timeout inplies putting the socket into non-blocking mode, and the docs were updated to make this "non-blocking <==> timeout" relationship clear.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:25:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Nov 2010 00:25:06 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1290384915.08.0.0768166392917.issue7995@psf.upfronthosting.co.za>
Message-ID: <1290385502.3620.46.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The notes in the documentation under socket.gettimeout() do go into
> more detail than elsewhere.  But at least one thing there is at best
> misleading: "Sockets are always created in blocking mode" is, as we've
> seen, not correct for BSD-ish systems for sockets returned by
> accept().  So, at a minimum, this section and the documentation for
> socket.accept() should be expanded, along with any other changes.

Well, unless someone explains convincingly how the current behaviour is
desireable (rather than misleading and useless), I really think this is
a bug that should be fix (then we can also discuss what the fix should
exactly be).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:26:15 2010
From: report at bugs.python.org (Xuanji Li)
Date: Mon, 22 Nov 2010 00:26:15 +0000
Subject: [issue10366] Remove unneeded '(object)' from 3.x class examples
In-Reply-To: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>
Message-ID: <1290385575.38.0.970348104299.issue10366@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Hi eric, what doc change are you referring to?

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10366>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:26:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 00:26:23 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1290385583.12.0.916280192141.issue8525@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you.  I uploaded your patch to Rietveld and reviewed it: http://codereview.appspot.com/3169042/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:27:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 00:27:06 +0000
Subject: [issue10366] Remove unneeded '(object)' from 3.x class examples
In-Reply-To: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>
Message-ID: <1290385626.52.0.715635844739.issue10366@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?I also think the doc for 'class' should say that the default inheritance is from the base class *object*?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10366>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:33:11 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Nov 2010 00:33:11 +0000
Subject: [issue10366] Remove unneeded '(object)' from 3.x class examples
In-Reply-To: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>
Message-ID: <1290385991.04.0.641698014643.issue10366@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

These mostly look good.  Do leave the howto documents as-is.  They have some value across multiple versions of Python.  Also, the descriptor how-to in particular gets some benefit from keeping (object) explicit because it helps remind users which version of __getattribute__ is being run.

Other than the how-tos, please go ahead and apply.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10366>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:35:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 00:35:15 +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: <1290386115.93.0.520186143469.issue10494@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

+0

Not "+1" because Georg suggested that this demo be removed.  See

http://mail.python.org/pipermail/python-ideas/2010-October/008416.html

On the patch, I would define a "usage" variable near the top of the program instead of repeating the usage text in the comment.

----------
nosy: +belopolsky, georg.brandl
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10494>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:38:32 2010
From: report at bugs.python.org (Ramiro Batista da Luz)
Date: Mon, 22 Nov 2010 00:38:32 +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: <1290386312.84.0.302753892173.issue10495@psf.upfronthosting.co.za>


New submission from Ramiro Batista da Luz <ramiroluz at gmail.com>:

When someone run Demo/comparisons/regextest.py without arguments it waits for lines to be inserted in the command line silently, until the EOF, or Ctrl+D in Linux, is entered.

If the user read the file, editing or using cat Demo/comparisons/sortingtest.py he have to understand the code to figure out how to use it.

My suggestion is to add an usage message, plus the if __name__ == '__main__':.

----------
components: Demos and Tools
messages: 122048
nosy: ramiroluz
priority: normal
severity: normal
status: open
title: Demo/comparisons/sortingtest.py needs some usage information.
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10495>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:42:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 00:42:03 +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: <1290386523.0.0.383433655948.issue10494@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Beware of UUOC: http://en.wikipedia.org/wiki/Cat_%28Unix%29#Useless_use_of_cat

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10494>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:43:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 22 Nov 2010 00:43:57 +0000
Subject: [issue706406] fix bug #685846: raw_input defers signals
Message-ID: <1290386637.6.0.626296921582.issue706406@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Noted in passing: Issue9867 may be relevant here.)

----------
nosy: +ned.deily -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue706406>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:47:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 00:47:12 +0000
Subject: [issue9831] test_distutils should honor PYTHONDONTWRITEBYTECODE
In-Reply-To: <1284198380.71.0.192975016699.issue9831@psf.upfronthosting.co.za>
Message-ID: <1290386832.13.0.984459924967.issue9831@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: accepted -> 
title: test_distutils fails on MacOSX 10.6 -> test_distutils should honor PYTHONDONTWRITEBYTECODE

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9831>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:59:52 2010
From: report at bugs.python.org (Brian Bi)
Date: Mon, 22 Nov 2010 00:59:52 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory
In-Reply-To: <1290387591.59.0.788816465526.issue10496@psf.upfronthosting.co.za>
Message-ID: <1290387591.59.0.788816465526.issue10496@psf.upfronthosting.co.za>


New submission from Brian Bi <bbi5291 at gmail.com>:

This bug is Linux-specific.

When Python cannot find the home directory of the user invoking it, it prints "'import site' failed; use -v for traceback".

This occurs only when both of these conditions are met:
1. /etc/passwd contains no entry for the current real UID
2. the HOME environment variable does not exist

To duplicate this bug, compile and run the attached program as root.
(Note that this will fail if 12345 is a legitimate user on your system, or if Python is not at /usr/bin/python.)

----------
components: None
files: bug.c
messages: 122051
nosy: bbi5291
priority: normal
severity: normal
status: open
title: "import site failed" when Python can't find home directory
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19760/bug.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Mon Nov 22 01:59:58 2010
From: report at bugs.python.org (Ramiro Batista da Luz)
Date: Mon, 22 Nov 2010 00:59:58 +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: <1290387598.0.0.270587214078.issue10494@psf.upfronthosting.co.za>


Ramiro Batista da Luz <ramiroluz at gmail.com> added the comment:

New patch from the suggestions, probably it will be discarded (see http://mail.python.org/pipermail/python-ideas/2010-October/008416.html)

But the work was already done. :P

----------
Added file: http://bugs.python.org/file19761/issue10494_demo_regextest_usage_patch_v2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10494>
_______________________________________

From report at bugs.python.org  Mon Nov 22 02:02:11 2010
From: report at bugs.python.org (Ramiro Batista da Luz)
Date: Mon, 22 Nov 2010 01:02:11 +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: <1290387731.04.0.0362791721335.issue10495@psf.upfronthosting.co.za>


Ramiro Batista da Luz <ramiroluz at gmail.com> added the comment:

I had write a suggested patch before seeing this message http://bugs.python.org/issue10494#msg122047 from Alexander Belopolsky (belopolsky). 

Probably it will be discarded, but as I commented in the previous #issue10494, the work was already done. (see http://mail.python.org/pipermail/python-ideas/2010-October/008416.html)

----------
keywords: +patch
Added file: http://bugs.python.org/file19762/issue10495_demo_sortingtest_usage_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10495>
_______________________________________

From report at bugs.python.org  Mon Nov 22 02:17:23 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 22 Nov 2010 01:17:23 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1290380522.64.0.319818609359.issue9877@psf.upfronthosting.co.za>
Message-ID: <20101121201709.1e17dd63@mission>


Barry A. Warsaw <barry at python.org> added the comment:

On Nov 21, 2010, at 11:02 PM, ?ric Araujo wrote:

>I noticed in the output of pydoc that get_makefile_filename does not have a
>docstring.  I added one in my local copy (?Return the path of the Makefile.?)
>and also removed ?s? in verbs in other docstrings to comply with PEP 257.
>Shall I commit it?

Please do.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Mon Nov 22 02:22:14 2010
From: report at bugs.python.org (Justin Cappos)
Date: Mon, 22 Nov 2010 01:22:14 +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: <1290388934.12.0.651177427391.issue7995@psf.upfronthosting.co.za>


Justin Cappos <justincappos at gmail.com> added the comment:

>> The Python implementation sets timeout=None (which implies that the
>> underlying socket is blocking).
>
>No, it doesn't. A socket may be non-blocking without having a timeout;
> that's the socket API (on all systems, not just BSD).

Sure and this happens when the timeout is 0, but None has a different meaning than 0.

>> The problem is that it has.   It has created a new Python socket
>> object with a specific value for timeout (None), but the underlying
>> socket is nonblocking.
>> 
>> The docs state that timeout = None makes the socket blocking.
>
> What specific wording are you looking at that makes you believe so?

Here is the last part of the description of settimeout:

s.settimeout(None) is equivalent to s.setblocking(1)

if you look at setblocking:

Set blocking or non-blocking mode of the socket: if flag is 0, the socket is set to non-blocking, else to blocking mode. 

This seems to imply that timeout = None -> blocking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Mon Nov 22 02:25:52 2010
From: report at bugs.python.org (Ari Consul)
Date: Mon, 22 Nov 2010 01:25:52 +0000
Subject: [issue9631] Python 2.7 installation issue for Linux gcc-4.1.0-3
	(Fedora Core 5?)
In-Reply-To: <1282108953.92.0.943632360126.issue9631@psf.upfronthosting.co.za>
Message-ID: <1290389152.95.0.230399306363.issue9631@psf.upfronthosting.co.za>


Ari Consul <ariconsul at gmail.com> added the comment:

Similar error on make install.  Using Centos 5

/usr/bin/install -c -m 644 ./LICENSE /home/ac927k/local/Python-2.7/lib/python2.7/LICENSE.txt
PYTHONPATH=/home/ac927k/local/Python-2.7/lib/python2.7   \
                ./python -Wi -tt /home/ac927k/local/Python-2.7/lib/python2.7/compileall.py \
                -d /home/ac927k/local/Python-2.7/lib/python2.7 -f \
                -x 'bad_coding|badsyntax|site-packages|lib2to3/tests/data' \
                /home/ac927k/local/Python-2.7/lib/python2.7
Traceback (most recent call last):
  File "/home/ac927k/local/Python-2.7/lib/python2.7/compileall.py", line 17, in <module>
    import struct
  File "/home/ac927k/local/Python-2.7/lib/python2.7/struct.py", line 1, in <module>
    from _struct import *
ImportError: No module named _struct
make: *** [libinstall] Error 1


[1]+  Exit 2                  make install >&~/python2.7_make_install.log
[ac927k at limbo Python-2.7]$ clear
[ac927k at limbo Python-2.7]$ df -T
Filesystem    Type   1K-blocks      Used Available Use% Mounted on
/dev/mapper/VolGroup00-LogVol00
              ext3    73608360  11832396  57976516  17% /
/dev/sda1     ext3      101086     26199     69668  28% /boot
tmpfs        tmpfs     1029736         0   1029736   0% /dev/shm
[ac927k at limbo Python-2.7]$ uname -av
Linux limbo.local 2.6.18-194.8.1.el5 #1 SMP Thu Jul 1 19:04:48 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
[ac927k at limbo Python-2.7]$ cat /etc/redhat-release
CentOS release 5.5 (Final)
[ac927k at limbo Python-2.7]$

----------
nosy: +Ari.Consul

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9631>
_______________________________________

From report at bugs.python.org  Mon Nov 22 02:33:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 01:33:42 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1290389622.81.0.165922690352.issue8525@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The following passes tests in elp_8525.patch, but is much simpler:

===================================================================
--- Lib/pydoc.py	(revision 86600)
+++ Lib/pydoc.py	(working copy)
@@ -1139,6 +1139,15 @@
                 push('    ' + makename(base))
             push('')
 
+        # List the built-in subclasses, if any:
+        subclasses = [cls.__name__ for cls in object.__subclasses__()
+                      if cls.__module__ == 'builtins']
+        if subclasses:
+            push("Built-in subclasses:")
+            for subclassname in sorted(subclasses):
+                push('    ' + subclassname)
+            push('')
+
         # Cute little class to pump out a horizontal rule between sections.
         class HorizontalRule:
             def __init__(self):

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Mon Nov 22 02:43:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 01:43:12 +0000
Subject: [issue9877] Expose sysconfig._get_makefile_filename() in public API
In-Reply-To: <1284659465.24.0.827166007618.issue9877@psf.upfronthosting.co.za>
Message-ID: <1290390192.29.0.446082298985.issue9877@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, done as r86662 and [fbcddbb92b14].

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Mon Nov 22 02:44:36 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 22 Nov 2010 01:44:36 +0000
Subject: [issue10268] Add --enable-loadable-sqlite-extensions option to
	`configure`
In-Reply-To: <1288544831.28.0.692302384707.issue10268@psf.upfronthosting.co.za>
Message-ID: <1290390276.87.0.00802232088589.issue10268@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Note, this change affects the documentation for the sqlite3 module which was modified for 3.2 by r85208 in Issue10020 to add a footnote:

"The sqlite3 module is not built with loadable extension support by default, because some platforms (notably Mac OS X) have SQLite libraries which are compiled without this feature. To get loadable extension support, you must modify setup.py and and remove the line that sets SQLITE_OMIT_LOAD_EXTENSION."

Also, the configure to Makefile option processing is non-standard. Unexpectedly, --enable-loadable-sqlite-extensions=no is treated the same as --enable-loadable-sqlite-extensions or --enable-loadable-sqlite-extensions=yes, contrary to standard Autoconf behavior.

----------
assignee:  -> benjamin.peterson
nosy: +ned.deily
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10268>
_______________________________________

From report at bugs.python.org  Mon Nov 22 02:53:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 01:53:10 +0000
Subject: [issue10138] calendar module does not support years outside [1,
	9999] range
In-Reply-To: <1287422620.12.0.790695371078.issue10138@psf.upfronthosting.co.za>
Message-ID: <1290390790.6.0.525998482471.issue10138@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10138>
_______________________________________

From report at bugs.python.org  Mon Nov 22 02:54:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 01:54:52 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1290390892.44.0.0415679734494.issue10087@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:02:44 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 22 Nov 2010 02:02:44 +0000
Subject: [issue9047] Python 2.7rc2 includes -isysroot twice on each gcc
	command line
In-Reply-To: <1277145493.52.0.0439952052215.issue9047@psf.upfronthosting.co.za>
Message-ID: <1290391364.2.0.916730616681.issue9047@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Can this be closed now?

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9047>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:03:40 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 22 Nov 2010 02:03:40 +0000
Subject: [issue10483] http.server - what is executable on Windows
In-Reply-To: <1290324390.55.0.445837984524.issue10483@psf.upfronthosting.co.za>
Message-ID: <1290391420.52.0.792385538066.issue10483@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Martin, that is an interesting viewpoint, and one I considered, but didn't state, because it seems much too restrictive.  Most CGI programs are written in scripting languages, not compiled to .exe.  So it seems the solution should allow for launching at least Perl and Python scripts, as well as .exe.  Whether subprocess.Popen can directly execute it, or whether it needs help from the registry or a #! line to get the execution going is just a matter of tweaking the coding for what gets passed to subprocess.Popen.  Declaring the definition based on what the existing code can already do is self-limiting.

Another possible interpretation of executable might be PATHEXT environment variable, but that is similar to declaring a list in the server source, which I did mention.  One might augment the other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10483>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:11:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Nov 2010 02:11:41 +0000
Subject: [issue7645] test_distutils fails on Windows XP
In-Reply-To: <1262807781.76.0.367553383725.issue7645@psf.upfronthosting.co.za>
Message-ID: <1290391901.15.0.757270178224.issue7645@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The addition of the Setup.sample to Tools/msi/msi.py was only done in 3.2. I backported it to 3.1 in r86666 and 2.7 in r86667.

----------
assignee: tarek -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7645>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:11:48 2010
From: report at bugs.python.org (Savio Sena)
Date: Mon, 22 Nov 2010 02:11:48 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1290391908.92.0.80547022938.issue1745035@psf.upfronthosting.co.za>


Savio Sena <savio.sena at acm.org> added the comment:

The attached patch adopts the minimalistic approach described in previous post. It pretends to implement Message Size Extension, defining a maximum message data size to 32M bytes and maximum command length to 512 bytes.

In my opinion this is the best way to accomplish a patch to the DoS issue alone. It's still a good idea though to implement full ESMTP support -- I know, I'm repeating myself. 

Please note this is my first patch. I'm new to Python and even though I made my best to be in conformance with the "standards" and good practices I may have missed something. Please review this patch with clinical eyes. 

For the records: this work is due to Python Bug Day. It worked to attract another curious developer. :-) This project is really awesome. Congratz you all. 

My best regards.

----------
Added file: http://bugs.python.org/file19763/issue1745035-saviosena-101121.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:13:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Nov 2010 02:13:24 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
	(getdefaultlocale returns value not usable in setlocale)
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1290392004.05.0.0557627066787.issue10466@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is unfunny that your program fails on Windows.

Yes it is the same bug, since calendar calls getdefaultlocale.

Issue 1080864 makes very interesting reading in this context.  Clearly Martin is right, yet the OP seems to find the current behavior of getdefaultencoding (returning the more standard locale name rather than Windows unique values) useful.

It is an interesting question what can be done about this.  Clearly resetlocale is non-functional on Windows, and getdefaultlocale is of questionable utility.  At the very least these limitations need to be documented.

Your application bug, however, can probably be addressed by fixing calendar to not use getdefaultencoding.  We should open a new bug for that, though.

----------
nosy: +loewis
title: locale.py resetlocale throws exception on Windows -> locale.py resetlocale throws exception on Windows (getdefaultlocale returns value not usable in setlocale)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:14:18 2010
From: report at bugs.python.org (Andrew Schaaf)
Date: Mon, 22 Nov 2010 02:14:18 +0000
Subject: [issue3709] BaseHTTPRequestHandler innefficient when sending HTTP
	header
In-Reply-To: <1219880627.35.0.0859788959986.issue3709@psf.upfronthosting.co.za>
Message-ID: <1290392058.17.0.863726029141.issue3709@psf.upfronthosting.co.za>


Andrew Schaaf <andrew at andrewschaaf.com> added the comment:

This patch (to 86665)...
* adds buffering to send_response_only
* adds flush_headers and uses it in end_headers and CGIHTTPRequestHandler.run_cgi
* tests {send_error,send_response_only,send_header} using a write-counting wfile
* improves the docs

Also, I've added my name to this account.

----------
Added file: http://bugs.python.org/file19764/issue3709-from86665.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3709>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:21:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 02:21:42 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290392502.51.0.898255418006.issue10461@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Raymond: I made a single diff for easier review.  I?m not 100% sure I should change 'r' to 'rb' in logging: It?s unrelated to with, and the rest of the file has not been checked for similar errors.  I prefer to do commits that don?t mix things.

Eli:
> which whitespace change do you refer to. I changed to 4-spaces
> indentation in the code sample to conform to PEP-8. Shouldn't I have?
PEP 8 only applies to Python code.  http://docs.python.org/dev/documenting/style applies to the docs.

----------
Added file: http://bugs.python.org/file19765/with-in-docs-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:26:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 02:26:52 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1290392812.4.0.817719963927.issue5088@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> eric.araujo
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5088>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:31:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 02:31:26 +0000
Subject: [issue10497] Incorrect use of gettext in argparse
In-Reply-To: <1290393086.01.0.235126341394.issue10497@psf.upfronthosting.co.za>
Message-ID: <1290393086.01.0.235126341394.issue10497@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I found two calls to gettext that are incorrect.  See attached patch.

----------
components: Library (Lib)
files: gettext-argparse.diff
keywords: patch
messages: 122068
nosy: bethard, eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Incorrect use of gettext in argparse
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file19766/gettext-argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10497>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:33:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 02:33:33 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <1290393213.48.0.43424916955.issue10200@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19375/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:33:46 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 22 Nov 2010 02:33:46 +0000
Subject: [issue10493] test_strptime failures under OpenIndiana
In-Reply-To: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>
Message-ID: <1290393226.17.0.125590245594.issue10493@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

OS stock python:

"""
jc at pythonbuildbot.uk.openindiana.org:~$ python
Python 2.6.4 (r264:75706, Sep 12 2010, 18:46:30) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime("%d")
'22'
"""

Buildbots for 2.7 and 3.2 are working nicely. There is something fishy there.

Building 3.1 head, I get:

"""
jc at pythonbuildbot.uk.openindiana.org:/tmp/z/build# export LD_LIBRARY_PATH=/tmp/z/build
jc at pythonbuildbot.uk.openindiana.org:/tmp/z/build# ./python
Python 3.1.3rc1+ (release31-maint:86646, Nov 21 2010, 20:07:38) 
[GCC 4.3.3] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.strftime("%d")
'%'
"""

That is clearly incorrect. Don't seems to be a problem with OpenIndiana, since 2.7 and 3.2 heads are OK.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10493>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:35:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Nov 2010 02:35:06 +0000
Subject: [issue10498] calendar.LocaleHTMLCalendar.formatyearpage() results in
	traceback with 'unsupported locale setting' on Windows
In-Reply-To: <1290393306.69.0.998081430395.issue10498@psf.upfronthosting.co.za>
Message-ID: <1290393306.69.0.998081430395.issue10498@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

See issue 10466 for background, but in short LocaleHTMLCalendar uses getdefaultlocale if no locale is specified, and on windows this results in a locale that setlocale will not accept.  The fix is presumably to use setlocale(LC_DATE, '') instead of getdefaultelocale.

----------
keywords: easy
messages: 122070
nosy: r.david.murray
priority: normal
severity: normal
stage: unit test needed
status: open
title: calendar.LocaleHTMLCalendar.formatyearpage() results in traceback with 'unsupported locale setting' on Windows
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10498>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:37:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Nov 2010 02:37:09 +0000
Subject: [issue10498] calendar.LocaleHTMLCalendar.formatyearpage() results in
	traceback with 'unsupported locale setting' on Windows
In-Reply-To: <1290393306.69.0.998081430395.issue10498@psf.upfronthosting.co.za>
Message-ID: <1290393429.23.0.737640207776.issue10498@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +skoczian

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10498>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:37:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Nov 2010 02:37:43 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
	(getdefaultlocale returns value not usable in setlocale)
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1290393463.1.0.846902423727.issue10466@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've opened issue 10498 for the calendar bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:38:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 02:38:59 +0000
Subject: [issue10498] calendar.LocaleHTMLCalendar.formatyearpage() results in
	traceback with 'unsupported locale setting' on Windows
In-Reply-To: <1290393306.69.0.998081430395.issue10498@psf.upfronthosting.co.za>
Message-ID: <1290393539.97.0.375995254632.issue10498@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

See also #10087.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10498>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:43:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 02:43:49 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290393829.39.0.52592122875.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

test_quiet hopefully fixed in r86668.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:45:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Nov 2010 02:45:05 +0000
Subject: [issue10164] Add an assertBytesEqual to unittest and use it for bytes
	assertEqual
In-Reply-To: <1287665297.21.0.48545376383.issue10164@psf.upfronthosting.co.za>
Message-ID: <1290393905.63.0.193827376099.issue10164@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Agreed on the closing.  The pre-diff processing function would be a great addition.  For the record, I am currently satisfying my use case by doing this:

   self.assertEqual(bstr1.split(b'\n'), bstr2.split(b'\n'))

which produces a very readable diff.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10164>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:49:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Nov 2010 02:49:09 +0000
Subject: [issue10138] calendar module does not support years outside [1,
	9999] range
In-Reply-To: <1287422620.12.0.790695371078.issue10138@psf.upfronthosting.co.za>
Message-ID: <1290394149.67.0.2848774435.issue10138@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Go ahead an remove the word "indefinitely".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10138>
_______________________________________

From report at bugs.python.org  Mon Nov 22 03:53:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 02:53:42 +0000
Subject: [issue10497] Incorrect use of gettext in argparse
In-Reply-To: <1290393086.01.0.235126341394.issue10497@psf.upfronthosting.co.za>
Message-ID: <1290394422.36.0.484741145138.issue10497@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The patch makes sense.  I wonder if i10n of programs using argparse should be mentioned in docs.  Providing a sample translation file somewhere may not be a bad idea at least for testing.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10497>
_______________________________________

From report at bugs.python.org  Mon Nov 22 04:07:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 03:07:54 +0000
Subject: [issue10138] calendar module does not support years outside [1,
	9999] range
In-Reply-To: <1287422620.12.0.790695371078.issue10138@psf.upfronthosting.co.za>
Message-ID: <1290395274.03.0.946394310659.issue10138@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Fixed in revision 86669.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10138>
_______________________________________

From report at bugs.python.org  Mon Nov 22 04:16:33 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 22 Nov 2010 03:16:33 +0000
Subject: [issue10499] Modular interpolation in configparser
In-Reply-To: <1290395793.65.0.355106669717.issue10499@psf.upfronthosting.co.za>
Message-ID: <1290395793.65.0.355106669717.issue10499@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

SUMMARY
=======

This is a refactoring of configparser raised from discussions on #6517 and #9876. It solves both issues and makes the code quite elegant. Best part is, it's fully backwards compatible [1].

In the patch I basically did:
a) move the interpolation functionality out of the parsers
b) deprecate RCP and CP in favor of SCP
c) refactor the resulting code to get rid of duplicates

This means that actually despite the generalization and introduction of deprecation warnings, configparser lost 22 lines in the process. The implementation is complete and unit tested.


WHAT'S LEFT TO DO
=================

1. Obviously the new `interpolation` __init__ argument needs docs. This includes the docstrings on *Interpolation classes that describe how the algorithms work.

2. `ExtendedInterpolation` class implementing the buildout syntax, that would satisfy the request from #9876.

3. Once we have more interpolation implementations new test cases will be added to test_cfgparser.py.

Will do all three when I have any opinions on the current direction.


REVIEW HINTS
============

I need some thumbs up or advice on the design decisions made.

1. `interpolation` now takes a class, __init__ instantiates an object on its own. Do tell if taking an object upfront would be a better approach.

2. *Interpolation classes have methods which take the parser as an argument. Do tell if making it an object attribute would be a better approach.

All other points of interest during a review naturally apply here too.



[1] Assuming _names are private and can be moved around when needed.

----------
assignee: lukasz.langa
components: Library (Lib)
files: configparser_interpolation.diff
keywords: needs review, patch
messages: 122078
nosy: eric.araujo, fdrake, georg.brandl, lukasz.langa, rhettinger
priority: normal
severity: normal
stage: patch review
status: open
title: Modular interpolation in configparser
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19767/configparser_interpolation.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10499>
_______________________________________

From report at bugs.python.org  Mon Nov 22 04:19:00 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 22 Nov 2010 03:19:00 +0000
Subject: [issue6517] Emphasising in the docs configparser.SafeConfigParser
	over ConfigParser
In-Reply-To: <1247949399.94.0.0752877480689.issue6517@psf.upfronthosting.co.za>
Message-ID: <1290395940.14.0.372790835692.issue6517@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Hopefully both RawConfigParser and ConfigParser will be successfully deprecated as part of #10499. The discussion goes on there.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Modular interpolation in configparser

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6517>
_______________________________________

From report at bugs.python.org  Mon Nov 22 04:20:09 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 22 Nov 2010 03:20:09 +0000
Subject: [issue9876] ConfigParser can't interpolate values from other sections
In-Reply-To: <1284655085.98.0.131711113127.issue9876@psf.upfronthosting.co.za>
Message-ID: <1290396009.54.0.665680541113.issue9876@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Hopefully a form of this feature will be introduced as part of #10499. The discussion goes on there.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Modular interpolation in configparser

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9876>
_______________________________________

From report at bugs.python.org  Mon Nov 22 04:20:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 03:20:37 +0000
Subject: [issue10366] Remove unneeded '(object)' from 3.x class examples
In-Reply-To: <1289243952.54.0.613327832426.issue10366@psf.upfronthosting.co.za>
Message-ID: <1290396037.86.0.481164176215.issue10366@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The patch actually already contained a doc change addressing Terry?s second request, thank you Xuanji Li.  I reverted the changes to howto as per Raymond?s comment, made some other slight editions (like removing trailing whitespace) and committed as r86670 and r86672.

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10366>
_______________________________________

From report at bugs.python.org  Mon Nov 22 04:25:41 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Mon, 22 Nov 2010 03:25:41 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1290396341.97.0.815459415267.issue10087@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

I have attached a patch that conditionally uses sys.stdout.buffer.write to output binary (encoded) data to stdout.

----------
nosy: +lambacck
Added file: http://bugs.python.org/file19768/calendar_bytes_output.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Mon Nov 22 04:28:12 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Nov 2010 03:28:12 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1290396492.2.0.469176262927.issue5150@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Opened back up for the new patch (posted after the previous close).

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Mon Nov 22 04:35:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 03:35:59 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1290396959.95.0.153902525474.issue10087@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It may be acceptable, but your patch elides the line breaks in output.  Can you add unit tests?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Mon Nov 22 04:44:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 03:44:00 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290397440.07.0.0797711735439.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Not fixed: http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%203.x/builds/54/steps/test/logs/stdio

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Nov 22 04:58:01 2010
From: report at bugs.python.org (Brian Bi)
Date: Mon, 22 Nov 2010 03:58:01 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory
In-Reply-To: <1290387591.59.0.788816465526.issue10496@psf.upfronthosting.co.za>
Message-ID: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>


Brian Bi <bbi5291 at gmail.com> added the comment:

This bug is Linux-specific.

When Python cannot find the home directory of the user invoking it, it prints "'import site' failed; use -v for traceback".

This occurs only when both of these conditions are met:
1. /etc/passwd contains no entry for the current real UID
2. the HOME environment variable does not exist

To duplicate this bug, compile and run the attached program as root.
(This program assumes that 12345 is not a legitimate user on your system, and that Python is at /usr/bin/python ; if this is not the case then edit it accordingly.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Mon Nov 22 05:12:33 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 22 Nov 2010 04:12:33 +0000
Subject: [issue8631] subprocess.Popen.communicate(...) hangs on Windows
In-Reply-To: <1273095906.37.0.582736332431.issue8631@psf.upfronthosting.co.za>
Message-ID: <1290399153.09.0.322880911285.issue8631@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm with Tim and Mark - can't reproduce this, so I'm closing the report. If you are able to find another case which can reproduce this, feel free to re-open.

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8631>
_______________________________________

From report at bugs.python.org  Mon Nov 22 05:19:22 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 22 Nov 2010 04:19:22 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290399562.7.0.823125826251.issue10470@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Michael,

I feared this might be the case. Without knowing the module deeply, it's not easy to be aware of all the possible paths, preconditions, and consequences (and tests obviously didn't catch that). A suggestion - maybe documenting these parts would allow you to get more meaningful help with the module. Or at least add the tests necessary to verify them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Mon Nov 22 05:21:07 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Mon, 22 Nov 2010 04:21:07 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290399667.23.0.775399642435.issue10461@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric,

Yes, in a consequent patch I fixed this - kept the formatted code indented at 3 spaces, while adhering to PEP-8 internally. If there's anything else, let me know.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Mon Nov 22 05:26:27 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 22 Nov 2010 04:26:27 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
	(getdefaultlocale returns value not usable in setlocale)
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1290399987.09.0.911796380568.issue10466@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

FYI, calendar.localeHTMLCalendar() fails on OS X in exactly the same way for exactly the same reason.  See, for instance, Issue10090.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Mon Nov 22 05:28:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 04:28:25 +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: <1290400105.68.0.231115134771.issue10299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I like this version.  HTML and LaTex build without warning; all-pdf takes forever and spits out a metric ton of messages, so I haven?t checked its result.

The markup trickery is unfortunate, though, I?d like a pronouncement from Georg about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Mon Nov 22 05:29:07 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 22 Nov 2010 04:29:07 +0000
Subject: [issue10498] calendar.LocaleHTMLCalendar.formatyearpage() results in
	traceback with 'unsupported locale setting' on Windows
In-Reply-To: <1290393306.69.0.998081430395.issue10498@psf.upfronthosting.co.za>
Message-ID: <1290400147.05.0.159334850093.issue10498@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Fails on OS X as well for similar reasons.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10498>
_______________________________________

From report at bugs.python.org  Mon Nov 22 05:45:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 04:45:29 +0000
Subject: [issue7283] test_site failure when .local/lib/pythonX.Y/site-packages
	hasn't been created yet
In-Reply-To: <1257640034.65.0.139323856655.issue7283@psf.upfronthosting.co.za>
Message-ID: <1290401129.18.0.386058807245.issue7283@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Is this still relevant?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7283>
_______________________________________

From report at bugs.python.org  Mon Nov 22 06:06:56 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 22 Nov 2010 05:06:56 +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: <1290402416.42.0.159900177405.issue4493@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed it in r86676 (py3k), r86677 ( release31-maint) and r86678(release27-maint).

Wes: I fixed it at the much higher level in the urlparse itself, so that the fixed url is sent to the httplib.


In issue2464, John had pointed out that according to STD 66, path component can legally be empty, so when it is empty this adding of '/' does not take place.

Also added tests and NEWS.

----------
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4493>
_______________________________________

From report at bugs.python.org  Mon Nov 22 06:14:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 05:14:16 +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: <1290402856.04.0.541637592373.issue9771@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9771>
_______________________________________

From report at bugs.python.org  Mon Nov 22 07:23:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 06:23:44 +0000
Subject: [issue8416] python 2.6.5 documentation can't search
In-Reply-To: <1271397834.22.0.547082855086.issue8416@psf.upfronthosting.co.za>
Message-ID: <1290407024.79.0.504319343763.issue8416@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: docs at python -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8416>
_______________________________________

From report at bugs.python.org  Mon Nov 22 07:27:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 06:27:46 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290407266.4.0.104060422655.issue9264@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python -georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Mon Nov 22 07:41:47 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 22 Nov 2010 06:41:47 +0000
Subject: [issue10461] Use with statement throughout the docs
In-Reply-To: <1290182704.47.0.121540663424.issue10461@psf.upfronthosting.co.za>
Message-ID: <1290408107.17.0.420330605804.issue10461@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> I?m not 100% sure I should change 'r' to 'rb' in logging:
> It?s unrelated to with, and the rest of the file 
> has not been checked for similar errors. 

Good catch.  This should only be a with-statement transformation.  I caught other accidental semantic changes, so be continue to exercise care.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10461>
_______________________________________

From report at bugs.python.org  Mon Nov 22 08:47:01 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Nov 2010 07:47:01 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1290385502.3620.46.camel@localhost.localdomain>
Message-ID: <4CEA1FF3.8080901@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Well, unless someone explains convincingly how the current behaviour is
> desireable (rather than misleading and useless), I really think this is
> a bug that should be fix (then we can also discuss what the fix should
> exactly be).

So please propose a fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Mon Nov 22 08:54:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Nov 2010 07:54:57 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <1290388934.12.0.651177427391.issue7995@psf.upfronthosting.co.za>
Message-ID: <4CEA21CC.4010907@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Set blocking or non-blocking mode of the socket: if flag is 0, the
> socket is set to non-blocking, else to blocking mode.
> 
> This seems to imply that timeout = None -> blocking.

I see. So gettimeout() should really make a system call, to determine
whether to return 0.0 or None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Mon Nov 22 09:04:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Nov 2010 08:04:17 +0000
Subject: [issue10483] http.server - what is executable on Windows
In-Reply-To: <1290391420.52.0.792385538066.issue10483@psf.upfronthosting.co.za>
Message-ID: <4CEA23F9.4050100@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin, that is an interesting viewpoint, and one I considered, but
> didn't state, because it seems much too restrictive.  Most CGI
> programs are written in scripting languages, not compiled to .exe.
> So it seems the solution should allow for launching at least Perl and
> Python scripts, as well as .exe.

Notice that it does support launching Python scripts. I disagree that
Perl scripts need to be supported. The idea of CGI is really that
"programs" get run by the web server, with the notion of "programs"
clearly deviating from system to system. Window really doesn't support
"scripts" (in the hash-bang sense), and it isn't the function of
http.server to extend Windows here. At best, support for .bat files
might be negotiable, using cmd.exe to launch them (but I personally
would not).

Anybody who wants support for other kinds of scripts on Windows will
have to subclass CGIHTTPRequestHandler (and it might be useful to
simplify subclassing that class).

In any case, the bug as stated ("def executable is simply wrong")
has a clear resolution - make it match what the rest of the code
supports. Anything beyond that is a feature request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10483>
_______________________________________

From report at bugs.python.org  Mon Nov 22 09:44:47 2010
From: report at bugs.python.org (Gynvael Coldwind)
Date: Mon, 22 Nov 2010 08:44:47 +0000
Subject: [issue1284316] Win32: Security problem with default installation
	directory
Message-ID: <1290415487.61.0.261588741928.issue1284316@psf.upfronthosting.co.za>


Gynvael Coldwind <gynvael at gmail.com> added the comment:

(since Issue 10491 is superseded by this one, I'll reply here)

As I've said in issue 10491, in my opinion this is not a case of frustrating users because they have to elevate the console (I think they have to do that in case of UAC anyway), but a case of privilege escalation vulnerability on mutli-user Windows systems with Python installed globally (i.e. in the default installation directory).

Though I am aware there are not many such systems to begin with, I am pretty certain they do exist (think: servers at an University giving Python access to students, and not using *nix for some reason).
There are also non-multi-user systems with multiple accounts (think: production systems running stuff on different accounts), and this issue can be abused as one of many steps during an attack, after gaining shell access, but before gaining administrative rights.

I acknowledge your right to choose not to fix this issue due to usability issues, but in such case imo there should be an explicit message during the installation making the user aware of this insecurity.
The last months revealed issues like this in many applications and tools, and they have (mostly) been patched, so administrators might assume this was also fixed in Python (especially since this is known from 2005).

----------
nosy: +Gynvael.Coldwind

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1284316>
_______________________________________

From report at bugs.python.org  Mon Nov 22 10:00:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Nov 2010 09:00:26 +0000
Subject: [issue10459] missing character names in unicodedata (CJK...)
In-Reply-To: <1290177387.08.0.667845269575.issue10459@psf.upfronthosting.co.za>
Message-ID: <1290416426.25.0.0109317591424.issue10459@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

For 3.2, this now fixed in r86681.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10459>
_______________________________________

From report at bugs.python.org  Mon Nov 22 10:16:36 2010
From: report at bugs.python.org (Vil)
Date: Mon, 22 Nov 2010 09:16:36 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>


New submission from Vil <vilignoble at gmail.com>:

scan on msi installer x86 win 3.x python gives Win32/Palevo.DZ worm and erases.

----------
messages: 122101
nosy: VilIgnoble
priority: normal
severity: normal
status: open
title: Palevo.DZ worm msix86 installer 3.x installer
type: security
versions: Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Mon Nov 22 10:17:22 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Mon, 22 Nov 2010 09:17:22 +0000
Subject: [issue10483] http.server - what is executable on Windows
In-Reply-To: <1290324390.55.0.445837984524.issue10483@psf.upfronthosting.co.za>
Message-ID: <1290417442.89.0.135347968264.issue10483@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

The rest of the code has clearly never had its deficiencies exposed on Windows, simply because executable() has prevented that.  So what the rest of the code "already supports" is basically nothing.  Reasonable Windows support is appropriate to implement as part of the bugfix.

You state that it isn't the function of http.server to extend Windows, however, even MS IIS has extended Windows to provide reasonable web scripting functionality, albeit it its own way, thus convicting the Windows facilities of being insufficient.  Attempting to use http.server to get a web testing environment running so that Python scripts can be tested locally requires some way of using an existing environment (except, of course, for "all new" web sites).  I suppose you would claim that using http.server for a web testing environment is an inappropriate use of http.server, also.  

Yet http.server on Unix appears to provide an adequate web testing environment: yes, some of that is because of Unix's #! feature.  This would certainly not be the first case where more code is required on Windows than Unix to implement reasonable functionality.

My desire for support for Perl is not an attempt to convince Python developers to use Perl instead of Python, but simply a reflection of the practicality of life: There are a lot of Perl CGI scripts used for pieces of Web servers.  Reinventing them in Python may be fun, but can be more time consuming than projects may have the luxury to do.

Your claim that it already supports Python CGI scripts must be tempered by the documentation claim that it provides "altered semantics".  "altered semantics", as best as I can read in the code, is that the query string is passed to the Python script as a command line if it doesn't happen to contain an "=" sign.  This is weird, unlikely to be found in a real web server, and hence somewhat useless for use as a test server also.

http.server has chosen to use subprocess which has chosen to use CreateProcess as its way of executing CGI.  There are other Windows facilities for executing programs, such as ShellExecute, but of course it takes the opposite tack: it can "execute" nearly any file, via registry-based associations.  Neither of these seem to be directly appropriate for use by http.server, the former being too restrictive without enhancements, the latter being too liberal in executing too many file types, although the requirement that CGI scripts live in specific directories may sufficiently rein in that liberality.

However, you have made me think through the process: it seems that an appropriate technique for Windows is to allow for a specific set of file extensions, and permit them to be executed using the registry-based association to do so.  However, for .cgi files, which depend heavily on the Unix #!, emulation of #! seems appropriate (and Windows doesn't seem to have an association for .cgi files either).

Your suggestion of making CGIHTTPRequestHandler easier to subclass is certainly a good one, and is almost imperative to implement to fix this bug in a useful manner without implementing an insufficient set of Windows extensions (for someone's definition of wrong).  There should be a way to sidestep the "altered semantics" for Python scripts (and Python scripts shouldn't have to be a special case, they should work with the general case), without replacing the whole run_cgi() function.  There should be a hook to define the list of executable extensions, and how to run them, and/or a hook to alter the command line passed to subprocess.Popen to achieve same.

So is_executable and is_python both seem to currently be replacable.  What is missing is a hook to implement cmdline creation before calling subprocess.Popen()  (besides the other reported bugs, of course)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10483>
_______________________________________

From report at bugs.python.org  Mon Nov 22 10:17:34 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Mon, 22 Nov 2010 09:17:34 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <1290270595.85.0.575802390463.issue10231@psf.upfronthosting.co.za>
Message-ID: <hbf.20101122e306@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Senthil Kumaran writes:
> I have doubts on the validity of this bug itself.
> 
> - First is, query and fragment are usually for the file being served
> from the webserver, not on the directories. If there are characters such
> as '?' and '#' in the directory names, which may get featured in the
> path, then those should be quoted in the request. So foo/dir?baz is
> wrong where as foo/dir%3Fbaz it the correct request.

That's backwards.  Start with the URL spec (RFC 3986), not with
thinking of filesystem paths.  If '?' or '#' do occur in the URL, they
are not part of the path.  That is the case this bug report is about.

That's because it reserves these characters for query and fragment.
So yes, the if filesystem path contains '?' or '#', these must be
escaped in the URL.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Mon Nov 22 11:01:43 2010
From: report at bugs.python.org (Martin)
Date: Mon, 22 Nov 2010 10:01:43 +0000
Subject: [issue10501] make_buildinfo regression with unquoted path
In-Reply-To: <1290420103.87.0.191839202946.issue10501@psf.upfronthosting.co.za>
Message-ID: <1290420103.87.0.191839202946.issue10501@psf.upfronthosting.co.za>


New submission from Martin <gzlist at googlemail.com>:

My build got broken by the change for issue 9981 in revision 86137. The problem is it adds $(IntDir) to various places in the vcproj file, including the command line arguments to make_buildinfo, and my svn checkout is under a dir with a space in.

Ideally it could just use a relative path, but just making sure it's quoted works too.

----------
components: Build
files: issue9981_regression.patch
keywords: patch
messages: 122104
nosy: gz, krisvale
priority: normal
severity: normal
status: open
title: make_buildinfo regression with unquoted path
versions: Python 3.2
Added file: http://bugs.python.org/file19769/issue9981_regression.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10501>
_______________________________________

From report at bugs.python.org  Mon Nov 22 11:51:14 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 22 Nov 2010 10:51:14 +0000
Subject: [issue10470] python -m unittest ought to default to discovery
In-Reply-To: <1290275740.25.0.645194828308.issue10470@psf.upfronthosting.co.za>
Message-ID: <1290423074.58.0.688909595219.issue10470@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Eli - I quite agree. TestProgram is a *particularly* obscure part of unittest. A much better solution (well - both would be ideal) would be to refactor the code so that it isn't so obscure.

TestProgram is an artefact of unittest's history and should be a series of functions rather than a class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10470>
_______________________________________

From report at bugs.python.org  Mon Nov 22 11:52:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 22 Nov 2010 10:52:51 +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: <1290423171.56.0.885395747743.issue9771@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> no cookie found, returns ('utf-8', [line1, line2])

I never understood the usage of the second item. IMO it should be None if no cookie found.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9771>
_______________________________________

From report at bugs.python.org  Mon Nov 22 11:54:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Nov 2010 10:54:12 +0000
Subject: [issue10459] missing character names in unicodedata (CJK...)
In-Reply-To: <1290177387.08.0.667845269575.issue10459@psf.upfronthosting.co.za>
Message-ID: <1290423252.02.0.975480464978.issue10459@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch for 3.1 is r86685. The patch for 2.7 is r86686.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10459>
_______________________________________

From report at bugs.python.org  Mon Nov 22 12:06:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Nov 2010 11:06:26 +0000
Subject: [issue10483] http.server - what is executable on Windows
In-Reply-To: <1290417442.89.0.135347968264.issue10483@psf.upfronthosting.co.za>
Message-ID: <4CEA4EAD.90705@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Your suggestion of making CGIHTTPRequestHandler easier to subclass is
> certainly a good one, and is almost imperative to implement to fix
> this bug in a useful manner without implementing an insufficient set
> of Windows extensions (for someone's definition of wrong).

It's indeed the approach I would prefer over the alternatives you
suggested - I particularly dislike Python implementing a strategy
where #! files become considered on Windows (you then immediately
run into subsequent problems, such as /usr/bin/perl being no valid
filename on most Windows installations).

So I maintain that technically, in order to resolve the *reported*
issue (msg121875), it is sufficient to define that executables
on Windows are the files ending with .exe. To recall, the reported
issue is "is simply wrong ... is not clear what to use instead"
(to you as the reporter). My job as a maintainer is to resolve this,
and I will decide to resolve this as suggested. Even the refactoring
to allow substitution of process creation is an independent feature,
but I'm willing to accept patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10483>
_______________________________________

From report at bugs.python.org  Mon Nov 22 12:07:41 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Nov 2010 11:07:41 +0000
Subject: [issue10501] make_buildinfo regression with unquoted path
In-Reply-To: <1290420103.87.0.191839202946.issue10501@psf.upfronthosting.co.za>
Message-ID: <1290424061.02.0.398547520162.issue10501@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Kristjan, can you take a look?

----------
assignee:  -> krisvale
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10501>
_______________________________________

From report at bugs.python.org  Mon Nov 22 12:13:08 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 22 Nov 2010 11:13:08 +0000
Subject: [issue1675455] Use getaddrinfo() in urllib2.py for IPv6 support
Message-ID: <1290424388.24.0.345969498616.issue1675455@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee: facundobatista -> orsenthil
nosy:  -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1675455>
_______________________________________

From report at bugs.python.org  Mon Nov 22 12:14:54 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 22 Nov 2010 11:14:54 +0000
Subject: [issue10483] http.server - what is executable on Windows
In-Reply-To: <1290324390.55.0.445837984524.issue10483@psf.upfronthosting.co.za>
Message-ID: <1290424494.14.0.682259412337.issue10483@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/issue10483>
_______________________________________

From report at bugs.python.org  Mon Nov 22 12:22:58 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 22 Nov 2010 11:22:58 +0000
Subject: [issue10502] Add unittestguirunner to Tools/
In-Reply-To: <1290424978.75.0.300298743015.issue10502@psf.upfronthosting.co.za>
Message-ID: <1290424978.75.0.300298743015.issue10502@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Add the unittestgui test runner, built with Tk, to the Tools directory.

It would be good to have this script included in the bin/ directory of the Mac installer as well.

The unittestgui runner can be found at:

    https://bitbucket.org/markroddy/unittestgui

The code is a modification of the original unittestgui by Steve Purcell and updated for test discovery by Mark Roddy. I have asked Mark if he is willing to help maintain the code and asked him to complete a contributor agreement.

----------
assignee: michael.foord
components: Library (Lib)
messages: 122110
nosy: michael.foord, ronaldoussoren
priority: low
severity: normal
stage: needs patch
status: open
title: Add unittestguirunner to Tools/
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10502>
_______________________________________

From report at bugs.python.org  Mon Nov 22 12:28:14 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 22 Nov 2010 11:28:14 +0000
Subject: [issue10502] Add unittestguirunner to Tools/
In-Reply-To: <1290424978.75.0.300298743015.issue10502@psf.upfronthosting.co.za>
Message-ID: <1290425294.97.0.949686666864.issue10502@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

It will need documenting, or at least pointing to in the documentation, probably with a note recommending Hudson for production use - unittestgui is a tool for beginners / convenience.

Note also that Brian Curtin has contributed a patch to make unittestgui Python 3 compatible. This has not yet been 'merged upstream':

http://lists.idyll.org/pipermail/testing-in-python/2010-November/003604.html

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10502>
_______________________________________

From report at bugs.python.org  Mon Nov 22 12:29:56 2010
From: report at bugs.python.org (Ole Laursen)
Date: Mon, 22 Nov 2010 11:29:56 +0000
Subject: [issue7257] Improve documentation of list.sort and sorted()
In-Reply-To: <1257271402.44.0.845935336984.issue7257@psf.upfronthosting.co.za>
Message-ID: <1290425396.65.0.361142570887.issue7257@psf.upfronthosting.co.za>


Ole Laursen <olau at iola.dk> added the comment:

Okay. I can only say that while the current docstrings are likely good reminders for you, knowing Python in and out, they were pretty useless to me as documentation, which I believe docstrings should be, they're called docstrings, after all, not reminderstrings. :) I fail to see how including more info can hurt in any way, you're not forced to read it if you don't need it, so I hope you (or somebody else) will reconsider at some point.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7257>
_______________________________________

From report at bugs.python.org  Mon Nov 22 12:38:21 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 22 Nov 2010 11:38:21 +0000
Subject: [issue10501] make_buildinfo regression with unquoted path
In-Reply-To: <1290420103.87.0.191839202946.issue10501@psf.upfronthosting.co.za>
Message-ID: <1290425901.79.0.085469134206.issue10501@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Ah yes, spaces in filenames.  One always forgets.
Fixed the make_buildinfo.c (quote whole string, not just part of it) and committed in revision 86689

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10501>
_______________________________________

From report at bugs.python.org  Mon Nov 22 13:18:36 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 22 Nov 2010 12:18:36 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1290428316.6.0.760945211106.issue8890@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Actually, I don't think it's a great idea in general to use temporary files for logging, though of course there are specific cases where one might do this. So for the logging examples in the docs (which used '/tmp/XXX') I just removed the '/tmp/' part.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Mon Nov 22 13:48:22 2010
From: report at bugs.python.org (Rob Cliffe)
Date: Mon, 22 Nov 2010 12:48:22 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1290385583.12.0.916280192141.issue8525@psf.upfronthosting.co.za>
Message-ID: <4CEA668F.5020302@btinternet.com>


Rob Cliffe <rob.cliffe at btinternet.com> added the comment:

Thanks for your work.  Glad if I have made a contribution to Python, 
however small.
Rob Cliffe

On 22/11/2010 00:26, ?ric Araujo wrote:
> ?ric Araujo<merwok at netwok.org>  added the comment:
>
> Thank you.  I uploaded your patch to Rietveld and reviewed it: http://codereview.appspot.com/3169042/
>
> ----------
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue8525>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Mon Nov 22 13:58:58 2010
From: report at bugs.python.org (Rob Cliffe)
Date: Mon, 22 Nov 2010 12:58:58 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1290389622.81.0.165922690352.issue8525@psf.upfronthosting.co.za>
Message-ID: <4CEA690B.4010809@btinternet.com>


Rob Cliffe <rob.cliffe at btinternet.com> added the comment:

I would not be at all surprised if my patch could be simplified (in fact 
I'd be surprised if it couldn't).
However, I did try out your version on Python 2.5 specifically, and it 
did not work for me.
Trying it out on help(Exception), the relevant members of 
object.__subclasses__() viz.
<type 'exceptions.StandardError'>, <type 'exceptions.StopIteration'>  etc.
had a __module__attribute which equalled 'exceptions', not 'builtins'.
Best wishes
Rob Cliffe

On 22/11/2010 01:33, Alexander Belopolsky wrote:
> Alexander Belopolsky<belopolsky at users.sourceforge.net>  added the comment:
>
> The following passes tests in elp_8525.patch, but is much simpler:
>
> ===================================================================
> --- Lib/pydoc.py	(revision 86600)
> +++ Lib/pydoc.py	(working copy)
> @@ -1139,6 +1139,15 @@
>                   push('    ' + makename(base))
>               push('')
>
> +        # List the built-in subclasses, if any:
> +        subclasses = [cls.__name__ for cls in object.__subclasses__()
> +                      if cls.__module__ == 'builtins']
> +        if subclasses:
> +            push("Built-in subclasses:")
> +            for subclassname in sorted(subclasses):
> +                push('    ' + subclassname)
> +            push('')
> +
>           # Cute little class to pump out a horizontal rule between sections.
>           class HorizontalRule:
>               def __init__(self):
>
> ----------
> nosy: +belopolsky
>
> _______________________________________
> Python tracker<report at bugs.python.org>
> <http://bugs.python.org/issue8525>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Mon Nov 22 14:01:11 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Nov 2010 13:01:11 +0000
Subject: [issue10503] os.getuid() documentation should be clear on what kind
	of uid it is referring
In-Reply-To: <1290430871.92.0.135823537975.issue10503@psf.upfronthosting.co.za>
Message-ID: <1290430871.92.0.135823537975.issue10503@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

http://docs.python.org/library/os.html#os.getuid
os.getuid() documentation just states:

> Return the current process?s user id.

It is not clear, however, whether "user id" refers to real, effective or saved user id.

As per:
http://linux.about.com/library/cmd/blcmdl2_getuid.htm
...it should refer to _real_ user id.

----------
assignee: docs at python
components: Documentation
messages: 122117
nosy: docs at python, giampaolo.rodola
priority: normal
severity: normal
status: open
title: os.getuid() documentation should be clear on what kind of uid it is referring
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10503>
_______________________________________

From report at bugs.python.org  Mon Nov 22 14:05:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 13:05:49 +0000
Subject: [issue8525] Small enhancement to help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1290431149.32.0.720163296031.issue8525@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

New features can only go into 3.2, so you have to test with an updated checkout of the Subversion branch named py3k.  See the link I have in a previous message.

(P.S. Would you be so kind as to edit quoted text out of your replies?  It?s unnecessary noise.  Thanks in advance.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Mon Nov 22 14:09:16 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 22 Nov 2010 13:09:16 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
	(getdefaultlocale returns value not usable in setlocale)
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1290431356.38.0.635921035266.issue10466@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I think that's a bug in the resetlocale() API.

The correct way to reset the locale setting to defaults, it to use

setlocale(category, "")

The other issues here is that getlocale() appears to return non-ISO language codes on Windows. If that's indeed the case, then we would need to add mappings of the Windows codes to the ISO ones and use a reverse mappings to make setlocale() work with the ISO codes.

Perhaps it's easier to just update the mapping used by getdefaultencoding() to return the non-ISO codes used by Windows and then update the documentation to say that on Windows, non-ISO codes are returned.

BTW: I wonder why this hasn't popped up earlier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Mon Nov 22 14:11:59 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Nov 2010 13:11:59 +0000
Subject: [issue9424] Disable unittest.TestCase.assertEquals and assert_ during
	a regrtest run
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1290431519.82.0.416073944542.issue9424@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Committed in r86690 on py3k, blocked in r86691 and r88692 on 3.1/2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9424>
_______________________________________

From report at bugs.python.org  Mon Nov 22 14:18:44 2010
From: report at bugs.python.org (Wes Chow)
Date: Mon, 22 Nov 2010 13:18:44 +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: <1290431924.99.0.626660417428.issue4493@psf.upfronthosting.co.za>


Wes Chow <wes.chow at gmail.com> added the comment:

This same bug also exists in HTTPClient, and my patch addresses that. Addressing it in HTTPClient has a side effect of taking care of it for urllib2 as well (and all future libraries that use HTTPClient).

Even if the urllib2 patch is preferable, shouldn't we fix the problem in HTTPClient as well?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4493>
_______________________________________

From report at bugs.python.org  Mon Nov 22 14:20:20 2010
From: report at bugs.python.org (Johann Hanne)
Date: Mon, 22 Nov 2010 13:20:20 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>


New submission from Johann Hanne <python at jf.hanne.name>:

There are a number of mingw compile issues which are easily fixed
* some "_MSC_VER" #if's should be "MS_WINDOWS" instead
* for cross-compiling, windows.h should be all-lowercase
* mingw has a strcasecmp, so private implementations must not use that name

----------
components: Build
files: Python-2.7.diff
keywords: patch
messages: 122122
nosy: jonny
priority: normal
severity: normal
status: open
title: Trivial mingw compile fixes
versions: Python 2.7
Added file: http://bugs.python.org/file19770/Python-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Mon Nov 22 14:37:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 13:37:15 +0000
Subject: [issue940286] pydoc.Helper.help() ignores input/output init parameters
Message-ID: <1290433035.29.0.393075589066.issue940286@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage: unit test needed -> patch review
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue940286>
_______________________________________

From report at bugs.python.org  Mon Nov 22 14:42:44 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Nov 2010 13:42:44 +0000
Subject: [issue10503] os.getuid() documentation should be clear on what kind
	of uid it is referring
In-Reply-To: <1290430871.92.0.135823537975.issue10503@psf.upfronthosting.co.za>
Message-ID: <1290433364.17.0.655498376057.issue10503@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Update: I think also os.getlogin() doc is wrong.
This is what it states (2.7 doc):


> Return the name of the user logged in on the controlling terminal of 
> the process. For most purposes, it is more useful to use the 
> environment variable LOGNAME to find out who the user is, or 
> pwd.getpwuid(os.getuid())[0] to get the login name of the currently 
> effective user id.

Since os.getuid() refers to _real_ uid the last sentence should be changed as such:

- ... to get the login name of the currently effective user id.
+ ... to get the login name of the currently real user id.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10503>
_______________________________________

From report at bugs.python.org  Mon Nov 22 14:59:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 13:59:46 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1275599514.93.0.639768129715.issue8890@psf.upfronthosting.co.za>
Message-ID: <1290434386.24.0.472146992667.issue8890@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Whatsnew documents are not edited after the corresponding release is done.

Using either /home/user or tempfile depending on the example seems good to me.

----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Mon Nov 22 15:02:29 2010
From: report at bugs.python.org (And Clover)
Date: Mon, 22 Nov 2010 14:02:29 +0000
Subject: [issue10490] mimetypes read_windows_registry fails for non-ASCII keys
In-Reply-To: <1290348624.99.0.246792937165.issue10490@psf.upfronthosting.co.za>
Message-ID: <1290434549.74.0.87011768656.issue10490@psf.upfronthosting.co.za>


Changes by And Clover <and at doxdesk.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10490>
_______________________________________

From report at bugs.python.org  Mon Nov 22 15:10:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 14:10:39 +0000
Subject: [issue10351] Add autocompletion for keys in dictionaries
In-Reply-To: <1289208160.65.0.489934250712.issue10351@psf.upfronthosting.co.za>
Message-ID: <1290435039.53.0.131589953924.issue10351@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Review time!

+            elif "[" in text:
+                self.matches = self.dict_key_matches(text)
Does this complete only dicts?  What about other mappings?  What about other sequences implementing __getitem__?  One of the function name and the function docstring (?Compute matches when text contains a [?) is wrong.

I?m not familiar with rlcompleter?s internals, so I?d like a few comments sprinkled in the code.

Please wrap your lines at 79 columns, and follow other advice given at http://www.python.org/dev/patches/ for the next version of your patch.

+        The evaluation of the part before the '[' could be enhanced.
This belongs in a comment or a test, not the docstring.

+                          'DictCompleteMe[\'?h, ???!\']',
I find it more readable to avoid escaped quotes whenever possible.  Here I would use "DictCompleteMe['?h, ???!']".

----------
assignee: docs at python -> 
components:  -Documentation
nosy:  -docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10351>
_______________________________________

From report at bugs.python.org  Mon Nov 22 15:14:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 14:14:41 +0000
Subject: [issue9095] patchcheck should handle extraneous whitespace in .rst
	files
In-Reply-To: <1277683188.13.0.698937807833.issue9095@psf.upfronthosting.co.za>
Message-ID: <1290435281.86.0.338982875889.issue9095@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I tried to use ?make patchcheck? after edits to reST files and it hung.  Do you have the same behavior?  I suspect reindent-rst is the culprit.

I?m wondering about the reindenting; other checks in patchcheck don?t edit files, they just print warnings.  On the other hand, removing trailing whitespace and reindenting is not a very good use of people?s time, so having a tool do them is good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9095>
_______________________________________

From report at bugs.python.org  Mon Nov 22 15:22:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Nov 2010 14:22:20 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
	(getdefaultlocale returns value not usable in setlocale)
In-Reply-To: <1290252967.41.0.731933480084.issue10466@psf.upfronthosting.co.za>
Message-ID: <1290435740.67.0.233147659467.issue10466@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I had a report from a user on IRC during the bug weekend that they could not reproduce the failure on windows.  So it may be dependent on the windows version.  That doesn't answer your question of why it hasn't come up before, though, since my tests were done on XP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Mon Nov 22 15:35:10 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 22 Nov 2010 14:35:10 +0000
Subject: [issue8890] Use tempfile instead of /tmp in examples
In-Reply-To: <1290434386.24.0.472146992667.issue8890@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=4BgYDAburfRdOfqY-HC+DE3kPK8Owrz8LRykS@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

On Mon, Nov 22, 2010 at 3:59 PM, ?ric Araujo <report at bugs.python.org> wrote:
>
> Using either /home/user or tempfile depending on the example seems good to me.

There is no /home/user on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8890>
_______________________________________

From report at bugs.python.org  Mon Nov 22 15:41:01 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Nov 2010 14:41:01 +0000
Subject: [issue10505] test_compileall: failure on Windows
In-Reply-To: <1290436861.2.0.949671079169.issue10505@psf.upfronthosting.co.za>
Message-ID: <1290436861.2.0.949671079169.issue10505@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

On Windows, test_compileall fails due to #10197:

======================================================================
FAIL: test_quiet (test.test_compileall.CommandLineTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_compileall.py", line 227, in test_quiet
    self.assertGreater(len(noise), len(quiet))
AssertionError: 89 not greater than 89


The patch uses subprocess.check_output() instead. Technically, now
byte strings are compared instead of strings, but that should not matter
for the outcome.

Does the patch look ok?

----------
components: Tests
files: test_compileall.patch
keywords: buildbot, patch
messages: 122129
nosy: brian.curtin, r.david.murray, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: test_compileall: failure on Windows
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19771/test_compileall.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10505>
_______________________________________

From report at bugs.python.org  Mon Nov 22 15:47:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 14:47:35 +0000
Subject: [issue10505] test_compileall: failure on Windows
In-Reply-To: <1290436861.2.0.949671079169.issue10505@psf.upfronthosting.co.za>
Message-ID: <1290437255.2.0.0725277759457.issue10505@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you post on #10453?  Thanks in advance.

----------
nosy: +eric.araujo
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Add -h/--help option to compileall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10505>
_______________________________________

From report at bugs.python.org  Mon Nov 22 15:48:21 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Mon, 22 Nov 2010 14:48:21 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1290437301.3.0.392484106832.issue10087@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

I don't understand what you mean by "elides the line breaks in output". They are still there, you just don't see them as \n because print() is no longer implicitly converting the bytes to a string (which appears to actually result in a repr).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Mon Nov 22 15:48:54 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Nov 2010 14:48:54 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1290437334.67.0.214175039954.issue10087@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/issue10087>
_______________________________________

From report at bugs.python.org  Mon Nov 22 15:57:17 2010
From: report at bugs.python.org (Stefan Krah)
Date: Mon, 22 Nov 2010 14:57:17 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290437837.59.0.25572596082.issue10453@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

On Windows, test_compileall fails due to #10197. The patch uses
subprocess.check_output() instead. Technically, now byte strings
are compared instead of strings, but that should not matter for
the outcome.

----------
nosy: +skrah
Added file: http://bugs.python.org/file19772/test_compileall.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Mon Nov 22 16:06:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Nov 2010 15:06:50 +0000
Subject: [issue7995] On Mac / BSD sockets returned by accept inherit the
	parent's FD flags
In-Reply-To: <4CEA1FF3.8080901@v.loewis.de>
Message-ID: <1290438403.3566.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > Well, unless someone explains convincingly how the current behaviour is
> > desireable (rather than misleading and useless), I really think this is
> > a bug that should be fix (then we can also discuss what the fix should
> > exactly be).
> 
> So please propose a fix.

Well, in case you didn't notice, a fix was already proposed :)
(not in proper form, granted, and lacking a test)

At least now you won't argue that this is normal behaviour, so we are
progressing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7995>
_______________________________________

From report at bugs.python.org  Mon Nov 22 16:15:23 2010
From: report at bugs.python.org (Tarsis Azevedo)
Date: Mon, 22 Nov 2010 15:15:23 +0000
Subject: [issue10506] argparse execute system exit in python prompt
In-Reply-To: <1290438923.5.0.695068609524.issue10506@psf.upfronthosting.co.za>
Message-ID: <1290438923.5.0.695068609524.issue10506@psf.upfronthosting.co.za>


New submission from Tarsis Azevedo <tarsis.azevedo at gmail.com>:

Hi all, when I use argparse in python prompt, and raise a exception, as the code below:

    >>> import argparse
    >>> parser = argparse.ArgumentParser()
    >>> parser.add_argument('-i' type=int)
    >>> parser.parse_args(['-i', 'a'])

the prompt is closed.

This behavior this in error function (Lib/argparse.py:2325)
I think in python prompt this behavior it's wrong.

it's right?!

----------
components: Library (Lib)
messages: 122134
nosy: Tarsis.Azevedo
priority: normal
severity: normal
status: open
title: argparse execute system exit in python prompt
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10506>
_______________________________________

From report at bugs.python.org  Mon Nov 22 16:24:23 2010
From: report at bugs.python.org (Doug Shea)
Date: Mon, 22 Nov 2010 15:24:23 +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: <1290439463.65.0.0200035713145.issue9742@psf.upfronthosting.co.za>


Doug Shea <doug.shea at gmail.com> added the comment:

I have some knowledge of these things, so I'll try to find out what's going on, but I could also upload output and/or debug files here for you to examine, if that helps. If you give me the files you'd like to see from my build, or the commands you'd like the output of, I'd be happy to oblige. Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Mon Nov 22 16:27:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 15:27:47 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1290437301.3.0.392484106832.issue10087@psf.upfronthosting.co.za>
Message-ID: <AANLkTikABRzx65FtAd1=-ToJ3qS6wgcoD9S+k0e3JEdm@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Nov 22, 2010 at 9:48 AM, Chris Lambacher <report at bugs.python.org> wrote:
..
> I don't understand what you mean by "elides the line breaks in output".

It is actually not that bad:

$ ./python.exe -m calendar -t html| wc -l
     121
$ python2.7 -m calendar -t html| wc -l
     122

At first, I thought that html was printed one line at a time, but now
I realize that it is prepared in-memory and printed in one shot.  The
extra '\n' in python2.7 is probably a bug in 2.7.

I think this is a reasonable approach.    Just a few comments on the patch:

1. Unit tests needed.
2. It may be appropriate to add a warning to the documentation stating
that using -e option may mess up the terminal.
3.   In the following snippet, p is an unconditional shortcut to
sys.stdout.buffer.write.  I would just call it "write"

         optdict = dict(encoding=encoding, css=options.css)
+        p = sys.stdout.buffer.write

4.  While white space consistency with 2.7 is not very important, the
following should be fixed, IMO:

$ ./python.exe -m calendar -e ascii| wc -l
      35
$ ./python.exe -m calendar| wc -l
      36

5. I wonder how ./python.exe -m calendar -e ascii will look on
Windows.  I don't think cmd window is smart about displaying unix line
endings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Mon Nov 22 16:32:47 2010
From: report at bugs.python.org (nh2)
Date: Mon, 22 Nov 2010 15:32:47 +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: <1290439967.9.0.942957453512.issue1975@psf.upfronthosting.co.za>


nh2 <nh2 at deditus.de> added the comment:

My problem was actually related to the subprocess.Popen I use inside my threads in combination with signals. As Popen does not spawn a new thread, but a new process, it completely ignores my locks.

However, it seems impossible to safely unregister signals for subprocesses. I tried using SIG_IGN in preexec_fn for Popen as well as a ignore/Popen/unignore wrapper, but both result in race conditions (for the first: if the signal arrives between fork and exec and for the second if it arrives within the wrapper).

I think ignoring signals by default for everything but the main thread or process would solve this problem and make parallel programming with events in Python a lot easier.

Explicit is better than implicit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Nov 22 16:44:59 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 22 Nov 2010 15:44:59 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1290440699.23.0.573707361738.issue10220@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Temporarily reopening to remind me to switch from using integer constants to strings (which are much friendlier for debugging purposes).

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Mon Nov 22 16:53:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 22 Nov 2010 15:53:09 +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: <1290441189.39.0.241465523373.issue9742@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Doug:  thanks.  I think I may just be being stupid here. One thing you might try is replacing the line

  extern double round(double);

in Include/pymath.h, with:

  PyAPI_FUNC(double) round(double);

and see if that helps.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Mon Nov 22 17:12:10 2010
From: report at bugs.python.org (Doug Shea)
Date: Mon, 22 Nov 2010 16:12:10 +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: <1290442330.26.0.559481102476.issue9742@psf.upfronthosting.co.za>


Doug Shea <doug.shea at gmail.com> added the comment:

I unpacked a fresh tarball, made this change, then did a ./configure and make as normal. Exact same error as originally reported. :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Mon Nov 22 17:17:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Nov 2010 16:17:29 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290442649.64.0.758146084514.issue10504@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What's the objective of this patch? I.e. what precisely is it supposed to achieve?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Mon Nov 22 17:29:45 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 22 Nov 2010 16:29:45 +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: <1290443385.42.0.482284503735.issue9742@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Hmm.  That's puzzling indeed.

I made a claim earlier that 'round' is already used in Objects/floatobject.c, but it occurs to me now that that's not true if PY_NO_SHORT_FLOAT_REPR is #defined.

Could you attach the pyconfig.h file produced by configure?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Mon Nov 22 17:29:31 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 22 Nov 2010 16:29:31 +0000
Subject: [issue10507] Check well-formedness of reST markup within "make
	patchcheck"
In-Reply-To: <1290443371.49.0.836951290391.issue10507@psf.upfronthosting.co.za>
Message-ID: <1290443371.49.0.836951290391.issue10507@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

Misc/NEWS needs to be valid reST.

Issue 10450 identified an issue where it wasn't.

"make patchcheck" potentially could check the markup of that file, and, potentially all the other places in the source tree that are supposed to be valid reST (all of the .rst files in the source tree, especially those below Doc).

I don't know what the best way of doing this is, without pulling in a lot of dependencies.  (Perhaps we could look for rst2html on $PATH, and use it if it's present?).

----------
components: Demos and Tools
messages: 122142
nosy: dmalcolm
priority: normal
severity: normal
stage: needs patch
status: open
title: Check well-formedness of reST markup within "make patchcheck"
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10507>
_______________________________________

From report at bugs.python.org  Mon Nov 22 17:30:25 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 22 Nov 2010 16:30:25 +0000
Subject: [issue10450] Fix markup in Misc/NEWS
In-Reply-To: <1290256717.74.0.425254722805.issue10450@psf.upfronthosting.co.za>
Message-ID: <1290443421.22578.10.camel@radiator.bos.redhat.com>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Opened as issue 10507

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10450>
_______________________________________

From report at bugs.python.org  Mon Nov 22 17:34:42 2010
From: report at bugs.python.org (Doug Shea)
Date: Mon, 22 Nov 2010 16:34:42 +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: <1290443682.12.0.324249271039.issue9742@psf.upfronthosting.co.za>


Doug Shea <doug.shea at gmail.com> added the comment:

Certainly!

----------
Added file: http://bugs.python.org/file19773/pyconfig.h

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Mon Nov 22 17:39:25 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 22 Nov 2010 16:39:25 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1290440699.23.0.573707361738.issue10220@psf.upfronthosting.co.za>
Message-ID: <AANLkTimaT7xDe13kjK-3ZLy36Sc9XZ9M3LTLKb+m_fTb@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

Yes please.

On Mon, Nov 22, 2010 at 7:44 AM, Nick Coghlan <report at bugs.python.org> wrote:
>
> Nick Coghlan <ncoghlan at gmail.com> added the comment:
>
> Temporarily reopening to remind me to switch from using integer constants to strings (which are much friendlier for debugging purposes).
>
> ----------
> status: closed -> open
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10220>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Mon Nov 22 17:55:45 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Mon, 22 Nov 2010 16:55:45 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1290444945.23.0.663068521515.issue10087@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

I am attaching a new patch which fixes the majority of the comments raised.

1. Any suggestions about how to test the output of the console program (the case that this bug affects) would be appreciated.

2. Agreed, included in the output for --help

3. Agreed, included in new patch

4. Okay. That is because of using write vs print. Changed to always use write

5. Doesn't seem to cause any issues on windows terminal.

----------
Added file: http://bugs.python.org/file19774/calendar_bytes_output_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Mon Nov 22 18:14:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 17:14:34 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1290444945.23.0.663068521515.issue10087@psf.upfronthosting.co.za>
Message-ID: <AANLkTinxBzC8wrp3P-sWxSw0XgEt6XNEN_2K4B0o3ia2@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Nov 22, 2010 at 11:55 AM, Chris Lambacher
<report at bugs.python.org> wrote:
..
> 1. Any suggestions about how to test the output of the console program (the case that this bug affects)
> would be appreciated.

For month displays, a doctest may be most appropriate. See
Lib/test/test_syntax.py for one example of using doctests in regrtest
suite.  Note that sys.stdout being StringIO may present a challenge to
your approach.  You can also take a look at test_pydoc which also
tests console-oriented text and html output.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Mon Nov 22 18:24:30 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Mon, 22 Nov 2010 17:24:30 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1290446670.59.0.0655817055349.issue10087@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

The test_pydoc method looks workable, but I'll need to come back to it later because I don't have any more time to work on it today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Mon Nov 22 18:32:03 2010
From: report at bugs.python.org (Johann Hanne)
Date: Mon, 22 Nov 2010 17:32:03 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290447123.55.0.0819538910665.issue10504@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

Python 2.7 will currently not compile with MinGW for the outlined reasons.

* There are several "#if defined(_MSC_VER)" macros which surround Windows specific code/preprocessor fragments. But _MSC_VER is only defined with the Visual Studio compiler, not with gcc/MinGW. So the MS_WINDOWS define needs to be used for Windows specific code (and _MSC_VER only for compiler specific code).

* When cross-compiling on Unix with gcc/MinGW, the windows.h header is only found if it's written all lowercase due to Unix filesystems being case-sensitive.

* strcasecmp is a already defined by gcc/MinGW, so it must not be used for defining another function. The patch thus renames a function currently named strcasecmp to my_strcasecmp.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Mon Nov 22 18:33:47 2010
From: report at bugs.python.org (Johann Hanne)
Date: Mon, 22 Nov 2010 17:33:47 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290447227.33.0.30982679508.issue10504@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

> What's the objective of this patch? I.e. what precisely is it supposed to achieve?

So the answer is: It will fix compiling with gcc/MinGW by fixing the 3 issues described.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Mon Nov 22 19:21:32 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 22 Nov 2010 18:21:32 +0000
Subject: [issue10508] compiler warnings about formatting pid_t as an int
In-Reply-To: <1290450092.69.0.523269953177.issue10508@psf.upfronthosting.co.za>
Message-ID: <1290450092.69.0.523269953177.issue10508@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

In r85679 Greorg committed a trivial patch to avoid a compiler warning.

I request this (single line fix) to be backported to 2.7.

My argument is that 2.7 is going to be live for quite long, the fix is trivial, it is already in use in Py3k branch, and we would have a perfect clean buildbot report.

For instance: http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%202.7/builds/17/steps/compile/logs/warnings%20%281%29

I mark this as a release blocker to raise attention of the maintainer, since we are in release candidate already.

----------
assignee: georg.brandl
components: Extension Modules
keywords: easy
messages: 122152
nosy: georg.brandl, jcea
priority: release blocker
severity: normal
stage: commit review
status: open
title: compiler warnings about formatting pid_t as an int
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10508>
_______________________________________

From report at bugs.python.org  Mon Nov 22 19:37:12 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 22 Nov 2010 18:37:12 +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: <1290451032.87.0.502665724256.issue10509@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

If a non-ascii character is found and there isn't an encoding cookie, a SyntaxError is raised (in `decoding_fgets`) that includes the path of the file (using ``tok->filename``), but that path is never set. You can easily reproduce the crash by calling `imp.find_module("badsyntax")`, where "badsyntax" is a Python file containing a non-ascii character (see e.g. the attached unit test), as `find_module` uses `PyTokenizer_FindEncoding`. Note that Python 3.1 uses `snprintf()` for formatting the error message and some implementations of `snprintf()` explicitly check for null pointers, hence it might not crash.

One possible fix is to set ``tok->filename`` to something like "<unknown>". Attached is a patch which does that and adds an unit test for imp.

----------
components: Interpreter Core
messages: 122153
nosy: Trundle
priority: normal
severity: normal
status: open
title: PyTokenizer_FindEncoding can lead to a segfault if bad characters are found
type: crash
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10509>
_______________________________________

From report at bugs.python.org  Mon Nov 22 19:37:38 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 22 Nov 2010 18:37:38 +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: <1290451058.06.0.105498064986.issue10509@psf.upfronthosting.co.za>


Changes by Andreas St?hrk <andy-python at hammerhartes.de>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19775/PyTokenizer_FindEncoding_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10509>
_______________________________________

From report at bugs.python.org  Mon Nov 22 19:39:27 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 22 Nov 2010 18:39:27 +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: <1290451167.54.0.944328845126.issue10509@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +ezio.melotti
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10509>
_______________________________________

From report at bugs.python.org  Mon Nov 22 19:53:57 2010
From: report at bugs.python.org (Santoso Wijaya)
Date: Mon, 22 Nov 2010 18:53:57 +0000
Subject: [issue10506] argparse execute system exit in python prompt
In-Reply-To: <1290438923.5.0.695068609524.issue10506@psf.upfronthosting.co.za>
Message-ID: <1290452037.99.0.841552176126.issue10506@psf.upfronthosting.co.za>


Changes by Santoso Wijaya <santa.ant at me.com>:


----------
nosy: +santa4nt
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10506>
_______________________________________

From report at bugs.python.org  Mon Nov 22 19:55:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 22 Nov 2010 18:55:59 +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: <1290452159.78.0.533428019471.issue9742@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks.  I'm still stuck, though.  Since I'm pretty much at the wild guesses stage, here's one:

<wild idea> Perhaps the pymath.o object file isn't being included in the Python executable at all, because none of its functions are needed.  Now that doesn't seem to make sense, since the round function is needed, and used, in Objects/floatobject.c (that is, if PY_NO_SHORT_FLOAT_REPR is *not* defined;  I'm still not clear on whether that's the case or not---if you can get as far as launching an interpreter, then the result of sys.float_repr_style would be 'short' in that case).  But gcc (depending on the version, I guess) has builtin versions of some standard C library functions, including 'round'.  So if it were using the builtin then there would be no need to link to the pymath.o file, so it might be left out of the python executable.  But I'm not sure why the same doesn't happen when compiling the math module.

Neither am I sure how one might go about testing the above hypothesis.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Mon Nov 22 20:00:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 19:00:59 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <1290032414.97.0.560643505576.issue10435@psf.upfronthosting.co.za>
Message-ID: <AANLkTimkG=9x5h6HJU9Ri20j6SGLt6nh=6Pu0rKRswJ9@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Nov 17, 2010 at 5:20 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> -/* Encodes a Unicode object and returns the result as Python string
> +/* Encodes a Unicode object and returns the result as Python bytes
> ? ?object. */
>
>
> PyUnicode_AsEncodedObject() encodes the Unicode object to
> whatever the codec returns, so the "bytes" is wrong in the
> above line.
>

The above line describes PyUnicode_AsEncodedString(), not
PyUnicode_AsEncodedObject().  The former has PyBytes_Check(v) after
calling  v = PyCodec_Encode(..).  As far as I can tell this is the
only difference that makes PyUnicode_AsEncodedObject() not redundant.

..
> +.. c:function:: PyObject* PyUnicode_AsDecodedObject(PyObject *unicode, const char *encoding, const char *errors)
>
> + ? Create a Unicode object by decoding the encoded Unicode object
> + ? *unicode*.
>
> The function does not guarantee that a Unicode object will be
> returned. It merely passes a Unicode object to a codec's
> decode function and returns whatever the codec returns.
>

Good point.  I am changing "Unicode object" to "Python object".

..
> + ? Note that Python codecs do not accept Unicode objects for decoding,
> + ? so this method is only useful with user or 3rd party codecs.
>
> Please strike the last sentence. The codecs that were wrongly removed
> from Python3 will get added back and provide such functionality.
>

Would it be acceptable to keep this note, but add "as of version 3.2"
or something like that?   I don't think there is a chance that these
codecs will be added in 3.2 given the current schedule.

..
> This should read:
>
> ? Decodes a Unicode object by passing the given Unicode object
> ? *unicode* to the codec for *encoding*.
> ? *encoding* and *errors* have the same meaning as the
> ? parameters of the same name in the :func:`unicode` built-in
> ? function. ?The codec to be used is looked up using the Python codec
> ? registry. ?Return *NULL* if an exception was raised by the codec.
>

Is the following better?

"""
    Decodes a Unicode object by passing the given Unicode object
    *unicode* to the codec for *encoding*.  *encoding* and *errors*
    have the same meaning as the parameters of the same name in the
    :func:`unicode` built-in  function. The codec to be used is
    looked up using the Python codec registry. Return *NULL* if an
    exception was raised by the codec.

    As of Python 3.2, this method is only useful with user or 3rd
    party codec that encodes string into something other than bytes.
    For encoding to bytes, use c:func:`PyUnicode_AsEncodedString`
    instead.
"""
..
>
> +.. c:function:: void PyUnicode_Append(PyObject **pleft, PyObject *right)
..
> +
> +.. c:function:: void PyUnicode_AppendAndDel(PyObject **pleft, PyObject *right)
..
>
> Please don't document these two obscure APIs. Instead we should
> make them private functions by prepending them with an underscore.
> If you look at the implementations of those two APIs, they
> are little more than a macros around PyUnicode_Concat().
>

I don't agree that they are obscure.  Python uses them in multiple
places and developers seem to know about them.  See patches submitted
to issue4113 and issue7584.

> 3rd party extensions should use PyUnicode_Concat() to achieve
> the same effect.
>

Hmm.  I would not be surprised if current 3rd party extensions used
PyUnicode_AppendAndDel() more often than PyUnicode_Concat().  (I know
that I learned about PyUnicode_AppendAndDel()  before
PyUnicode_Concat().)

Is there anything that makes PyUnicode_AppendAndDel() undesirable?   I
don't mind adding a recommendation to use PyUnicode_Concat() if there
is a practical reason for it or even a warning that
PyUnicode_AppendAndDel() may be deprecated in the future, but renaming
it to _PyUnicode_AppendAndDel() seems premature.

..
>
> I don't think it's a good idea to make this a public API.
> 3rd party extensions should not need to make use of such
> APIs.
>
> Instead, we should make this a private API.

I agree, but isn't it prudent to document it as deprecated for 3rd
party use first?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Mon Nov 22 20:09:12 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 22 Nov 2010 19:09:12 +0000
Subject: [issue9095] patchcheck should handle extraneous whitespace in .rst
	files
In-Reply-To: <1277683188.13.0.698937807833.issue9095@psf.upfronthosting.co.za>
Message-ID: <1290452952.65.0.877019877874.issue9095@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Just ran it without issue after doing an `svn up`.

As for fix vs. not, while fixing indentations and removing trailing whitespace is nice, it isn't necessary. Both instances should be a rarity (most IDEs will make sure the situation doesn't occur), so the most important thing is detecting there is an issue for people to fix them (along with providing as much info as possible to make it easy to fix) rather than fixing it for them (if that turns out to be somewhat complicated to do).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9095>
_______________________________________

From report at bugs.python.org  Mon Nov 22 20:23:52 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 22 Nov 2010 19:23:52 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1290453832.54.0.164902159624.issue9807@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


Removed file: http://bugs.python.org/file19564/9807.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Mon Nov 22 20:24:35 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 22 Nov 2010 19:24:35 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1290453875.76.0.784477902368.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Here's an updated patch which address's Matthias's last concerns.

----------
Added file: http://bugs.python.org/file19776/9807.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Mon Nov 22 20:28:08 2010
From: report at bugs.python.org (SilentGhost)
Date: Mon, 22 Nov 2010 19:28:08 +0000
Subject: [issue6878] changed return type from tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1290454088.83.0.334651021559.issue6878@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

In my original post, I mentioned that it might be just a documentation issue. Could someone confirm that having map object returned is actually causing any problems?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________

From report at bugs.python.org  Mon Nov 22 20:29:21 2010
From: report at bugs.python.org (Doug Shea)
Date: Mon, 22 Nov 2010 19:29:21 +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: <1290454161.42.0.32315271433.issue9742@psf.upfronthosting.co.za>


Doug Shea <doug.shea at gmail.com> added the comment:

> ./python
Python 2.7 (r27:82500, Nov 22 2010, 10:06:14)
[GCC 3.3.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> print sys.float_repr_style
short

So it appears, if I follow you, that PY_NO_SHORT_FLOAT_REPR is not defined.

Glancing through the Makefile, pymath.o is included in the PYTHON_OBJS variable, which is in turn included in the LIBRARY_OBJS variable, which is used in all the libpython* targets.

I'm going to try to turn on some debugging on the commands that build those targets, and see if anything jumps out at me. Maybe it'll be obvious that pymath.o is being left out for one reason or another that'll sync up with your "wild guess". :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Mon Nov 22 20:49:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 19:49:53 +0000
Subject: [issue6878] changed return type from tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1290455393.89.0.315057726748.issue6878@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r86697 (3.2) and r86698 (3.1).

@?ric: I tried to minimize whitespace changes in the commit, but if you see indentation that can be improved, let me know and I'll fix it separately.

@SilentGhost: Yes, the problem is real.  For example, turtle module had to be fixed to work around the API change.  I now reverted that.  Note that 2to3 (I believe) fixes direct invocations of map, but cannot look inside the functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________

From report at bugs.python.org  Mon Nov 22 20:50:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 22 Nov 2010 19:50:51 +0000
Subject: [issue6878] changed return type from tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1290455451.65.0.934342130705.issue6878@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________

From report at bugs.python.org  Mon Nov 22 21:17:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Nov 2010 20:17:17 +0000
Subject: [issue10503] os.getuid() documentation should be clear on what kind
	of uid it is referring
In-Reply-To: <1290430871.92.0.135823537975.issue10503@psf.upfronthosting.co.za>
Message-ID: <1290457037.86.0.123665779257.issue10503@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

These are wrappers around the posix functions.  As such the unix man pages are a better authority than the Python docs :)  Still, we could certainly improve the docs.

The getlogin error is probably a miscopy from the man page: the man page on my system shows the example as  getpwuid(geteuid()), but it is actually showing a replacement for 'cuserid', not 'getlogin'.

----------
nosy: +r.david.murray
stage:  -> needs patch
type:  -> behavior
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10503>
_______________________________________

From report at bugs.python.org  Mon Nov 22 21:19:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Nov 2010 20:19:44 +0000
Subject: [issue10506] argparse execute system exit in python prompt
In-Reply-To: <1290438923.5.0.695068609524.issue10506@psf.upfronthosting.co.za>
Message-ID: <1290457184.84.0.628753399319.issue10506@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is working as designed.  Whether or not the design is correct has been debated in the past.  If you want to re-debate it the appropriate place is probably python-ideas.

----------
nosy: +bethard, r.david.murray
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10506>
_______________________________________

From report at bugs.python.org  Mon Nov 22 21:24:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Nov 2010 20:24:37 +0000
Subject: [issue10490] mimetypes read_windows_registry fails for non-ASCII keys
In-Reply-To: <1290348624.99.0.246792937165.issue10490@psf.upfronthosting.co.za>
Message-ID: <1290457477.07.0.239377081312.issue10490@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate if issue 9291.

----------
nosy: +r.david.murray
stage:  -> committed/rejected
status: open -> closed
superseder:  -> mimetypes initialization fails on Windows because of non-Latin characters in registry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10490>
_______________________________________

From report at bugs.python.org  Mon Nov 22 21:25:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 22 Nov 2010 20:25:22 +0000
Subject: [issue9291] mimetypes initialization fails on Windows because of
	non-Latin characters in registry
In-Reply-To: <1279454095.41.0.733053669611.issue9291@psf.upfronthosting.co.za>
Message-ID: <1290457522.25.0.994197851365.issue9291@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +aclover

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9291>
_______________________________________

From report at bugs.python.org  Mon Nov 22 21:31:31 2010
From: report at bugs.python.org (Daniel Tavares)
Date: Mon, 22 Nov 2010 20:31:31 +0000
Subject: [issue9162] License for multiprocessing files
In-Reply-To: <1278311687.0.0.315948028382.issue9162@psf.upfronthosting.co.za>
Message-ID: <1290457891.53.0.430525940334.issue9162@psf.upfronthosting.co.za>


Daniel Tavares <danielmtavares at gmail.com> added the comment:

Hi Jesse,

Any word from PSF board regarding this issue? I was hoping to fix it and have it be my 1st contribution to Python.

Thanks

----------
nosy: +dBugSlayer

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9162>
_______________________________________

From report at bugs.python.org  Mon Nov 22 21:37:42 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 22 Nov 2010 20:37:42 +0000
Subject: [issue10503] os.getuid() documentation should be clear on what kind
	of uid it is referring
In-Reply-To: <1290430871.92.0.135823537975.issue10503@psf.upfronthosting.co.za>
Message-ID: <1290458262.62.0.300975952487.issue10503@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Indeed, now that I google for "getlogin", it's not easy to figure out what kind of user it is supposed to return exactly.

For getuid() it seems pretty clear that we're talking about _real_ uid, though.
http://www.manpagez.com/man/2/getuid/
http://linux.die.net/man/2/getuid

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10503>
_______________________________________

From report at bugs.python.org  Mon Nov 22 21:44:15 2010
From: report at bugs.python.org (Max Arnold)
Date: Mon, 22 Nov 2010 20:44:15 +0000
Subject: [issue1647654] No obvious and correct way to get the time zone offset
Message-ID: <1290458655.49.0.232705165027.issue1647654@psf.upfronthosting.co.za>


Max Arnold <lwarxx at gmail.com> added the comment:

Our region recently switched to another timezone and I've noticed similar issue while using Mercurial. There is some (hopefully) useful details: http://mercurial.selenic.com/bts/issue2511

----------
nosy: +LwarX

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647654>
_______________________________________

From report at bugs.python.org  Mon Nov 22 21:47:39 2010
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 22 Nov 2010 20:47:39 +0000
Subject: [issue9162] License for multiprocessing files
In-Reply-To: <1278311687.0.0.315948028382.issue9162@psf.upfronthosting.co.za>
Message-ID: <1290458859.93.0.228124894393.issue9162@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

We have to add the BSD header and maintain the copyright clause on all of the multiprocessing files. Apologies for the delay

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9162>
_______________________________________

From report at bugs.python.org  Mon Nov 22 22:33:00 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 22 Nov 2010 21:33:00 +0000
Subject: [issue9095] patchcheck should handle extraneous whitespace in .rst
	files
In-Reply-To: <1277683188.13.0.698937807833.issue9095@psf.upfronthosting.co.za>
Message-ID: <1290461580.53.0.654993791346.issue9095@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

patchcheck.py is not so complicated; why don't you debug that hangup yourself?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9095>
_______________________________________

From report at bugs.python.org  Mon Nov 22 22:52:40 2010
From: report at bugs.python.org (Doug Shea)
Date: Mon, 22 Nov 2010 21:52:40 +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: <1290462760.66.0.661815732093.issue9742@psf.upfronthosting.co.za>


Doug Shea <doug.shea at gmail.com> added the comment:

I don't think there's anything wrong with the setup we've been looking at so far, per se. The libpython2.7.a file produced has the 'round' function like it should:

> nm libpython2.7.a | grep round
[116] |      1360|     696|FUNC |GLOB |0    |2      |_Py_double_round
[218] |         0|       0|NOTY |GLOB |0    |UNDEF  |_Py_double_round
[10] |     15268|     236|FUNC |LOCL |0    |2      |builtin_round
[48] |      9912|     198|OBJT |LOCL |0    |4      |round_doc
[8] |         0|      96|FUNC |GLOB |0    |2      |round

However, the python executable itself, compiled against that archive, does *not* have it:

> nm python | grep round
[4805] |    244408|     696|FUNC |GLOB |0    |9      |_Py_double_round
[1735] |    640836|     236|FUNC |LOCL |0    |9      |builtin_round
[1770] |   1533576|     198|OBJT |LOCL |0    |16     |round_doc

So, for some reason, the gcc command that builds that python executable is leaving it out:

gcc -o python \
       Modules/python.o \
       libpython2.7.a -lresolv -lsocket -lnsl -lrt -ldl -lpthread -lm

Just an update. Going to try to debug that command and see if I can find out why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Mon Nov 22 22:59:38 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 22 Nov 2010 21:59:38 +0000
Subject: [issue9263] Try to print repr() when an C-level assert fails (in the
	garbage collector, beyond?)
In-Reply-To: <1279151450.93.0.973335817084.issue9263@psf.upfronthosting.co.za>
Message-ID: <1290463178.01.0.324470380811.issue9263@psf.upfronthosting.co.za>


Changes by Dave Malcolm <dmalcolm at redhat.com>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9263>
_______________________________________

From report at bugs.python.org  Mon Nov 22 23:13:25 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 22 Nov 2010 22:13:25 +0000
Subject: [issue9263] Try to print repr() when an C-level assert fails (in the
	garbage collector, beyond?)
In-Reply-To: <1279151450.93.0.973335817084.issue9263@psf.upfronthosting.co.za>
Message-ID: <1290464005.72.0.615150828252.issue9263@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Attaching a simplified version of the patch; I got rid of the callbacks.

Still doesn't have test cases.

I suspect that the use of __STRING and __PRETTY_FUNCTION__ may be compatibility issues.  I believe that __FILE__ and __LINE__ and standard C though.

----------
Added file: http://bugs.python.org/file19777/py3k-objdump-on-gcmodule-assertions-2010-11-22-001.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9263>
_______________________________________

From report at bugs.python.org  Mon Nov 22 23:16:18 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 22 Nov 2010 22:16:18 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290464178.92.0.142324688907.issue10504@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/issue10504>
_______________________________________

From report at bugs.python.org  Mon Nov 22 23:30:30 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Mon, 22 Nov 2010 22:30:30 +0000
Subject: [issue6166] encoding error for 'setup.py --author' when read via
	subprocess pipe
In-Reply-To: <1243881147.82.0.337721955444.issue6166@psf.upfronthosting.co.za>
Message-ID: <1290465030.86.0.0436015641983.issue6166@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

"PYTHONIOENCODING=UTF-8 python test2.py" does work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6166>
_______________________________________

From report at bugs.python.org  Mon Nov 22 23:34:30 2010
From: report at bugs.python.org (Martin)
Date: Mon, 22 Nov 2010 22:34:30 +0000
Subject: [issue10501] make_buildinfo regression with unquoted path
In-Reply-To: <1290420103.87.0.191839202946.issue10501@psf.upfronthosting.co.za>
Message-ID: <1290465270.42.0.484477391484.issue10501@psf.upfronthosting.co.za>


Martin <gzlist at googlemail.com> added the comment:

Thanks. Don't actually need to quote the whole path, but what you've landed works for me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10501>
_______________________________________

From report at bugs.python.org  Mon Nov 22 23:36:07 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 22 Nov 2010 22:36:07 +0000
Subject: [issue10437] ThreadPoolExecutor should accept max_workers=None
In-Reply-To: <1289936174.35.0.332227808259.issue10437@psf.upfronthosting.co.za>
Message-ID: <1290465367.28.0.924216257935.issue10437@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Amaury Forgeot d'Arc said:
> pypy does have a GIL!

D'oh.  That shows you how much I know about PyPy.  Make that "keep in mind that IronPython doesn't have a GIL". ;)

Brian Quinlan said:
> I think that using the number of CPUs for max_workers makes sense
> for you but won't for most users. So I wouldn't make it a default.

Fair enough.  Marking as invalid.

----------
resolution:  -> invalid
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10437>
_______________________________________

From report at bugs.python.org  Mon Nov 22 23:42:48 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 22 Nov 2010 22:42:48 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290465768.67.0.860290890585.issue10504@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I doubt this fix will be enough to fix compilation with mingw32.
But IMO it goes in the right direction.

With this patch, "#ifdef MS_WINDOWS" has the meaning of "linked with some version of MSVCRT".  Do we agree on this, or is another symbol necessary?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Tue Nov 23 00:12:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 22 Nov 2010 23:12:56 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290465768.67.0.860290890585.issue10504@psf.upfronthosting.co.za>
Message-ID: <4CEAF8F5.1020101@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I doubt this fix will be enough to fix compilation with mingw32.

So somebody will have to verify independently. If it fails to fix
the bug completely, it's out of scope for 2.7 (it's out of scope for
2.7.1 IMO either way).

> With this patch, "#ifdef MS_WINDOWS" has the meaning of "linked with
> some version of MSVCRT". Do we agree on this, or is another symbol
> necessary?

MS_WINDOWS is defined as

MS_WINDOWS - Code specific to Windows, but all versions.

So it does *not* imply "MSVCRT". Introducing a new preprocessor symbol
is also out of scope for 2.7, so if we mean "MSC or mingw", we need
to spell that out (i.e. defined(_MSC_VER) || defined(__MINGW32__)).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Tue Nov 23 00:13:36 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 22 Nov 2010 23:13:36 +0000
Subject: [issue9846] ZipExtFile provides no mechanism for closing the
	underlying file object
In-Reply-To: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>
Message-ID: <1290467616.24.0.0567068924124.issue9846@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Adding a patch implementing the discussed functionality, removing almost all of the ResourceWarnings raised by zipfile.

----------
keywords: +patch
nosy: +lukasz.langa
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19778/issue9846.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9846>
_______________________________________

From report at bugs.python.org  Tue Nov 23 00:35:03 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Mon, 22 Nov 2010 23:35:03 +0000
Subject: [issue9846] ZipExtFile provides no mechanism for closing the
	underlying file object
In-Reply-To: <1284394640.99.0.715812735205.issue9846@psf.upfronthosting.co.za>
Message-ID: <1290468903.86.0.412017329545.issue9846@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Committed in rev 86699.

----------
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9846>
_______________________________________

From report at bugs.python.org  Tue Nov 23 00:50:39 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 22 Nov 2010 23:50:39 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290469839.91.0.969730471514.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

I'm starting to get settled in here at Google and finding time to follow up on everything that got put on hold while moving.

Based on the feedback everyone gave me (thanks!), I greatly revised my script for comparing the speed of sort().  It's now compares speeds more quickly and more accurately.  I discovered a few things along the way:

1) Don't try to run timings on a virtual server with crummy clock resolution.

2) Make sure that CPU frequency scaling is turned off.  It increases the standard deviation of timings by an order of magnitude or two.

On Linux systems, the new version of my script will check to see if CPU frequency scaling is turned on and provide suggestions on how to turn it off.  On other operating systems, you are on your own. ;)

Usage:
filfre:~/py3k-patched$ ./python Tools/sort_speed/sort_speed.py -r 3 --maxn 100000 ../py3k-pristine . sort_random

Using my new-and-improved timing script and running on real hardware with CPU frequency scaling turned off, I was able to detect a slight slowdown on sorting random integers.  Here's a summary for sorting random integers:

Original patch (increasing execution time is bad):
n in [700 .. 100,000]: 1% to 2% increase in execution time
n in [70 to 700]: 2% to 3% increase
n in [10 to 70]: 3% to 4% increase
n in [5 to 7]: 7% to 9% decrease
n in [0 to 3]: 18+% decrease

I went back to the code and managed to squeeze out a bit more performance.  Here's a summary of the new patch:

New patch (increasing execution time is bad):
n in [30,000 .. 100,000]: < 1% increase in execution time
n in [35 .. 30,000]: 1% to 2% increase
n in [20 .. 35]: about the same
n in [10 .. 20]: 1 to 2% decrease
n in [4 .. 7]: 15+% decrease
n in [0 .. 3]: 22+% decrease

All of the above results are for sorting without a key.  For sorting *with* a key, there's a big performance boost across the board (15% to 45% decrease in execution time, when the key function is simply "int").

Overall, the patch shrinks Objects/listobject.c by 10 lines.

Executive Summary
-----------------

Good:
- Dramatically cuts execution time of sorting with a key (15% to 45%)
- Significantly cuts execution time of sorting small lists without a key (15+%)

Bad:
- Very slightly increases execution of sorting large lists without a key (1% to 2%; less than 1% for very large lists)

Worthwhile trade?

----------
Added file: http://bugs.python.org/file19779/sort-speed-test.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 00:51:08 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 22 Nov 2010 23:51:08 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290469868.79.0.0896010124947.issue9915@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


Added file: http://bugs.python.org/file19780/sort-faster.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 00:52:10 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 22 Nov 2010 23:52:10 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290469930.92.0.0161301016909.issue9915@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <stutzbach at google.com>:


Added file: http://bugs.python.org/file19781/detailed-speed-results.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 00:58:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 22 Nov 2010 23:58:29 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290470309.39.0.9554274513.issue9915@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Worthwhile trade?

+1 obviously.

Why don't you contribute a list sorting benchmark to the suite in http://hg.python.org/benchmarks/?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 00:59:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 22 Nov 2010 23:59:52 +0000
Subject: [issue1676121] Problem linking to readline lib on x86(64) Solaris
Message-ID: <1290470392.19.0.843196445221.issue1676121@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
superseder: documentation for new SSL module -> readline configuration for shared libs w/o curses dependencies

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1676121>
_______________________________________

From report at bugs.python.org  Tue Nov 23 01:10:47 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 23 Nov 2010 00:10:47 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290471047.36.0.434523282977.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> Why don't you contribute a list sorting benchmark to the suite in http://hg.python.org/benchmarks/?

I considered that, but I want to separately benchmark sorting different kinds and quantities of data.  AFAIK, there isn't an easy way to do that with perf.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 01:12:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Nov 2010 00:12:00 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1290471047.36.0.434523282977.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290471109.3566.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le mardi 23 novembre 2010 ? 00:10 +0000, Daniel Stutzbach a ?crit :
> Daniel Stutzbach <stutzbach at google.com> added the comment:
> 
> Antoine Pitrou <report at bugs.python.org> wrote:
> > Why don't you contribute a list sorting benchmark to the suite in http://hg.python.org/benchmarks/?
> 
> I considered that, but I want to separately benchmark sorting
> different kinds and quantities of data.  AFAIK, there isn't an easy
> way to do that with perf.py.

Right, that wouldn't suit your present purposes. But apparently you are
proposing to add a list sorting benchmark to the Tools directory, with
lots of duplicated code from that repo...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 01:23:33 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 23 Nov 2010 00:23:33 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290471813.38.0.574204387061.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Antoine Pitrou <report at bugs.python.org> wrote:
> Right, that wouldn't suit your present purposes. But apparently you 
> are proposing to add a list sorting benchmark to the Tools directory,
> with lots of duplicated code from that repo...

Oh, I just stuck that under Tools because it was convenient for testing.  The timing script is in a separate patch because I'm -0 on committing the timing script itself.

The perf.py that my timing script uses is based on the one from benchmarks/, but with 90% of the code removed, so the amount of duplicated code is less than it may at first appear.

My script could go in benchmarks/ if there was a convenient way for it to import perf.py.  I wouldn't want to clutter the top-level directory with my script though.  Any suggestions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 02:16:40 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Nov 2010 01:16:40 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290475000.98.0.110170769958.issue9915@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the revisions and timing updates.  I'm heartened that the common-case of sorting without a key function isn't negatively impacted.  That result is surprising though -- I thought the concept was manipulate the key and value arrays at the same time instead of just the keys -- did you do more than this, perhaps changing the logic or pattern of comparisons?  If so, I would be *much* more comfortable if Tim reviewed this.

The one part of the current code that would be missed is that it cleanly separates/decouples the key-function logic from the Timsort logic.  Now those are heavily intertwined -- I find the code harder to follow.

Why did the variable names change, pa/pb to ssa/ssb, etc.?

I'm hoping that I'll have a chance to go through the details of the patch in the next couple of weeks.  Unfortunately, the patch is huge and it looks like it mixes in a number of optimizations beyond just moving keys and values in parallel, variable names are changing, comment lines are rewrapped, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 02:26:06 2010
From: report at bugs.python.org (Ron Adam)
Date: Tue, 23 Nov 2010 01:26:06 +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: <1290475566.95.0.791171442484.issue10509@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Is this a duplicate of issue 9319?

----------
nosy: +ron_adam

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10509>
_______________________________________

From report at bugs.python.org  Tue Nov 23 02:45:47 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 23 Nov 2010 01:45:47 +0000
Subject: [issue10501] make_buildinfo regression with unquoted path
In-Reply-To: <1290420103.87.0.191839202946.issue10501@psf.upfronthosting.co.za>
Message-ID: <1290476747.55.0.847313683184.issue10501@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I did various tests and quoting parts of the path seemed fragile, especially if the quote landed next to a backslash.  This is dangerous ground :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10501>
_______________________________________

From report at bugs.python.org  Tue Nov 23 02:53:31 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 23 Nov 2010 01:53:31 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290477211.88.0.0233980966681.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
> That result is surprising though -- I thought the concept was
> manipulate the key and value arrays at the same time instead of just
> the keys

If the "key" parameter was not used, then the values pointer is a null pointer.  Each time elements must be moved, the code needs to check if the values pointer is NULL.  In other words, the overhead is one conditional branch per move or group of moves (we only have to check once for memmove()).

Since the branch will always be the same throughout any given call to sort(), CPU branch prediction is effective making the branches fairly inexpensive.

> -- did you do more than this, perhaps changing the logic or
> pattern of comparisons?

In the original version of the patch, I tried hard to avoid unrelated changes.  

In the new version, I made many small not-strictly-related optimizations.  However, I have not changed the order in which comparisons occur.

> Why did the variable names change, pa/pb to ssa/ssb, etc.?

I took "pa" to mean "pointer to array A", but it's now a sortslice structure instead of a pointer.

> comment lines are rewrapped

The comment rewrapping aren't completely spurious.  The comments really have changed and in some cases the constraints on the inputs to a function have changed slightly.

For what it's worth, my methodology when working on this patch went like this:
1) Make an improvement
2) Measure the performance relative to the previous reference point
3) If it was a statistically significant an improvement, commit the change to my local DVCS
4) Goto 1

I can upload the patch to Rietveld to facilitate review.

If I can get Rietveld to show each of my local commits, would it be helpful to see the patch in incremental pieces?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 03:12:13 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Nov 2010 02:12:13 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290478333.95.0.29705999518.issue9915@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> If the "key" parameter was not used, then the values pointer 
> is a null pointer. 
  . . .
> Since the branch will always be the same throughout any given 
> call to sort(), CPU branch prediction is effective making the
> branches fairly inexpensive.

I see how the branch can be optimized away but not how it gets cheaper than when there was no branch at all (and no lo.keys and lo.values extra layer of direction).  How did it get *faster* than the original (in the case with no key-function)?

>> Why did the variable names change, pa/pb to ssa/ssb, etc.?
> I took "pa" to mean "pointer to array A", but it's now 
> a sortslice structure instead of a pointer.

That makes sense.

> If I can get Rietveld to show each of my local commits,
> would it be helpful to see the patch in incremental pieces?

At this point, it may be best for me to read the patch as-is.  Unfortunately, it's a big patch and will likely take a lot of time to read in detail.

Is there any chance you can persuade Uncle Timmy to review this?  This is all his code and he's likely to have some good insights.

Also, is there anyone else who is knowledgeable about Python on less common platforms?  ISTM part of the optimization is dependent on the branch-prediction and other nuances that vary from environment to environment.  That being said, doing fewer memory allocations is always a win.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 03:16:56 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 23 Nov 2010 02:16:56 +0000
Subject: [issue10508] compiler warnings about formatting pid_t as an int
In-Reply-To: <1290450092.69.0.523269953177.issue10508@psf.upfronthosting.co.za>
Message-ID: <1290478616.47.0.397099432624.issue10508@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Python 3.1 affected also.

----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10508>
_______________________________________

From report at bugs.python.org  Tue Nov 23 03:31:35 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 23 Nov 2010 02:31:35 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290479495.3.0.497436556145.issue1859@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I'd be interested in having a go if I knew what the desired behaviour was, ie unit tests to confirm what was 'correct'.

How should it handle line breaks? Should it treat them like any other whitespace as at present, should it honour them, or should it get another option, eg 'honor_breaks' (if US spelling is the standard for Python's libraries)?

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Tue Nov 23 04:50:07 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 23 Nov 2010 03:50:07 +0000
Subject: [issue9852] test_ctypes fail with clang
In-Reply-To: <1284465948.07.0.835658917717.issue9852@psf.upfronthosting.co.za>
Message-ID: <1290484207.29.0.365162595685.issue9852@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9852>
_______________________________________

From report at bugs.python.org  Tue Nov 23 04:50:50 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 23 Nov 2010 03:50:50 +0000
Subject: [issue10238] ctypes not building under OS X 10.6 with LLVM/Clang 2.8
In-Reply-To: <1288391275.39.0.918201255477.issue10238@psf.upfronthosting.co.za>
Message-ID: <1290484250.48.0.63406895866.issue10238@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10238>
_______________________________________

From report at bugs.python.org  Tue Nov 23 04:51:44 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 23 Nov 2010 03:51:44 +0000
Subject: [issue8914] Run clang's static analyzer
In-Reply-To: <1275795174.58.0.536949662024.issue8914@psf.upfronthosting.co.za>
Message-ID: <1290484304.06.0.206693617925.issue8914@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8914>
_______________________________________

From report at bugs.python.org  Tue Nov 23 05:32:03 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 23 Nov 2010 04:32:03 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290486723.59.0.572735356409.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

> How did it get *faster* than the original (in the case with no 
> key-function)?

I was able to shave off some instructions in countrun(), binarysort(), and the setup and cleanup code in listsort() proper.  For small n, these made a difference.

> Is there any chance you can persuade Uncle Timmy to review this?  This
> is all his code and he's likely to have some good insights.

Any suggestions on how he might be persuaded? ;-)

> Also, is there anyone else who is knowledgeable about Python on less
> common platforms?  ISTM part of the optimization is dependent on the
> branch-prediction and other nuances that vary from environment to
> environment.  That being said, doing fewer memory allocations is
> always a win.

I do have a Windows machine I can test on.  It's not exactly a "less common" platform, but at least it's a completely different compiler.  I'll post the results once I have them.


The Rietveld issue is here:
http://codereview.appspot.com/3269041

I ended up loading my incremental patches in, but it's easy enough to diff the base with the last patch.  If for some reasons it doesn't work as conveniently as I expect, let me know and I will upload it to Rietveld again as one big patch.

If there's anything else I can do to make reviewing easier, please let me know.  For that matter, if there's other code you'd like me to review in exchange or straightforward bugs you'd like to pawn off, I would be happy to help out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 05:36:09 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Tue, 23 Nov 2010 04:36:09 +0000
Subject: [issue10498] calendar.LocaleHTMLCalendar.formatyearpage() results in
	traceback with 'unsupported locale setting' on Windows
In-Reply-To: <1290393306.69.0.998081430395.issue10498@psf.upfronthosting.co.za>
Message-ID: <1290486969.78.0.0746542501847.issue10498@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


----------
nosy: +ruseel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10498>
_______________________________________

From report at bugs.python.org  Tue Nov 23 05:39:56 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Tue, 23 Nov 2010 04:39:56 +0000
Subject: [issue1508475] transparent gzip compression in urllib
Message-ID: <1290487196.9.0.766460505456.issue1508475@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


----------
nosy: +ruseel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1508475>
_______________________________________

From report at bugs.python.org  Tue Nov 23 06:03:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 23 Nov 2010 05:03:16 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1290488596.66.0.0130358932994.issue10087@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I wonder: do we really need "encoding" option to the calendar output?  It is really not the job of the calendar module to deal with encodings.  The calendar module should produce text calendars as unicode strings and HTML calendars as UTF-8 bytes.  If someone wants to save them in a specific encoding, there are plenty of ways to achieve that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Tue Nov 23 06:11:54 2010
From: report at bugs.python.org (Brian Jones)
Date: Tue, 23 Nov 2010 05:11:54 +0000
Subject: [issue10510] distutils.command.upload/register HTTP message headers:
	bad line termination
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>


New submission from Brian Jones <bkjones at gmail.com>:

In trying to write a PyPI service, I of course need to support the registration and upload features of setup.py, which uses distutils for those actions. One thing making this a bit more difficult than need be is the fact that distutils.command.register and distutils.command.upload both use bare line feeds as a line terminator in the HTTP message headers. While there are probably tolerant servers out there, I think this behavior should be considered a bug in light of the HTTP spec, which reads: 

"The line terminator for message-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR."

The second sentence can be interpreted in multiple ways that either agree with or contradict the first sentence, but the first sentence is at least perfectly clear, and I'd like to see "\r\n" added to the beginning of (specifically in this case) the Content-Disposition headers assembled by distutils.command.upload and distutils.command.register.  

The change involves taking identical lines in each file that currently look like this: 


           title = '\nContent-Disposition: form-data; name="%s"' % key

...and making them look like this: 


           title = '\r\nContent-Disposition: form-data; name="%s"' % key

The result is that servers which do not support a lax adherence to the protocol will still be able to support users of distutils in Python 2.6, 2.7, and 3.1 (and maybe others).

----------
messages: 122192
nosy: Brian.Jones
priority: normal
severity: normal
status: open
title: distutils.command.upload/register HTTP message headers: bad line termination
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Tue Nov 23 06:34:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 23 Nov 2010 05:34:29 +0000
Subject: [issue8525] Display exception's subclasses in help()
In-Reply-To: <1272150602.3.0.323796636819.issue8525@psf.upfronthosting.co.za>
Message-ID: <1290490469.43.0.24195081406.issue8525@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The proposal is to display builtin subclasses as for example:

>>> help(ArithmeticError)
class ArithmeticError(Exception)
 |  Base class for arithmetic errors.
 |  
 |  Method resolution order:
 |      ArithmeticError
 |      Exception
 |      BaseException
 |      object
 |  
 |  Built-in subclasses:
 |      FloatingPointError
 |      OverflowError
 |      ZeroDivisionError

Note that this really affects only exceptions because no other builtin class has builtin subclasses.  (dict has subclasses in collections, but not in builtins.)

Exception hierarchy is presented in the reference manual at

http://docs.python.org/dev/library/exceptions.html?#exception-hierarchy

I wonder if rather than having MRO and subclasses sections, we should just present a portion of the exception hierarchy including the given exception, all its bases and direct subclasses:

object
 |
BaseException
 |
Exception
 |
*ArithmeticError*
 |
 +-- FloatingPointError
 +-- OverflowError
 +-- ZeroDivisionError

----------
title: Small enhancement to help() -> Display exception's subclasses in help()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8525>
_______________________________________

From report at bugs.python.org  Tue Nov 23 07:49:17 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Nov 2010 06:49:17 +0000
Subject: [issue9222] IDLE: Fix open/saveas 'Files of type' choices
In-Reply-To: <1278809052.13.0.969100167059.issue9222@psf.upfronthosting.co.za>
Message-ID: <1290494957.7.0.331242371635.issue9222@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.2, 3.1, 2.7: r86702, r86703, r86704

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9222>
_______________________________________

From report at bugs.python.org  Tue Nov 23 07:53:50 2010
From: report at bugs.python.org (Johann Hanne)
Date: Tue, 23 Nov 2010 06:53:50 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290495230.54.0.590383325337.issue10504@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

I've revised the patch to use "defined(_MSC_VER) || defined(__MINGW32__)" as suggested.

And no, it does not solve all mingw compilition issues, but most of them. I've tried to only address the most obvious ones, which are *very* unlikely to break anything.

I have Python 2.7 completely compiling with MinGW (and even major parts of pywin32), but that requires some small changes to MinGW, too. I've also already started to submitting patches to the MinGW project.

Please give me some starting point by applying these patches. I don't care if it's for 2.7.1 or 2.7.2. I'll try hard to get *everything* fixed, but we have to start somewhere.

----------
Added file: http://bugs.python.org/file19782/Python-2.7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Tue Nov 23 07:59:59 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Nov 2010 06:59:59 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290495599.55.0.602889982731.issue1859@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Georg, if your comment means that you think that the doc patch is ready to apply, as is, without testing with a doc build, then I will do so for all 3 versions.

Should there really be two blank lines after the note?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Tue Nov 23 08:07:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 23 Nov 2010 07:07:55 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290495230.54.0.590383325337.issue10504@psf.upfronthosting.co.za>
Message-ID: <4CEB6848.9080105@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Please give me some starting point by applying these patches. I don't
> care if it's for 2.7.1 or 2.7.2. I'll try hard to get *everything*
> fixed, but we have to start somewhere.

I'm skeptical that we should do that with 2.7, then. So it would be
better to target 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Tue Nov 23 08:23:31 2010
From: report at bugs.python.org (Johann Hanne)
Date: Tue, 23 Nov 2010 07:23:31 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290497011.78.0.698724178551.issue10504@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

Why exactly are you skeptical? Because it doesn't fix everything in one go? The other changes are also minimal (I'm not even sure if it requires more source changes, maybe I have just to get my #defines right). If you prefer to see a single patch which you can reproduce to fix MinGW compilation completely, I'm willing to do that.

Given that 2.7 is supposed to be a long time support version, I really think people should have a chance to use MinGW. The patch is trivial, but figuring out everything from the compiler error messages can be brain bending.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Tue Nov 23 08:46:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Nov 2010 07:46:25 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290498385.94.0.0321210141462.issue10504@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Since the patch does not completely fix the mingw32 build, I suggest to apply it only on 3.2, and continue to work on mingw32 support there.

Only after we will be able to discuss whether all the changes can be backported to 2.7, provided that they fix the mingw32 build.

2.7 is in maintenance mode, and should not accept a change that only gives progress to a larger development process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Tue Nov 23 08:50:28 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 23 Nov 2010 07:50:28 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290498628.18.0.591053433752.issue1859@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, please do apply.  You don't need to run a doc build for every small change; of course it is nice if you do, but errors will be caught by the daily build routine anyway and mailed to me.

As for the two blank lines: you'll see that the original conversion from LaTeX produced two blank lines after each description (function, class, ...), and I find this to be a little more readable than only one blank line, especially when the descriptions are longer; for short descriptions leaving only one blank line saves space.  Syntactically, both are fully equivalent.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Tue Nov 23 08:54:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 23 Nov 2010 07:54:36 +0000
Subject: [issue10468] Document UnicodeError access functions
In-Reply-To: <1290260862.46.0.923226351306.issue10468@psf.upfronthosting.co.za>
Message-ID: <1290498876.21.0.974421677887.issue10468@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, reviewed and applied in r86705.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10468>
_______________________________________

From report at bugs.python.org  Tue Nov 23 09:00:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 23 Nov 2010 08:00:57 +0000
Subject: [issue10508] compiler warnings about formatting pid_t as an int
In-Reply-To: <1290450092.69.0.523269953177.issue10508@psf.upfronthosting.co.za>
Message-ID: <1290499257.46.0.494245164041.issue10508@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, I can't see a problem with it.  Backported in r86706, r86707.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10508>
_______________________________________

From report at bugs.python.org  Tue Nov 23 09:10:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 23 Nov 2010 08:10:11 +0000
Subject: [issue10511] heapq docs clarification
In-Reply-To: <1290499811.48.0.151604893048.issue10511@psf.upfronthosting.co.za>
Message-ID: <1290499811.48.0.151604893048.issue10511@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

On the python-docs mailing list, a user suggested to rewrite the first paragraph of the heapq docs like this.  Are you okay with this change, Raymond?


Heaps are trees for which every parent node has a value less than or equal to
any of its children.  This implementation uses arrays for which ``heap[k] <=
heap[2*k+1]`` and ``heap[k] <= heap[2*k+2]`` for all *k*, counting elements from
zero.  For the sake of comparison, non-existing elements are considered to be
infinite.  The interesting property of a heap is that its smallest element is
always the root, ``heap[0]``.

----------
assignee: rhettinger
messages: 122203
nosy: georg.brandl, rhettinger
priority: normal
severity: normal
status: open
title: heapq docs clarification

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10511>
_______________________________________

From report at bugs.python.org  Tue Nov 23 09:16:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 23 Nov 2010 08:16:04 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290497011.78.0.698724178551.issue10504@psf.upfronthosting.co.za>
Message-ID: <4CEB7841.6060004@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Why exactly are you skeptical? Because it doesn't fix everything in
> one go? The other changes are also minimal (I'm not even sure if it
> requires more source changes, maybe I have just to get my #defines
> right). If you prefer to see a single patch which you can reproduce
> to fix MinGW compilation completely, I'm willing to do that.

Only bug fixes are acceptable for the 2.7 branch. If this *doesn't*
actually fix the bug (i.e. allows building Python with mingw), then
it's not a bug fix. Mere "improvements" are not acceptable for that
branch.

We have a long tradition of people proposing patches "we need this
and that code to support this and that platform". Then, right after
applying the patch, they come back with more patches, and after
that with more patches. I can accept this for the trunk if it doesn't
break anything, but not for a maintenance branch. The objective should
be to have the minimal necessary amount of changes that just address
the goal of the maintenance branch (i.e. fixes). Work in progress
doesn't belong here (some will argue that work in progress doesn't
even belong to the trunk, but should be carried out in a separate
branch).

> Given that 2.7 is supposed to be a long time support version, I
> really think people should have a chance to use MinGW. The patch is
> trivial, but figuring out everything from the compiler error messages
> can be brain bending.

If this bug (which, unfortunately, hasn't been identified clearly,
either) ever gets fixed, I'm open for backporting it (with the
release manager's approval - it could also be considered as a new
feature - port to mingw - in which case it also would be out of
scope).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Tue Nov 23 09:24:41 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 23 Nov 2010 08:24:41 +0000
Subject: [issue10511] heapq docs clarification
In-Reply-To: <1290499811.48.0.151604893048.issue10511@psf.upfronthosting.co.za>
Message-ID: <1290500681.84.0.72306966517.issue10511@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

That looks fine.  Perhaps s/trees/binary trees

----------
assignee: rhettinger -> georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10511>
_______________________________________

From report at bugs.python.org  Tue Nov 23 09:38:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 23 Nov 2010 08:38:11 +0000
Subject: [issue10511] heapq docs clarification
In-Reply-To: <1290499811.48.0.151604893048.issue10511@psf.upfronthosting.co.za>
Message-ID: <1290501491.23.0.466915004588.issue10511@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Great!  Applied in r86708.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10511>
_______________________________________

From report at bugs.python.org  Tue Nov 23 09:47:23 2010
From: report at bugs.python.org (Johann Hanne)
Date: Tue, 23 Nov 2010 08:47:23 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290502043.22.0.743965592912.issue10504@psf.upfronthosting.co.za>


Johann Hanne <python at jf.hanne.name> added the comment:

Well... ok. Although I already regard the patch as a strict bugfix (it fixes compilation of some C modules on MinGW), I'll go forward and create a patch for Python 3.2 which fixes compilation of all C modules on MinGW (all which are supposed to work on Win32 that is).

I assume once I've shown that the patch still mostly consists of some preprocessor fixes, it will have a fair chance of being applied in 2.7. If somebody knows that there is *no* chance, please speak *now* so I can just stop trying to make something that already works for me available to everybody.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Tue Nov 23 10:51:54 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Tue, 23 Nov 2010 09:51:54 +0000
Subject: [issue10483] http.server - what is executable on Windows
In-Reply-To: <1290324390.55.0.445837984524.issue10483@psf.upfronthosting.co.za>
Message-ID: <1290505914.43.0.597315955076.issue10483@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Martin, you are splitting hairs about the "reported problem".  The original message does have a paragraph about the executable bits being wrong.  But the bulk of the message is commenting about the difficulty of figuring out what to replace it with.

So it looks like in spite of the hair splitting, we have iterated to a design of making run_cgi a bit friendlier in this regard.

I find it sufficient to define a method fully extracted from run_cgi as follows:

    def make_cmdline( self, scriptfile, query ):
        cmdline = [scriptfile]
        if self.is_python(scriptfile):
            interp = sys.executable
            if interp.lower().endswith("w.exe"):
                # On Windows, use python.exe, not pythonw.exe
                interp = interp[:-5] + interp[-4:]
            cmdline = [interp, '-u'] + cmdline
        if '=' not in query:
            cmdline.append(query)

This leaves run_cgi with:

            import subprocess
            cmdline = self.make_cmdline( scriptfile, query )
            self.log_message("command: %s", subprocess.list2cmdline(cmdline))


Apologies: I don't know what format of patch is acceptable, but this is a simple cut-n-paste change.  I was sort of holding off until the hg conversion to figure out how to make code submissions, since otherwise I'd have to learn it twice in short order.

I have reimplemented my work-arounds in terms of the above fix, and they function correctly, so this fix would suffice for me, for this issue.  (N.B. I'm sure you've noticed that I have entered a number of issues for http.server; I hope that was the right way to do it, to attempt to separate the issues.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10483>
_______________________________________

From report at bugs.python.org  Tue Nov 23 11:02:16 2010
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Nov 2010 10:02:16 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed socket
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>


New submission from Nadeem Vawda <nadeem.vawda at gmail.com>:

When running "make test" on Python3, test_socket reports a number of ResourceWarnings due to unclosed sockets.  Attached is a patch that changes the relevant tests so that they close all the created sockets.

test_multiprocessing and test_xmlrpc have a similar problem; I will upload patches for these shortly.

----------
components: Tests
files: test_socket-resourcewarning-fix.diff
keywords: patch
messages: 122209
nosy: nvawda
priority: normal
severity: normal
status: open
title: regrtest ResourceWarning - unclosed socket
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19783/test_socket-resourcewarning-fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Tue Nov 23 12:50:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Nov 2010 11:50:51 +0000
Subject: [issue10510] distutils.command.upload/register HTTP message headers:
	bad line termination
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1290513051.59.0.479959039704.issue10510@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the report.  This is how I understand the part of the spec you quoted: Strictly valid HTTP uses CRLF, but servers and clients should be liberal in what they accept and deal with LF too.  Senthil, do you agree with that?

There are a small number of PyPI-like servers out there which seem to deal fine with what distutils produces.  We have strong backward compatibility constraints in distutils, so we try to make the less changes possible to fix bugs.  Because we?ve haven?t had this reported by those other servers before, I?m tempted to reject this report.  The good part is that since you?re still writing the server, you can change its code to follow Postel?s Law and be liberal in what you accept.  Does that sound acceptable to you?

Best regards

----------
assignee:  -> eric.araujo
components: +Distutils, Distutils2
nosy: +eric.araujo, orsenthil, tarek
versions: +3rd party, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Tue Nov 23 12:51:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Nov 2010 11:51:10 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290513070.47.0.271471016374.issue10500@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +loewis
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Tue Nov 23 13:03:31 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 23 Nov 2010 12:03:31 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290513811.05.0.811757418895.issue10500@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What file specifically did you download?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Tue Nov 23 13:05:37 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 23 Nov 2010 12:05:37 +0000
Subject: [issue10504] Trivial mingw compile fixes
In-Reply-To: <1290432020.95.0.401711712349.issue10504@psf.upfronthosting.co.za>
Message-ID: <1290513937.08.0.798353067882.issue10504@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

But a "strict bugfix" should fix something.  Is there something that did not work before, and will work after this patch? IOW, how do you compile posixmodule.c with MinGW and does it produce a working module?

Now, I *am* interested in a working MinGW build.  Please share what you have done.  Your patch will certainly be merged into the py3k branch.
But it won't be merged into 2.7 until it gives a tangible benefit to the maintenance branch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10504>
_______________________________________

From report at bugs.python.org  Tue Nov 23 13:35:34 2010
From: report at bugs.python.org (Anders Blomdell)
Date: Tue, 23 Nov 2010 12:35:34 +0000
Subject: [issue10513] sqlite3.InterfaceError after commit
In-Reply-To: <1290515734.43.0.643837241692.issue10513@psf.upfronthosting.co.za>
Message-ID: <1290515734.43.0.643837241692.issue10513@psf.upfronthosting.co.za>


New submission from Anders Blomdell <anders.blomdell at control.lth.se>:

With version 2.7 (and 2.7.1rc1), the following sequence (see attached test):
   
   c =  cursor.execute(' select k from t where k == ?;', (1,))
   conn.commit()
   r = c.fetchone()

Traceback (most recent call last):
  File "/bugs/sqlite_bug.py", line 22, in <module>
    c =  cursor.execute(' select k from t where k == ?;', (2,))
sqlite3.InterfaceError: Error binding parameter 0 - probably unsupported type.

The program works with 2.6.2

----------
components: Extension Modules
files: sqlite_bug.py
messages: 122213
nosy: anders.blomdell at control.lth.se
priority: normal
severity: normal
status: open
title: sqlite3.InterfaceError after commit
type: crash
versions: Python 2.7
Added file: http://bugs.python.org/file19784/sqlite_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10513>
_______________________________________

From report at bugs.python.org  Tue Nov 23 13:38:18 2010
From: report at bugs.python.org (Alexander Solovyov)
Date: Tue, 23 Nov 2010 12:38:18 +0000
Subject: [issue10499] Modular interpolation in configparser
In-Reply-To: <1290395793.65.0.355106669717.issue10499@psf.upfronthosting.co.za>
Message-ID: <1290515898.03.0.249049167595.issue10499@psf.upfronthosting.co.za>


Changes by Alexander Solovyov <piranha at piranha.org.ua>:


----------
nosy: +asolovyov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10499>
_______________________________________

From report at bugs.python.org  Tue Nov 23 14:38:41 2010
From: report at bugs.python.org (Keith Meyer)
Date: Tue, 23 Nov 2010 13:38:41 +0000
Subject: [issue10514] configure does not create accurate Makefile
In-Reply-To: <1290519521.61.0.0855233461913.issue10514@psf.upfronthosting.co.za>
Message-ID: <1290519521.61.0.0855233461913.issue10514@psf.upfronthosting.co.za>


New submission from Keith Meyer <meyer.keith at gmail.com>:

When running configure on AIX 5.3 using:

OPT=-O2 LDFLAGS=-s ./configure --with-gcc="xlc_r -q64" --with-cxx-main="xlC_r -q64" --disable-ipv6 AR="ar -X64"

The Makefile still contains g++ as the CXX compiler to be used.

----------
components: Build
messages: 122214
nosy: daelious
priority: normal
severity: normal
status: open
title: configure does not create accurate Makefile
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10514>
_______________________________________

From report at bugs.python.org  Tue Nov 23 14:46:26 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Nov 2010 13:46:26 +0000
Subject: [issue10435] Document unicode C-API in reST
In-Reply-To: <AANLkTimkG=9x5h6HJU9Ri20j6SGLt6nh=6Pu0rKRswJ9@mail.gmail.com>
Message-ID: <4CEBC5AE.1000800@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 Wed, Nov 17, 2010 at 5:20 PM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
> ..
>> -/* Encodes a Unicode object and returns the result as Python string
>> +/* Encodes a Unicode object and returns the result as Python bytes
>>    object. */
>>
>>
>> PyUnicode_AsEncodedObject() encodes the Unicode object to
>> whatever the codec returns, so the "bytes" is wrong in the
>> above line.
>>
> 
> The above line describes PyUnicode_AsEncodedString(), not
> PyUnicode_AsEncodedObject().  The former has PyBytes_Check(v) after
> calling  v = PyCodec_Encode(..).  As far as I can tell this is the
> only difference that makes PyUnicode_AsEncodedObject() not redundant.

In that case, the change is fine.

> ..
>> +.. c:function:: PyObject* PyUnicode_AsDecodedObject(PyObject *unicode, const char *encoding, const char *errors)
>>
>> +   Create a Unicode object by decoding the encoded Unicode object
>> +   *unicode*.
>>
>> The function does not guarantee that a Unicode object will be
>> returned. It merely passes a Unicode object to a codec's
>> decode function and returns whatever the codec returns.
>>
> 
> Good point.  I am changing "Unicode object" to "Python object".
> 
> ..
>> +   Note that Python codecs do not accept Unicode objects for decoding,
>> +   so this method is only useful with user or 3rd party codecs.
>>
>> Please strike the last sentence. The codecs that were wrongly removed
>> from Python3 will get added back and provide such functionality.
>>
> 
> Would it be acceptable to keep this note, but add "as of version 3.2"
> or something like that?   I don't think there is a chance that these
> codecs will be added in 3.2 given the current schedule.

Please remove the sentence or change it to:

 Note that most Python codecs only accept Unicode objects for
 decoding.

> ..
>> This should read:
>>
>>   Decodes a Unicode object by passing the given Unicode object
>>   *unicode* to the codec for *encoding*.
>>   *encoding* and *errors* have the same meaning as the
>>   parameters of the same name in the :func:`unicode` built-in
>>   function.  The codec to be used is looked up using the Python codec
>>   registry.  Return *NULL* if an exception was raised by the codec.
>>
> 
> Is the following better?
> 
> """
>     Decodes a Unicode object by passing the given Unicode object
>     *unicode* to the codec for *encoding*.  *encoding* and *errors*
>     have the same meaning as the parameters of the same name in the
>     :func:`unicode` built-in  function. The codec to be used is
>     looked up using the Python codec registry. Return *NULL* if an
>     exception was raised by the codec.
> 
>     As of Python 3.2, this method is only useful with user or 3rd
>     party codec that encodes string into something other than bytes.

Same as above.

>     For encoding to bytes, use c:func:`PyUnicode_AsEncodedString`
>     instead.
> """
> ..
>>
>> +.. c:function:: void PyUnicode_Append(PyObject **pleft, PyObject *right)
> ..
>> +
>> +.. c:function:: void PyUnicode_AppendAndDel(PyObject **pleft, PyObject *right)
> ..
>>
>> Please don't document these two obscure APIs. Instead we should
>> make them private functions by prepending them with an underscore.
>> If you look at the implementations of those two APIs, they
>> are little more than a macros around PyUnicode_Concat().
>>
> 
> I don't agree that they are obscure.  Python uses them in multiple
> places and developers seem to know about them.  See patches submitted
> to issue4113 and issue7584.

I found these references:

http://osdir.com/ml/python.python-3000.cvs/2007-11/msg00270.html

and

http://riverbankcomputing.co.uk/hg/sip/annotate/91a545605044/siplib/siplib.c

so you're right: they are already in use in the wild. Too bad...

Please add these porting notes to the documentation:

PyUnicode_Append() works like the PyString_Concat(), while
PyUnicode_AppendAndDel() works like PyString_ConcatAndDel().

>> 3rd party extensions should use PyUnicode_Concat() to achieve
>> the same effect.
>>
> 
> Hmm.  I would not be surprised if current 3rd party extensions used
> PyUnicode_AppendAndDel() more often than PyUnicode_Concat().  (I know
> that I learned about PyUnicode_AppendAndDel()  before
> PyUnicode_Concat().)

Certainly not more often. PyUnicode_Concat() has been around much
longer than the other two APIs which are only available in Python3.

> Is there anything that makes PyUnicode_AppendAndDel() undesirable?   I
> don't mind adding a recommendation to use PyUnicode_Concat() if there
> is a practical reason for it or even a warning that
> PyUnicode_AppendAndDel() may be deprecated in the future, but renaming
> it to _PyUnicode_AppendAndDel() seems premature.

Both APIs are just slight variants of the PyUnicode_Concat()
API. They change parameters in-place which is rather uncommon
for the Unicode API and don't return their result - in fact the
error reporting is somewhat broken: APIs which do in-place
modifcations usually return an integer for error reporting.
These APIs set the *pleft to NULL instead.

Finally, the naming is of PyUnicode_AppendAndDel() is not ideal.
"Del" would suggest that an object is deleted, but in reality
it is only decrefed. It is also not clear that the second argument
is affected, but not the first one.

> ..
>> [PyUnicode_InternImmortal(PyObject **p)]
>> I don't think it's a good idea to make this a public API.
>> 3rd party extensions should not need to make use of such
>> APIs.
>>
>> Instead, we should make this a private API.
> 
> I agree, but isn't it prudent to document it as deprecated for 3rd
> party use first?

I don't think that's needed in this case. The API is not used
outside Python3, it seems. If people complain in beta phase,
we can always add a deprecation function wrapper instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10435>
_______________________________________

From report at bugs.python.org  Tue Nov 23 15:15:27 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Nov 2010 14:15:27 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
	(getdefaultlocale returns value not usable in setlocale)
In-Reply-To: <1290435740.67.0.233147659467.issue10466@psf.upfronthosting.co.za>
Message-ID: <4CEBCC76.6000502@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

R. David Murray wrote:
> 
> R. David Murray <rdmurray at bitdance.com> added the comment:
> 
> I had a report from a user on IRC during the bug weekend that they could not reproduce the failure on windows.  So it may be dependent on the windows version.  That doesn't answer your question of why it hasn't come up before, though, since my tests were done on XP.

Some research shows that the MS VCRT uses non-ISO locale names
for setlocale():

http://msdn.microsoft.com/en-us/library/x99tb11d.aspx
http://msdn.microsoft.com/en-us/library/hzz3tw78.aspx
http://msdn.microsoft.com/en-us/library/39cwe7zf.aspx
http://msdn.microsoft.com/en-us/library/cdax410z.aspx

and it doesn't support the ISO style locale namings, even though
the setlocale() page says "The set of available languages, country/region codes, and code pages
includes all those supported by the Win32 NLS API" and the Win32
API does support the ISO names:

http://msdn.microsoft.com/en-us/library/dd373814(VS.85).aspx

I'll have to check whether Vista also shows this behavior. On
Win XP the setlocale() API doesn't accept ISO language names;
I can confirm that. It only accepts the fully written out
form described on the above pages.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Tue Nov 23 15:37:12 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 23 Nov 2010 14:37:12 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290523032.66.0.9818096551.issue7094@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
stage: unit test needed -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Tue Nov 23 15:50:04 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 23 Nov 2010 14:50:04 +0000
Subject: [issue10466] locale.py resetlocale throws exception on Windows
	(getdefaultlocale returns value not usable in setlocale)
In-Reply-To: <4CEBCC76.6000502@egenix.com>
Message-ID: <4CEBD498.1070400@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
> 
> R. David Murray wrote:
>>
>> R. David Murray <rdmurray at bitdance.com> added the comment:
>>
>> I had a report from a user on IRC during the bug weekend that they could not reproduce the failure on windows.  So it may be dependent on the windows version.  That doesn't answer your question of why it hasn't come up before, though, since my tests were done on XP.
> 
> Some research shows that the MS VCRT uses non-ISO locale names
> for setlocale():
> 
> http://msdn.microsoft.com/en-us/library/x99tb11d.aspx
> http://msdn.microsoft.com/en-us/library/hzz3tw78.aspx
> http://msdn.microsoft.com/en-us/library/39cwe7zf.aspx
> http://msdn.microsoft.com/en-us/library/cdax410z.aspx
> 
> and it doesn't support the ISO style locale namings, even though
> the setlocale() page says "The set of available languages, country/region codes, and code pages
> includes all those supported by the Win32 NLS API" and the Win32
> API does support the ISO names:
> 
> http://msdn.microsoft.com/en-us/library/dd373814(VS.85).aspx
> 
> I'll have to check whether Vista also shows this behavior. On
> Win XP the setlocale() API doesn't accept ISO language names;
> I can confirm that. It only accepts the fully written out
> form described on the above pages.

Confirmed on Vista as well.

I think the only choice we have is to add a new alias dictionary
mapping the ISO language names to the Windows ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10466>
_______________________________________

From report at bugs.python.org  Tue Nov 23 16:06:44 2010
From: report at bugs.python.org (Jerzy Kozera)
Date: Tue, 23 Nov 2010 15:06:44 +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: <1290524804.7.0.328674807982.issue9742@psf.upfronthosting.co.za>


Jerzy Kozera <jerzy.kozera at gmail.com> added the comment:

Running

gcc -Wl,-R/usr/local/lib,-R/usr/lib  -o python Python/pymath.o Modules/python.o libpython2.7.a -lresolv -lsocket -lnsl -lrt -ldl  -lpthread   -lm

mv build/lib.solaris-2.8-sun4u-2.7/math_failed.so build/lib.solaris-2.8-sun4u-2.7/math.so

seems to have made math module import correctly and work:

bash-2.03$ ./python
Python 2.7 (r27:82500, Nov 23 2010, 14:49:30)
[GCC 3.4.6] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import math
>>> math.floor(2.4)
2.0


I suppose it's more a workaround than a solution, but hopefully it makes using math module possible and confirms the suggestion there might be something wrong with ar/gcc linking the .a file.

----------
nosy: +Jerzy.Kozera

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Tue Nov 23 16:11:17 2010
From: report at bugs.python.org (Chris Lambacher)
Date: Tue, 23 Nov 2010 15:11:17 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1290525077.45.0.414955444629.issue10087@psf.upfronthosting.co.za>


Chris Lambacher <chris at kateandchris.net> added the comment:

I don't think we *need* to have the encoding in the HTML calendar, but I doubt we could remove it at this point, deprecate maybe, but since I don't use the module I don't have a sense for how often the need for encoding comes up.

The one thing that the encoding is doing in the HTML calendar is ensuring that Unicode characters that are not directly translatable in the target encoding are replaced with html character references (the "xmlcharrefreplace" option to the errors argument in the encode method).

The encoding may be a holdover from Python 2x where the expected result was a string. The docs say HTMLCalendar was added in Python 2.5 at the same time that the Local versions were added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Tue Nov 23 16:51:28 2010
From: report at bugs.python.org (Brian Jones)
Date: Tue, 23 Nov 2010 15:51:28 +0000
Subject: [issue10510] distutils.command.upload/register HTTP message headers:
	bad line termination
In-Reply-To: <1290489114.33.0.672814735109.issue10510@psf.upfronthosting.co.za>
Message-ID: <1290527488.68.0.956238958635.issue10510@psf.upfronthosting.co.za>


Brian Jones <bkjones at gmail.com> added the comment:

In truth, I don't personally know if the other PyPI server implementations also have to work around this issue. Other comments on that are welcome. 

As for my own implementation, I've implemented a workaround to this, but I'm working around and reimplementing what is otherwise a feature built into the server (and every other one). 

I believe the suggested change makes the world a better place, and having administered several different web servers, I can't imagine ill effects from making the change. Web servers support *at least* the standard. Any ill effects we might imagine are, at least for my part, pure speculation. I, on the other hand, have found a real-life problem now :) 

I guess in the end I think that servers are more likely to err on the side of strict HTTP than make allowances for every "SHOULD" in the protocol spec, and leaving things as-is relies on a "SHOULD", which I submit is incorrect behavior, and therefore a bug. 

It's not like a fix is going to magically improve my life, as I'll have to support older buggy versions anyway, but making the change now can help grease the wheels for future implementations who won't have to hit this hurdle. 

My $.02.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Tue Nov 23 16:58:03 2010
From: report at bugs.python.org (Steve Moran)
Date: Tue, 23 Nov 2010 15:58:03 +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: <1290527883.3.0.611174517808.issue2636@psf.upfronthosting.co.za>


Steve Moran <stiv at uw.edu> added the comment:

Forgive me if this is just a stupid oversight. 

I'm a linguist and use UTF-8 for "special" characters for linguistics data. This often includes multi-byte Unicode character sequences that are composed as one grapheme. For example the ?? (if it's displaying correctly for you) is a LATIN SMALL LETTER I WITH STROKE \u0268 combined with COMBINING ACUTE ACCENT \u0301. E.g. a word I'm parsing:

j??-e-g?

I was pretty excited to find out that this regex library implements the grapheme match \X (equivalent to \P{M}\p{M}*). For the above example I needed to evaluate which sequences of characters can occur across syllable boundaries (here the hyphen "-"), so I'm aiming for:

??-e
e-g

When regex couldn't get any better, you awesome developers implemented an overlapped=True flag with findall and finditer. 

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
>>> import regex
>>> s = "j??-e-g?"
>>> s
'j??-e-g?'
>>> m = regex.compile("(\X)(-)(\X)")
>>> m.findall(s, overlapped=False)
[('??', '-', 'e')]

But these results are weird to me:

>>> m.findall(s, overlapped=True)
[('??', '-', 'e'), ('??', '-', 'e'), ('e', '-', 'g'), ('e', '-', 'g'), ('e', '-', 'g')]

Why the extra matches? At first I figured this had something to do with the overlapping match of the grapheme, since it's multiple characters. So I tried it with with out the grapheme match:

>>> m = regex.compile("(.)(-)(.)")
>>> s2 = "a-b-cd-e-f"
>>> m.findall(s2, overlapped=False)
[('a', '-', 'b'), ('d', '-', 'e')]

That's right. But with overlap...

>>> m.findall(s2, overlapped=True)
[('a', '-', 'b'), ('b', '-', 'c'), ('b', '-', 'c'), ('d', '-', 'e'), ('d', '-', 'e'), ('d', '-', 'e'), ('e', '-', 'f'), ('e', '-', 'f')]

Those 'extra' matches are confusing me. 2x b-c, 3x d-e, 2x e-f? Or even more simply:

>>> s2 = "a-b-c"
>>> m.findall(s2, overlapped=False)
[('a', '-', 'b')]
>>> m.findall(s2, overlapped=True)
[('a', '-', 'b'), ('b', '-', 'c'), ('b', '-', 'c')]

Thanks!

----------
nosy: +stiv
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Nov 23 17:03:54 2010
From: report at bugs.python.org (Phillip M. Feldman)
Date: Tue, 23 Nov 2010 16:03:54 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1290498628.18.0.591053433752.issue1859@psf.upfronthosting.co.za>
Message-ID: <AANLkTinRPsNSJ5mTqhS2=2i=V1fTA4R0mWZNRH8Bh0KX@mail.gmail.com>


Phillip M. Feldman <Phillip.M.Feldman at gmail.com> added the comment:

I would like to unsubscribe from this thread, but haven't been able to
figure out how to do it.

Phillip

On Mon, Nov 22, 2010 at 11:50 PM, Georg Brandl <report at bugs.python.org>wrote:

>
> Georg Brandl <georg at python.org> added the comment:
>
> Yes, please do apply.  You don't need to run a doc build for every small
> change; of course it is nice if you do, but errors will be caught by the
> daily build routine anyway and mailed to me.
>
> As for the two blank lines: you'll see that the original conversion from
> LaTeX produced two blank lines after each description (function, class,
> ...), and I find this to be a little more readable than only one blank line,
> especially when the descriptions are longer; for short descriptions leaving
> only one blank line saves space.  Syntactically, both are fully equivalent.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1859>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19785/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________
-------------- next part --------------
I would like to unsubscribe from this thread, but haven&#39;t been able to figure out how to do it.<br><br>Phillip<br><br><div class="gmail_quote">On Mon, Nov 22, 2010 at 11:50 PM, Georg Brandl <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>
Georg Brandl &lt;<a href="mailto:georg at python.org">georg at python.org</a>&gt; added the comment:<br>
<br>
Yes, please do apply. ??You don&#39;t need to run a doc build for every small change; of course it is nice if you do, but errors will be caught by the daily build routine anyway and mailed to me.<br>
<br>
As for the two blank lines: you&#39;ll see that the original conversion from LaTeX produced two blank lines after each description (function, class, ...), and I find this to be a little more readable than only one blank line, especially when the descriptions are longer; for short descriptions leaving only one blank line saves space. ??Syntactically, both are fully equivalent.<br>

<br>
----------<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/issue1859" target="_blank">http://bugs.python.org/issue1859</a>&gt;<br>
_______________________________________<br>
</blockquote></div><br>

From report at bugs.python.org  Tue Nov 23 17:04:27 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 23 Nov 2010 16:04:27 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290528267.03.0.372102997607.issue1859@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy:  -Phillip.M.Feldman at gmail.com

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Tue Nov 23 17:13:01 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 23 Nov 2010 16:13:01 +0000
Subject: [issue10510] distutils.command.upload/register HTTP message headers:
	bad line termination
In-Reply-To: <1290513051.59.0.479959039704.issue10510@psf.upfronthosting.co.za>
Message-ID: <20101123161243.GB10389@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I think, it is better that  distutils.command.register and
distutils.command.upload  use CRLF as the line terminator for header
values.
It just helps in many cases, we can safely side by this case, but not
relying LR or CR only may not be always possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Tue Nov 23 17:23:40 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 23 Nov 2010 16:23:40 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1290529420.41.0.42716222311.issue9807@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

looks good. checked with a plain and a debug build and installation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Tue Nov 23 17:31:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 23 Nov 2010 16:31: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: <1290529918.89.0.495795218715.issue2636@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Please don't change the type, this issue is about the feature request of adding this regex engine to the stdlib.

I'm sure Matthew will get back to you about your question.

----------
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Nov 23 18:31:45 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Nov 2010 17:31:45 +0000
Subject: [issue10513] sqlite3.InterfaceError after commit
In-Reply-To: <1290515734.43.0.643837241692.issue10513@psf.upfronthosting.co.za>
Message-ID: <1290533505.81.0.0478362965876.issue10513@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Also fails with 3.2 as in 2.7 and works in 3.1 as in 2.6.

----------
nosy: +ghaering, ned.deily
stage:  -> needs patch
type: crash -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10513>
_______________________________________

From report at bugs.python.org  Tue Nov 23 18:55:42 2010
From: report at bugs.python.org (Martin Budaj)
Date: Tue, 23 Nov 2010 17:55: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: <1290534942.45.0.466757650174.issue10515@psf.upfronthosting.co.za>


New submission from Martin Budaj <m.budaj at gmail.com>:

The method Sniffer._guess_quote_and_delimiter() in the module csv.py contains a bug in a regexp which checks for quotes around the last item of the line (example: a,b,"c,d"\n).

the pattern
'(?P<delim>>[^\w\n"\'])(?P<space> ?)(?P<quote>["\']).*?(?P=quote)(?:$|\n)'
used in the regex should be changed to
'(?P<delim>[^\w\n"\'])(?P<space> ?)(?P<quote>["\']).*?(?P=quote)(?:$|\n)'

file csv.py: line 212 in python 2.6, line 216 in 2.7, line 207 in 3.1

----------
components: Library (Lib)
messages: 122227
nosy: Martin.Budaj
priority: normal
severity: normal
status: open
title: csv sniffer does not recognize quotes at the end of line
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Tue Nov 23 19:34:05 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 23 Nov 2010 18:34:05 +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: <1290537245.34.0.834932552812.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101123.zip is a new version of the regex module.

Oops, sorry, the weird behaviour of msg122221 was a bug. :-(

----------
Added file: http://bugs.python.org/file19786/issue2636-20101123.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Nov 23 19:37:35 2010
From: report at bugs.python.org (Doug Shea)
Date: Tue, 23 Nov 2010 18:37:35 +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: <1290537455.6.0.490506275462.issue9742@psf.upfronthosting.co.za>


Doug Shea <doug.shea at gmail.com> added the comment:

It's actually not quite a solution, either. Working your changes into the build process, I *do* get a math module... but it does *not* have a round function.

> python
Python 2.7 (r27, Nov 23 2010, 11:54:39)
[GCC 3.3.2] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import math;
>>> print math.round(2.5);
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'module' object has no attribute 'round'
>>> print math.floor(2.5);
2.0

A step in the right direction, though, I'd think. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Tue Nov 23 19:37:48 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 23 Nov 2010 18:37: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: <1290537468.06.0.112019329002.issue10515@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for the report. It would be helpful if you could supply a patch including a unit test for this against 3.2 and/or 2.7.  Note only security issues are accepted for 2.6.

----------
nosy: +ned.deily
stage:  -> unit test needed
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Tue Nov 23 19:47:59 2010
From: report at bugs.python.org (Savio Sena)
Date: Tue, 23 Nov 2010 18:47:59 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1290538079.83.0.87056983759.issue1745035@psf.upfronthosting.co.za>


Savio Sena <savio.sena at acm.org> added the comment:

Attaching a more concise patch, as requested by georg.brandl.

----------
Added file: http://bugs.python.org/file19787/issue1745035-101123-saviosena.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Tue Nov 23 19:56:01 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 23 Nov 2010 18:56:01 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1290538561.75.0.785397056093.issue1745035@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I think data_size_limit and command_size_limit should be class attributes instead of instance attributes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Tue Nov 23 19:57:13 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 23 Nov 2010 18:57:13 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1290215757.3621.8.camel@localhost.localdomain>
Message-ID: <1290538628.27240.30.camel@radiator.bos.redhat.com>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> If this a work in progress, you could create an SVN branch in the
> sandbox (you can then use svnmerge to avoid diverging too much from
> mainline) or an hg repo.

Good idea; I've created branch "dmalcolm-ast-optimization-branch" (of
py3k) on svn.python.org for use as I build up my prototype
implementation of this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Tue Nov 23 20:05:30 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 23 Nov 2010 19:05:30 +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: <1290539130.07.0.342644565463.issue9742@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I *do* get a math module... but it does *not* have a round function.

Not a problem:  the math module isn't supposed to have a round function. :-)

The round function is used as part of the calculations that produce the gamma function.  So if the gamma function is working, then all's well:

>>> from math import gamma
>>> gamma(3.1)
2.197620278392477

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9742>
_______________________________________

From report at bugs.python.org  Tue Nov 23 20:15:46 2010
From: report at bugs.python.org (Savio Sena)
Date: Tue, 23 Nov 2010 19:15:46 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1290539746.32.0.706610605876.issue1745035@psf.upfronthosting.co.za>


Savio Sena <savio.sena at acm.org> added the comment:

Previous patch was incorrect. I'm attaching another one, I'm really sorry.

@giampaolo, about making the limits class attributes, it's not a good idea IMHO. According to RFC1869 command sizes can change depending on which Service Extensions are supported.

----------
Added file: http://bugs.python.org/file19788/issue1745035-101123-saviosena.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Tue Nov 23 20:24:23 2010
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Nov 2010 19:24:23 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1290540263.77.0.24714506422.issue10512@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

Attached is a patch that fixes the warnings in test_xmlrpc, along with some other file- and socket-related warnings in test_normalization, test_timeout and test_tk that only show up when regrtest is run with -uall.

The warning in test_timeout could be fixed with a smaller modification of the test code, but I thought it was better to have two separate attributes for the two sockets.  It seemed misleading to have _some_ of the setup/teardown code in setUp() and tearDown(), but then be doing more in the actual tests.

The warnings in test_multiprocessing seem to be due to leaks in the actual multiprocessing module, not in the test code, so that might be a bit more work to fix.

----------
title: regrtest ResourceWarning - unclosed socket -> regrtest ResourceWarning - unclosed sockets and files
Added file: http://bugs.python.org/file19789/resourcewarning-fixes-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Tue Nov 23 20:27:08 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 23 Nov 2010 19:27:08 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1290540428.68.0.335392000389.issue10399@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

py3k-ast-pyoptimize-2010-11-19-006.patch fixed up and committed to the branch as r86715; I'll work on that branch for the time being.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Tue Nov 23 20:35:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 23 Nov 2010 19:35:40 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290540940.2.0.104881865394.issue2001@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I am reviewing this and making some edits to the patch.  Will post this week.

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Tue Nov 23 20:37:12 2010
From: report at bugs.python.org (Savio Sena)
Date: Tue, 23 Nov 2010 19:37:12 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1290541032.2.0.32424349287.issue1745035@psf.upfronthosting.co.za>


Savio Sena <savio.sena at acm.org> added the comment:

size_limits are not class attributes instead of instance attributes, as suggested by giampaolo.rodola.

----------
Added file: http://bugs.python.org/file19790/issue1745035-101123-saviosena.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Tue Nov 23 20:40:06 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Tue, 23 Nov 2010 19:40:06 +0000
Subject: [issue1676121] Problem linking to readline lib on x86(64) Solaris
Message-ID: <1290541206.9.0.750071535901.issue1676121@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

Hmm why you dont use LDFLAGS ?
It is well documented what to expect during configuration and build phase.

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1676121>
_______________________________________

From report at bugs.python.org  Tue Nov 23 21:10:13 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Nov 2010 20:10:13 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290543013.04.0.912612602626.issue1859@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Removed file: http://bugs.python.org/file19785/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Tue Nov 23 21:10:34 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 23 Nov 2010 20:10:34 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1290543034.21.0.368735775242.issue1745035@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

AFAICT patch looks ok to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_______________________________________

From report at bugs.python.org  Tue Nov 23 21:19:21 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 23 Nov 2010 20:19:21 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290543561.18.0.592812967038.issue1859@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

textwrap_2010-11-23.diff is my attempt to provide a fix, if it's wanted/needed.

----------
Added file: http://bugs.python.org/file19791/textwrap_2010-11-23.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Tue Nov 23 21:33:37 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 23 Nov 2010 20:33:37 +0000
Subject: [issue9189] Improve CFLAGS handling
In-Reply-To: <1278517873.84.0.191654592449.issue9189@psf.upfronthosting.co.za>
Message-ID: <1290544417.62.0.653340304876.issue9189@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Since I was the one who reopened this: The issues I found were fixed in
r85358 and #9047 seems to be ok now. Setting to pending.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9189>
_______________________________________

From report at bugs.python.org  Tue Nov 23 21:53:54 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 23 Nov 2010 20:53:54 +0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1290545634.37.0.841307035509.issue1745035@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/issue1745035>
_______________________________________

From report at bugs.python.org  Tue Nov 23 21:59:32 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Nov 2010 20:59:32 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290545972.77.0.0847934677809.issue1859@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Doc patch applied to 3.2, 3.1, 2.7 in r86717, r86718, r86719
Jeremy Thurgood added to 3.2 Misc/ACKS in r86720.
(I know, I should have added this first before committing.)

I am leaving this open for a possible behavior patch.

Mathew: look at the examples by Tom Lynn and Jeremy Thurgood for unit tests. My comment "If newlines in the text are left in, [with replace_whitespace=False] they should reset the
characters-in-line count to 0 the same as inserted newlines." may be all that is needed for a fix.

If and when there is a behavior patch, the current doc patch should be reverted (undone) with an alternate doc patch.

Whoops, you just added a patch while I wrote the above. I will try to take a look if no one else does.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Tue Nov 23 22:00:04 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Nov 2010 21:00:04 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290546004.8.0.801374030824.issue1859@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Tue Nov 23 22:26:28 2010
From: report at bugs.python.org (Nadeem Vawda)
Date: Tue, 23 Nov 2010 21:26:28 +0000
Subject: [issue1508475] transparent gzip compression in urllib
Message-ID: <1290547588.64.0.446660265794.issue1508475@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nvawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1508475>
_______________________________________

From report at bugs.python.org  Tue Nov 23 22:30:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Nov 2010 21:30:47 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1290486723.59.0.572735356409.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290547843.3642.106.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The Rietveld issue is here:
> http://codereview.appspot.com/3269041
> 
> I ended up loading my incremental patches in, but it's easy enough to
> diff the base with the last patch.  If for some reasons it doesn't
> work as conveniently as I expect, let me know and I will upload it to
> Rietveld again as one big patch.

I've started reviewing, and I must say that incremental patches would
have made more sense if they didn't mutate each other's changes. Still
reviewing though, thanks for the upload.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 22:34:05 2010
From: report at bugs.python.org (Tom Lynn)
Date: Tue, 23 Nov 2010 21:34:05 +0000
Subject: [issue1859] textwrap doesn't linebreak on "\n"
In-Reply-To: <1200573627.07.0.875176355387.issue1859@psf.upfronthosting.co.za>
Message-ID: <1290548045.62.0.753348686502.issue1859@psf.upfronthosting.co.za>


Tom Lynn <tlynn at users.sourceforge.net> added the comment:

I've also been attempting to look into this and came up with an almost identical patch, which is promising:
https://bitbucket.org/tlynn/issue1859/diff/textwrap.py?diff2=041c9deb90a2&diff1=f2c093077fbf

I missed the wordsep_simple_re though.

Testing it is the hard part.  I've got a few examples that could become tests in that repository, but it's far from conclusive.

One corner case I found is trailing whitespace becoming a blank line:

>>> from textwrap import TextWrapper
>>> T = TextWrapper(replace_whitespace=False, drop_whitespace=False, width=9)
>>> T.wrap('x'*9 + ' \nfoo')
['xxxxxxxxx', ' ', 'foo']

I think it's fine.  drop_whitespace=True removes the blank line, and those who really want drop_whitespace=False can remove the blank lines easily.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1859>
_______________________________________

From report at bugs.python.org  Tue Nov 23 22:52:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Nov 2010 21:52:18 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1290547843.3642.106.camel@localhost.localdomain>
Message-ID: <1290549133.3642.109.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > I ended up loading my incremental patches in, but it's easy enough to
> > diff the base with the last patch.  If for some reasons it doesn't
> > work as conveniently as I expect, let me know and I will upload it to
> > Rietveld again as one big patch.
> 
> I've started reviewing, and I must say that incremental patches would
> have made more sense if they didn't mutate each other's changes. Still
> reviewing though, thanks for the upload.

Ok, things are even worse: comments I've made to intermediate patches
have wrong URLs in the summary e-mail, so they don't point to the right
line numbers. Certainly a bug in Rietveld, but I'm not willing to do it,
sorry.

Bottom line is that you're making too many gratuitous changes, including
style changes, and probably useless changes (Py_LOCAL_INLINE everywhere,
nitpicking over ISLT / IFLT...). Also, there's some strange complication
in some places which deserves comments and justification.

Next time, please upload a single patch. Really.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 23:22:08 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 23 Nov 2010 22:22:08 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290550928.0.0.451697765266.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Antoine Pitrou wrote:
> Next time, please upload a single patch. Really.

I haven't used Rietveld that much yet, and I'm still learning best-practices.  I apologize for the painful experience.

For anyone else planning to take a look at this, here it is as one big patch:
http://codereview.appspot.com/3290041

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 23 23:29:50 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 23 Nov 2010 22:29:50 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290551390.54.0.384750100564.issue9915@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Antoine,

My original patch was much more focused, but had a slightly larger performance penalty for sorting random keys (see http://bugs.python.org/msg122178).  Do you think the performance tradeoff there was still worthwhile?

Ihave uploaded my original patch (as one patch :) ) here:
http://codereview.appspot.com/3291041

If you think the original performance looks like a worthwhile tradeoff, could you spend about 1 minute looking over that version of patch and give your general impression?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Wed Nov 24 00:03:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 23 Nov 2010 23:03:58 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1290551390.54.0.384750100564.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290553434.3642.111.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> My original patch was much more focused, but had a slightly larger
> performance penalty for sorting random keys (see
> http://bugs.python.org/msg122178).  Do you think the performance
> tradeoff there was still worthwhile?

I am not objecting against the performance tweaks but the other more or
less gratuitous changes (IFLT vs ISLT, Py_LOCAL_INLINE sprinkled all
over, weird complicated static "keys" instead of the initial stack_keys,
"else" style change...).

You can still try to salvage my comments from the review I've posted,
but it seems Rietveld makes the thing tediously annoying to navigate
(best thing may be to browse all 14 side-by-side diffs to look for the
comments).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Wed Nov 24 00:37:48 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 23 Nov 2010 23:37:48 +0000
Subject: [issue10516] Add list.clear()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Add list.clear() method with obvious semantics.

Pro:
1. parallel to set/dict/defaultdict/deque.clear(),
   usable in generic mutable collection function;
2. makes it easier to switch between list and other collection class;
3. current alternatives are not as obvious;
4. some people seem to expect it.

Anti:
1. unneeded; del l[:] or l[:]=[] do same already.

Guido: (python-ideas list, 'Set Syntax' thread, today)
"FWIW I'm fine with adding list.clear() to 3.3."

----------
components: Interpreter Core
messages: 122251
nosy: terry.reedy
priority: normal
severity: normal
stage: unit test needed
status: open
title: Add list.clear()
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Wed Nov 24 00:58:47 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 23 Nov 2010 23:58:47 +0000
Subject: [issue10516] Add list.clear()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290556727.65.0.051345303996.issue10516@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Guido's email is archived at:
http://mail.python.org/pipermail/python-ideas/2010-November/008732.html

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Wed Nov 24 01:20:10 2010
From: report at bugs.python.org (demarcus)
Date: Wed, 24 Nov 2010 00:20:10 +0000
Subject: [issue9404] IDLE won't launch on XP
In-Reply-To: <1280352480.94.0.617351160567.issue9404@psf.upfronthosting.co.za>
Message-ID: <1290558010.25.0.96210039779.issue9404@psf.upfronthosting.co.za>


demarcus <python at dmarkphotography.com> added the comment:

Had this issue.. figured out what's causing it... definitively.

I had an earlier version of python installed, and I created a pythonhome user variable: "c:\python24."

I'm now using Python 2.5, and that old variable was:
1.) Keeping me from opening the IDLE
2.) Keeping the console from finding the os module.  This is also the source of the import os error.

TO FIX:
- modify the pythonhome variable to your current version, or.. remove it.

-Dmark
www.dmarkphotography.com

----------
nosy: +rugburnpy
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9404>
_______________________________________

From report at bugs.python.org  Wed Nov 24 01:24:19 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 24 Nov 2010 00:24:19 +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: <1290558259.33.0.917274146548.issue10517@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

py3k built from trunk on Centos 5.5 freezes during regrtest on test_concurrent_futures with "Fatal Python error: Invalid thread state for this thread".

A set of hopefully useful diagnostic logs attached as patch.

----------
assignee: bquinlan
components: Extension Modules
files: concurrent-futures-freeze.tar.bz2
messages: 122254
nosy: bquinlan, lukasz.langa
priority: critical
severity: normal
status: open
title: test_concurrent_futures crashes with "Fatal Python error: Invalid thread state for this thread"
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file19792/concurrent-futures-freeze.tar.bz2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Nov 24 01:32:41 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 24 Nov 2010 00:32:41 +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: <1290558761.09.0.807422273506.issue10517@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

A colorful example: http://bpaste.net/show/11493/

(just in case if downloading and extracting logs is not feasible)

Some clarification: as in a typical concurrent problem, subsequent calls freeze in different test cases, but the freeze itself is always reproducible and always during this test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Nov 24 01:56:15 2010
From: report at bugs.python.org (Andrew McNamara)
Date: Wed, 24 Nov 2010 00:56:15 +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: <1290560175.34.0.84027620948.issue10515@psf.upfronthosting.co.za>


Changes by Andrew McNamara <andrewm at object-craft.com.au>:


----------
nosy: +andrewmcnamara

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Wed Nov 24 02:29:04 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 24 Nov 2010 01:29:04 +0000
Subject: [issue3061] time.strftime() always decodes result with UTF-8
In-Reply-To: <1212914669.61.0.344111508001.issue3061@psf.upfronthosting.co.za>
Message-ID: <1290562144.98.0.00208492163301.issue3061@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3061>
_______________________________________

From report at bugs.python.org  Wed Nov 24 03:17:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Nov 2010 02:17:01 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290565021.66.0.139740570386.issue10516@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Guido approved these both in a thread earlier this year.

The reasoning for copy() was the same as for clear(), some folks couldn't cope with:

   b = a[:]

----------
nosy: +rhettinger
title: Add list.clear() -> Add list.clear() and list.copy()

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Wed Nov 24 04:01:17 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 24 Nov 2010 03:01:17 +0000
Subject: [issue10493] test_strptime failures under OpenIndiana
In-Reply-To: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>
Message-ID: <1290567677.27.0.959931524437.issue10493@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I have spend the afternoon doing bisection on the buildslave. The problem was introduced in r73043:

"""
------------------------------------------------------------------------
r73043 | martin.v.loewis | 2009-05-30 08:13:40 +0200 (Sat, 30 May 2009) | 2 lines

Issue #5562: Use wcsftime for time.strftime where available.

------------------------------------------------------------------------
"""

I confirm that 2.7 and 3.x buildbots are green for this particular test.
Only 3.1 is affected, in this particular buildslave.

Martin, could you check it? Thanks!.

----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10493>
_______________________________________

From report at bugs.python.org  Wed Nov 24 04:41:17 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 24 Nov 2010 03:41:17 +0000
Subject: [issue10486] http.server doesn't set all CGI environment variables
In-Reply-To: <1290325295.78.0.545647251788.issue10486@psf.upfronthosting.co.za>
Message-ID: <1290570077.93.0.0712791208318.issue10486@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Took a little more time to do a little more analysis on this one.  Compared a sample query via Apache on Linux vs http.server, then looked up the CGI RFC for more info:

DOCUMENT_ROOT: ...
GATEWAY_INTERFACE: CGI/1.1
HTTP_ACCEPT: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
HTTP_ACCEPT_CHARSET: ISO-8859-1,utf-8;q=0.7,*;q=0.7
HTTP_ACCEPT_ENCODING: gzip,deflate
HTTP_ACCEPT_LANGUAGE: en-us,en;q=0.5
HTTP_CONNECTION: keep-alive
HTTP_COOKIE: ...
HTTP_HOST: ...
HTTP_KEEP_ALIVE: 115
HTTP_USER_AGENT: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10
PATH: /usr/local/bin:/usr/bin:/bin
PATH_INFO: ...
PATH_TRANSLATED: ...
QUERY_STRING: 
REMOTE_ADDR: 173.75.100.22
REMOTE_PORT: 50478
REQUEST_METHOD: GET
REQUEST_URI: ...
SCRIPT_FILENAME: ...
SCRIPT_NAME: ...
SERVER_ADDR: ...
SERVER_ADMIN: ...
SERVER_NAME: ...
SERVER_PORT: ...
SERVER_PROTOCOL: HTTP/1.1
SERVER_SIGNATURE: <address>Apache Server at rkivs.com Port 80</address>

SERVER_SOFTWARE: Apache
UNIQUE_ID: TLEs8krc24oAABQ1TIUAAAPN

Above from Apache, below from http.server

GATEWAY_INTERFACE: CGI/1.1
HTTP_USER_AGENT: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12
PATH_INFO: ...
PATH_TRANSLATED: ...
QUERY_STRING: ...
REMOTE_ADDR: 127.0.0.1
REQUEST_METHOD: GET
SCRIPT_NAME: ...
SERVER_NAME: ...
SERVER_PORT: ...
SERVER_PROTOCOL: HTTP/1.0
SERVER_SOFTWARE: SimpleHTTP/0.6 Python/3.2a4

Analysis of missing variables between Apache and http.server:

DOCUMENT_ROOT
HTTP_ACCEPT
HTTP_ACCEPT_CHARSET
HTTP_ACCEPT_ENCODING
HTTP_ACCEPT_LANGUAGE
HTTP_CONNECTION
HTTP_COOKIE
HTTP_HOST
HTTP_KEEP_ALIVE
HTTP_PORT
PATH
REQUEST_URI
SCRIPT_FILENAME
SERVER_ADDR
SERVER_ADMIN


Additional variables mentioned in RFC 3875, not used for my test requests:

AUTH_TYPE
CONTENT_LENGTH
CONTENT_TYPE
REMOTE_IDENT
REMOTE_USER

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10486>
_______________________________________

From report at bugs.python.org  Wed Nov 24 04:50:34 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 24 Nov 2010 03:50:34 +0000
Subject: [issue10484] http.server.is_cgi fails to handle CGI URLs containing
	PATH_INFO
In-Reply-To: <1290324717.4.0.0270982528857.issue10484@psf.upfronthosting.co.za>
Message-ID: <1290570634.45.0.196562474666.issue10484@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

Here is a replacement for the body of is_cgi that will work with the current _url_collapse_path_split function, but it seems to me that it is ineffecient to do multiple splits and joins of the path between the two functions.

            splitpath = server._url_collapse_path_split(self.path)
            # more processing required due to possible PATHINFO parts
            # not clear above function really does what is needed here,
            # nor just how general it is!
            splitpath = '/'.join( splitpath ).split('/', 2 )
            head = '/' + splitpath[ 1 ]
            tail = splitpath[ 2 ]
            if head in self.cgi_directories:
                self.cgi_info = head, tail
                return True
            return False

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10484>
_______________________________________

From report at bugs.python.org  Wed Nov 24 06:08:38 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Wed, 24 Nov 2010 05:08:38 +0000
Subject: [issue10498] calendar.LocaleHTMLCalendar.formatyearpage() results in
	traceback with 'unsupported locale setting' on Windows
In-Reply-To: <1290393306.69.0.998081430395.issue10498@psf.upfronthosting.co.za>
Message-ID: <1290575318.59.0.563528249638.issue10498@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

On OSX, _locale.setlocale raise locale.Error with arg 'UTF8' but ok with 'UTF-8'. and setlocale tries to normalize localename with locale.normalize(). and locale.normalize() always change encoding to 'UTF8' (locale.py:646). 

So changes in locale.normalize could fix this issue at least on OSX. 

patch and unittest against p3k is attached.



I did not search why normalize() changes 'utf_8' to 'UTF8' until now. but I would post if I get answer in subversion log.

----------
keywords: +patch
Added file: http://bugs.python.org/file19793/issue10498.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10498>
_______________________________________

From report at bugs.python.org  Wed Nov 24 08:03:37 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Wed, 24 Nov 2010 07:03:37 +0000
Subject: [issue9852] test_ctypes fail with clang
In-Reply-To: <1284465948.07.0.835658917717.issue9852@psf.upfronthosting.co.za>
Message-ID: <1290582217.35.0.730418360265.issue9852@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

Problem seems to be in _ctypes_test.c . If you compile _ctypes_test.c with gcc problems disappears.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9852>
_______________________________________

From report at bugs.python.org  Wed Nov 24 08:11:04 2010
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 24 Nov 2010 07:11:04 +0000
Subject: [issue10037] multiprocessing.pool processes started by worker handler
	stops working
In-Reply-To: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za>
Message-ID: <1290582664.21.0.805609667175.issue10037@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Could you give an example code which can reproduce this issue?

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10037>
_______________________________________

From report at bugs.python.org  Wed Nov 24 08:34:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 24 Nov 2010 07:34:57 +0000
Subject: [issue10493] test_strptime failures under OpenIndiana
In-Reply-To: <1290567677.27.0.959931524437.issue10493@psf.upfronthosting.co.za>
Message-ID: <4CECC01C.6030305@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin, could you check it? Thanks!.

Not in the foreseeable future, sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10493>
_______________________________________

From report at bugs.python.org  Wed Nov 24 08:35:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 24 Nov 2010 07:35:18 +0000
Subject: [issue10493] test_strptime failures under OpenIndiana
In-Reply-To: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>
Message-ID: <1290584118.22.0.442365713858.issue10493@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee: loewis -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10493>
_______________________________________

From report at bugs.python.org  Wed Nov 24 08:56:21 2010
From: report at bugs.python.org (Glenn Linderman)
Date: Wed, 24 Nov 2010 07:56:21 +0000
Subject: [issue10482] subprocess and deadlock avoidance
In-Reply-To: <1290320162.59.0.372707956205.issue10482@psf.upfronthosting.co.za>
Message-ID: <1290585381.55.0.0184871541809.issue10482@psf.upfronthosting.co.za>


Glenn Linderman <v+python at g.nevcal.com> added the comment:

So I've experimented a bit, and it looks like simply exposing ._readerthread as an external API would handle the buffered case for stdout or stderr.  For http.server CGI scripts, I think it is fine to buffer stderr, as it should not be a high-volume channel... but not both stderr and stdout, as stdout can be huge.  And not stdin, because it can be huge also.

For stdin, something like the following might work nicely for some cases, including http.server (with revisions):

    def _writerthread(self, fhr, fhw, length):
        while length > 0:
            buf = fhr.read( min( 8196, length ))
            fhw.write( buf )
            length -= len( buf )
        fhw.close()

When the stdin data is buffered, but the application wishes to be stdout centric instead of stdin centric (like the current ._communicate code), a variation could be made replacing fhr by a data buffer, and writing it gradually (or fully) to the pipe, but from a secondary thread.

Happily, this sort of code (the above is extracted from a test version of http.server) can be implemented in the server, but would be more usefully provided by subprocess, in my opinion.

To include the above code inside subprocess would just be a matter of tweaking references to class members instead of parameters.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10482>
_______________________________________

From report at bugs.python.org  Wed Nov 24 08:56:50 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Wed, 24 Nov 2010 07:56:50 +0000
Subject: [issue10498] calendar.LocaleHTMLCalendar.formatyearpage() results in
	traceback with 'unsupported locale setting' on Windows
In-Reply-To: <1290393306.69.0.998081430395.issue10498@psf.upfronthosting.co.za>
Message-ID: <1290585410.96.0.850183663911.issue10498@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

r38027 has following changes.

-    'utf-8':                        'UTF-8',
+    'utf_8':                        'UTF8',


subversion log is:

Correct mapping of Python codec name to C encoding name for UTF-8 (the C lib doesn't seem to like "UTF-8").

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10498>
_______________________________________

From report at bugs.python.org  Wed Nov 24 10:49:38 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Nov 2010 09:49:38 +0000
Subject: [issue10498] calendar.LocaleHTMLCalendar.formatyearpage() results in
	traceback with 'unsupported locale setting' on Windows
In-Reply-To: <1290393306.69.0.998081430395.issue10498@psf.upfronthosting.co.za>
Message-ID: <1290592178.71.0.380915708073.issue10498@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Your analysis is correct.  Sorry, I should have noted that the OS X "UTF8" vs "UTF-8" discrepancy has already been discussed in Issue10090 and Issue10154.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10498>
_______________________________________

From report at bugs.python.org  Wed Nov 24 11:02:20 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Nov 2010 10:02:20 +0000
Subject: [issue9852] test_ctypes fail with clang
In-Reply-To: <1284465948.07.0.835658917717.issue9852@psf.upfronthosting.co.za>
Message-ID: <1290592940.09.0.79372579717.issue9852@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Can you say exactly what arguments are given to clang for this compile?  (As you probably know, CPython builds on OS X for python.org installers use gcc, not clang.)

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9852>
_______________________________________

From report at bugs.python.org  Wed Nov 24 11:02:50 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 24 Nov 2010 10:02:50 +0000
Subject: [issue10430] _sha.sha().digest() method is endian-sensitive. and
	hexdigest()
In-Reply-To: <1289893015.01.0.604303806999.issue10430@psf.upfronthosting.co.za>
Message-ID: <1290592970.04.0.559105717149.issue10430@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Found the issue and it wasn't with sha1.
Turned out that the code was doing somethign like
sha1(buffer(unicode('str'))) which exposed the endianness of the unicode representation.
Sorry for wasting your time.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10430>
_______________________________________

From report at bugs.python.org  Wed Nov 24 11:03:42 2010
From: report at bugs.python.org (Ismail Donmez)
Date: Wed, 24 Nov 2010 10:03:42 +0000
Subject: [issue9852] test_ctypes fail with clang
In-Reply-To: <1284465948.07.0.835658917717.issue9852@psf.upfronthosting.co.za>
Message-ID: <1290593022.77.0.00830432741868.issue9852@psf.upfronthosting.co.za>


Ismail Donmez <ismail at namtrac.org> added the comment:

No interesting option. But this looks like a clang bug, compiling _ctypes_test.c with -O0 fixes the issue. So this is a compiler optimization bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9852>
_______________________________________

From report at bugs.python.org  Wed Nov 24 11:08:17 2010
From: report at bugs.python.org (Anders Blomdell)
Date: Wed, 24 Nov 2010 10:08:17 +0000
Subject: [issue10513] sqlite3.InterfaceError after commit
In-Reply-To: <1290515734.43.0.643837241692.issue10513@psf.upfronthosting.co.za>
Message-ID: <1290593297.3.0.671039363955.issue10513@psf.upfronthosting.co.za>


Anders Blomdell <anders.blomdell at control.lth.se> added the comment:

The culprit seems to be 'pysqlite_do_all_statements(self, ACTION_RESET, 0)' in pysqlite_connection_commit, which resets all active statements, but subsequent fetch/fetchall seems to trash the sqlite3 state in the statements. Removing the ACTION_RESET seems to bring back old behaviour (if it's the correct fix is, however, beyond me).

Slightly modified testprogram that shows more wierdness; output from:

    c =  cursor.execute(' select k from t where k == ?;', (0,))
    conn.commit()
    print c.fetchall()

is:

    [(0,), (0,)]

which is not what I would expect with a primary key...

----------
Added file: http://bugs.python.org/file19794/sqlite_bug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10513>
_______________________________________

From report at bugs.python.org  Wed Nov 24 11:19:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Nov 2010 10:19:57 +0000
Subject: [issue9852] test_ctypes fail with clang
In-Reply-To: <1284465948.07.0.835658917717.issue9852@psf.upfronthosting.co.za>
Message-ID: <1290593997.87.0.466510560605.issue9852@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

OK, then if you care to follow up, I suggest pursuing with the Clang project.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9852>
_______________________________________

From report at bugs.python.org  Wed Nov 24 12:05:32 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Nov 2010 11:05:32 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1290596732.07.0.0656192958939.issue10496@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
Removed message: http://bugs.python.org/msg122051

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Wed Nov 24 12:06:31 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Nov 2010 11:06:31 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1290596791.05.0.701883643508.issue10496@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The problem is reproducible on a current Debian Linux system although with different results for current versions of Python (only security issues are accepted against 2.6).  Unlike with 2.6, 3.1 reports no error.  2.7 and 3.2 both fail with an exception:

Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 548, in <module>
    main()
  File "/usr/lib/python2.7/site.py", line 530, in main
    known_paths = addusersitepackages(known_paths)
  File "/usr/lib/python2.7/site.py", line 257, in addusersitepackages
    user_site = getusersitepackages()
  File "/usr/lib/python2.7/site.py", line 232, in getusersitepackages
    user_base = getuserbase() # this will also set USER_BASE
  File "/usr/lib/python2.7/site.py", line 222, in getuserbase
    USER_BASE = get_config_var('userbase')
  File "/usr/lib/python2.7/sysconfig.py", line 541, in get_config_var
    return get_config_vars().get(name)
  File "/usr/lib/python2.7/sysconfig.py", line 449, in get_config_vars
    _CONFIG_VARS['userbase'] = _getuserbase()
  File "/usr/lib/python2.7/sysconfig.py", line 198, in _getuserbase
    return env_base if env_base else joinuser("~", ".local")
  File "/usr/lib/python2.7/sysconfig.py", line 185, in joinuser
    return os.path.expanduser(os.path.join(*args))
  File "/usr/lib/python2.7/posixpath.py", line 256, in expanduser
    userhome = pwd.getpwuid(os.getuid()).pw_dir
KeyError: 'getpwuid(): uid not found: 12345'

----------
nosy: +ned.deily
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Wed Nov 24 12:07:05 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Nov 2010 11:07:05 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1290596825.42.0.607354325233.issue10496@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Wed Nov 24 14:05:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Nov 2010 13:05:25 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It was just resting. Here is a patch to wake it up for 3.2 (or 3.3 pending moratorium interpretation).

As for the py3k warning in 2.x (and the 2to3 fixer), it's not obvious what we should do: callable() clearly doesn't exist in 3.0 and 3.1.

----------
assignee: georg.brandl
components: Interpreter Core
files: callable.patch
keywords: patch
messages: 122273
nosy: benjamin.peterson, georg.brandl, pitrou
priority: normal
severity: normal
status: open
title: Bring back callable()
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19795/callable.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Wed Nov 24 14:21:52 2010
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 24 Nov 2010 13:21:52 +0000
Subject: [issue10519] setobject.c no-op typo
In-Reply-To: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>
Message-ID: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>


New submission from Armin Rigo <arigo at users.sourceforge.net>:

Probably a typo in setobject.c.

The patch attached here does not really change anything but fixes the typo, leading to slightly clearer code and avoiding one level of recursion.  All tests still pass.

----------
components: Interpreter Core
files: diff1
messages: 122274
nosy: arigo
priority: normal
severity: normal
status: open
title: setobject.c no-op typo
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19796/diff1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10519>
_______________________________________

From report at bugs.python.org  Wed Nov 24 14:28:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Nov 2010 13:28:14 +0000
Subject: [issue10519] setobject.c no-op typo
In-Reply-To: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>
Message-ID: <1290605294.41.0.479113962828.issue10519@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger, stutzbach
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10519>
_______________________________________

From report at bugs.python.org  Wed Nov 24 14:32:35 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 24 Nov 2010 13:32:35 +0000
Subject: [issue10027] os.lstat/os.stat don't set st_nlink on Windows
In-Reply-To: <1286289327.29.0.159315245099.issue10027@psf.upfronthosting.co.za>
Message-ID: <1290605555.48.0.431580564138.issue10027@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed to py3k in r86727.


I think this should be backported to the maintenance branches, but not until after the upcoming point releases. Although those branches won't have the ability to create hard links, they should have the ability to view information about existing links on the system (or if they create them via ctypes/pywin32). Since those branches won't be able to explicitly test this, I think it makes sense to let this bake for a while on py3k.

----------
assignee: ocean-city -> brian.curtin
resolution: accepted -> fixed
stage: patch review -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Wed Nov 24 14:36:56 2010
From: report at bugs.python.org (SilentGhost)
Date: Wed, 24 Nov 2010 13:36:56 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290605816.61.0.501960137526.issue5800@psf.upfronthosting.co.za>


Changes by SilentGhost <michael.mischurow+bpo at gmail.com>:


Removed file: http://bugs.python.org/file19680/headers.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Wed Nov 24 14:37:37 2010
From: report at bugs.python.org (SilentGhost)
Date: Wed, 24 Nov 2010 13:37:37 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290605857.51.0.591641921056.issue5800@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Re-submitting the patch for Lib/wsgiref/headers.py w/o the isinstance change

----------
keywords: +patch
Added file: http://bugs.python.org/file19797/headers.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Wed Nov 24 14:45:33 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Nov 2010 13:45:33 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290606333.13.0.672136537306.issue10518@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think we should lift the py3k warning after 3.2 is released, but leave the 2to3 fixer in for the time being.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Wed Nov 24 14:47:07 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 24 Nov 2010 13:47:07 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290606427.16.0.450471018719.issue5800@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Wed Nov 24 15:00:02 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 24 Nov 2010 14:00:02 +0000
Subject: [issue10520] Build with --enable-shared fails
Message-ID: <1290607202.61.0.672349288392.issue10520@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: skrah
priority: normal
severity: normal
status: open
title: Build with --enable-shared fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Wed Nov 24 15:05:56 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 24 Nov 2010 14:05:56 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Building the modules fails if --enable-shared is used. The linker picks
up an existing library from /usr/local/lib, which has not been compiled
with -fPIC:


gcc -pthread -shared build/temp.linux-x86_64-3.2/home/stefan/svn/py3k/Modules/_struct.o -L/usr/local/lib -L. -lpython3.2m -o build/lib.linux-x86_64-3.2/_struct.cpython-32m.so
/usr/bin/ld: /usr/local/lib/libpython3.2m.a(abstract.o): relocation R_X86_64_32S against `_PyObject_NextNotImplemented' can not be used when making a shared object; recompile with -fPIC
/usr/local/lib/libpython3.2m.a: could not read symbols: Bad value
collect2: ld returned 1 exit status


Linking works if the order of the flags is changed to "-L. L/usr/local/lib".

----------
components: +Build
nosy: +pitrou, tarek
priority: normal -> critical
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Wed Nov 24 15:08:12 2010
From: report at bugs.python.org (Ray.Allen)
Date: Wed, 24 Nov 2010 14:08:12 +0000
Subject: [issue7238] frame.f_lineno doesn't get updated after local trace
	function assigned to it
In-Reply-To: <1256836618.71.0.0275056583438.issue7238@psf.upfronthosting.co.za>
Message-ID: <1290607692.77.0.548477514822.issue7238@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

It's not a bug. What happens is like this:

1, You set trace function using sys.settrace(tracer).
2, When the following func() is called, tracer is called with a "call" event, so the trace function in PyThreadState is set to NULL since "sys.settrace(None)" is execute, but since the return value is a valid local trace function, the frame of called function("func()") has its local trace function.
3, The called function("func()") executes, though its frame has a local trace function, but it will not be executed since PyThreadState->c_tracefunc is NULL. When you get f_lineno from frame, you get the not refreshed f_lineno value but not the dynamically computed lineno, as the f_lineno's getter function said:
    if(f->f_trace)
        return f->f_lineno;
    else
        return PyCode_Addr2Line(f->f_code, f->f_lasti);

   Here because your frame's local trace function is not executed, the f_lineno is not refreshed.

4, When the second time func() calls, there is no global trace function. Each time you get the f_lineno, it uses PyCode_Addr2Line() to get the dynamically computed line number.


I think this situation is so rarely that the doc saying "f_lineno is 
the current line number of the frame" is correct.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7238>
_______________________________________

From report at bugs.python.org  Wed Nov 24 15:13:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Nov 2010 14:13:44 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290608024.25.0.788149607751.issue10520@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Wed Nov 24 16:13:51 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 24 Nov 2010 15:13:51 +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: <1290611631.46.0.319540629775.issue10517@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/issue10517>
_______________________________________

From report at bugs.python.org  Wed Nov 24 16:25:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 24 Nov 2010 15:25:25 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>>> 'xyz'.center(20, '\U00100140')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: The fill character must be exactly one character long

str.ljust and str.rjust are similarly affected.

----------
components: Interpreter Core
messages: 122280
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: str methods don't accept non-BMP fillchar on a narrow Unicode build
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Wed Nov 24 16:31:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Nov 2010 15:31:07 +0000
Subject: [issue10522] test_telnet exception
In-Reply-To: <1290612667.85.0.353730083287.issue10522@psf.upfronthosting.co.za>
Message-ID: <1290612667.85.0.353730083287.issue10522@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This has just occurred on the Solaris buildbot:

test_telnetlib
Exception in thread Thread-452:
Traceback (most recent call last):
  File "/home2/buildbot/slave/2.7.loewis-sun/build/Lib/threading.py", line 530, in __bootstrap_inner
    self.run()
  File "/home2/buildbot/slave/2.7.loewis-sun/build/Lib/threading.py", line 483, in run
    self.__target(*self.__args, **self.__kwargs)
  File "/home2/buildbot/slave/2.7.loewis-sun/build/Lib/test/test_telnetlib.py", line 41, in server
    conn.close()
UnboundLocalError: local variable 'conn' referenced before assignment

----------
components: Tests
messages: 122281
nosy: jackdied, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_telnet exception
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10522>
_______________________________________

From report at bugs.python.org  Wed Nov 24 16:31:10 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Nov 2010 15:31:10 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290612670.76.0.0852515974683.issue10520@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

So, you must have done a 'make install' or 'make altinstall' to get a build into /usr/local, right?  Without that of course it works fine.

You're probably still right about changing the order so it picks up the local copy first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Wed Nov 24 16:32:08 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Nov 2010 15:32:08 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290612728.88.0.317888153502.issue10520@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm bumping the status down since this likely won't affect the average user, only developers who do their own source installs.

----------
assignee:  -> barry
priority: critical -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Wed Nov 24 16:33:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 24 Nov 2010 15:33:43 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290612823.89.0.808626412832.issue10521@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The question is, what should it do with such an input? Pretend it's a single char (but other chars in the source string won't get the same treatment)? Treat it as a two-char string (but then center() and friends should logically be extended to accept strings of arbitrary lengths)?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Wed Nov 24 16:57:37 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 24 Nov 2010 15:57:37 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290614257.49.0.501207174097.issue10521@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

str.__format__ and friends (int, float, complex) also have this same problem. For example, when they're computing the "fill" character:

>>> format('', 'x^')
''

>>> format('', '\U00100140^')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Invalid conversion specification

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Wed Nov 24 17:18:05 2010
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 24 Nov 2010 16:18:05 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290615485.4.0.212057392682.issue10520@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

-L. should appear before -L/usr/local/lib.

----------
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Wed Nov 24 17:28:40 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 24 Nov 2010 16:28:40 +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: <1290616120.3.0.741545644866.issue10517@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I'm able to reliably reproduce this on a RHEL 5 box (i386 in this case).

All of the "ProcessPool*" unittest subclasses within Lib/test/test_concurrent_futures.py exhibit this hang, each printing out just the name of the first test (so presumably either within the first test method, or in shared setup/teardown).

None of the other subclasses hang.

You need to build with --with-pydebug to see this: the error message is coming from this code in PyThreadState_Swap in Python/pystate.c:

   390  #if defined(Py_DEBUG) && defined(WITH_THREAD)
   391      if (newts) {
   392          /* This can be called from PyEval_RestoreThread(). Similar
   393             to it, we need to ensure errno doesn't change.
   394          */
   395          int err = errno;
   396          PyThreadState *check = PyGILState_GetThisThreadState();
   397          if (check && check->interp == newts->interp && check != newts)
>>>398              Py_FatalError("Invalid thread state for this thread");
   399          errno = err;
   400      }
   401  #endif

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Nov 24 17:36:44 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 24 Nov 2010 16:36:44 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290616604.18.0.832631471423.issue10516@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/issue10516>
_______________________________________

From report at bugs.python.org  Wed Nov 24 17:47:25 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 24 Nov 2010 16:47:25 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1290617245.53.0.808740636943.issue4147@psf.upfronthosting.co.za>


Changes by anatoly techtonik <techtonik at gmail.com>:


----------
nosy: +techtonik

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Wed Nov 24 17:47:30 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 24 Nov 2010 16:47:30 +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: <1290617250.21.0.596404438028.issue10517@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Minimal reproducer:
$ ./python -c "from concurrent.futures import * ; e = ProcessPoolExecutor() ; e.submit(pow, 2, 5)"
Fatal Python error: Invalid thread state for this thread

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Nov 24 17:50:51 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 24 Nov 2010 16:50:51 +0000
Subject: [issue4147] xml.dom.minidom toprettyxml: omit whitespace for
	text-only elements
In-Reply-To: <1224430404.43.0.0672391440841.issue4147@psf.upfronthosting.co.za>
Message-ID: <1290617451.96.0.913192484978.issue4147@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

This one is bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4147>
_______________________________________

From report at bugs.python.org  Wed Nov 24 17:54:44 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 24 Nov 2010 16:54:44 +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: <1290617684.13.0.178262994199.issue10517@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Seems to be an issue within (or triggered by) multiprocessing (test_threads and test_threading pass OK, fwiw):
$ ./python -m test.test_multiprocessing
Fatal Python error: Invalid thread state for this thread
Traceback (most recent call last):
  File "/home/dmalcolm/coding/python-svn/py3k-clean/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/dmalcolm/coding/python-svn/py3k-clean/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/dmalcolm/coding/python-svn/py3k-clean/Lib/test/test_multiprocessing.py", line 2127, in <module>
    main()
  File "/home/dmalcolm/coding/python-svn/py3k-clean/Lib/test/test_multiprocessing.py", line 2124, in main
    test_main(unittest.TextTestRunner(verbosity=2).run)
  File "/home/dmalcolm/coding/python-svn/py3k-clean/Lib/test/test_multiprocessing.py", line 2103, in test_main
    ManagerMixin.pool = ManagerMixin.manager.Pool(4)
  File "/home/dmalcolm/coding/python-svn/py3k-clean/Lib/multiprocessing/managers.py", line 644, in temp
    token, exp = self._create(typeid, *args, **kwds)
  File "/home/dmalcolm/coding/python-svn/py3k-clean/Lib/multiprocessing/managers.py", line 542, in _create
    conn = self._Client(self._address, authkey=self._authkey)
  File "/home/dmalcolm/coding/python-svn/py3k-clean/Lib/multiprocessing/connection.py", line 149, in Client
    answer_challenge(c, authkey)
  File "/home/dmalcolm/coding/python-svn/py3k-clean/Lib/multiprocessing/connection.py", line 383, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
EOFError

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Nov 24 17:59:22 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 24 Nov 2010 16:59:22 +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: <1290617962.15.0.908717009332.issue10517@psf.upfronthosting.co.za>


Changes by ?ukasz Langa <lukasz at langa.pl>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Nov 24 18:03:43 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 24 Nov 2010 17:03:43 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290618223.93.0.00685660153015.issue10520@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Since I'm on Linux, I did a prior install into /usr/local. But I'm pretty
sure that BSD ports (which you might view as the system install) also use
/usr/local.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Wed Nov 24 18:25:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 24 Nov 2010 17:25:34 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290619534.53.0.26322986623.issue10518@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Does the plan include deprecating collections.Callable?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Wed Nov 24 18:26:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 24 Nov 2010 17:26:13 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290619573.9.0.67058075479.issue10516@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/issue10516>
_______________________________________

From report at bugs.python.org  Wed Nov 24 18:51:22 2010
From: report at bugs.python.org (SilentGhost)
Date: Wed, 24 Nov 2010 17:51:22 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290621082.38.0.0698299518675.issue10518@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

What is the reason for this? Why do we need it?

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Wed Nov 24 19:45:46 2010
From: report at bugs.python.org (gius.dima)
Date: Wed, 24 Nov 2010 18:45:46 +0000
Subject: [issue8938] Mac OS  dialogs(Save As..., Load) translation
In-Reply-To: <1275996872.25.0.17428013193.issue8938@psf.upfronthosting.co.za>
Message-ID: <1290624346.62.0.66820697736.issue8938@psf.upfronthosting.co.za>


gius.dima <gius.dima at gmail.com> added the comment:

I'm using Python 2.7, PyQt 4.8.1, qt 4.7.1 on OS X Leopard 10.6.5 and have just the same problem.
In C++ and qt all dialog's messages are in italian, in PyQt dialogs are partially in english.

----------
nosy: +gius.dima
Added file: http://bugs.python.org/file19798/pyqt_getsavefilename.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8938>
_______________________________________

From report at bugs.python.org  Wed Nov 24 19:48:13 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 24 Nov 2010 18:48:13 +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: <1290624493.24.0.0880497529097.issue10517@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

By strategically adding print() and input() calls, I was able to isolate the error to this line in test_multiprocessing.py's test_main:
   ManagerMixin.pool = ManagerMixin.manager.Pool(4)

specifically, to the construction:
  ManagerMixin.manager.Pool(4)

Minimal reproducer seems to be:
>>> import multiprocessing.managers
>>> mpp = multiprocessing.Pool(4)
>>> sm = multiprocessing.managers.SyncManager()
>>> sm.start()

i.e.:

$ ./python -c "import multiprocessing.managers ; mpp = multiprocessing.Pool(4); sm = multiprocessing.managers.SyncManager(); sm.start()"
Fatal Python error: Invalid thread state for this thread

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Wed Nov 24 19:57:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Nov 2010 18:57:48 +0000
Subject: [issue10519] setobject.c no-op typo
In-Reply-To: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>
Message-ID: <1290625068.2.0.551785312933.issue10519@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10519>
_______________________________________

From report at bugs.python.org  Wed Nov 24 20:06:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 24 Nov 2010 19:06:17 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612823.89.0.808626412832.issue10521@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=_vgBhVBnt3+4DVt7xOPEruyA=GssoZcyL_Cjx@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Nov 24, 2010 at 10:33 AM, Antoine Pitrou <report at bugs.python.org> wrote:
..
> The question is, what should it do with such an input?

I think the rule for such functions should be that if
input.encode('utf-8') is the same on wide and narrow builds, then the
output.encode('utf-8') should be the same.

> Pretend it's a single char (but other chars in the source string won't get the same treatment)?

Yes, *and* surrogate pairs in the source string should count for one
char as well.

> Treat it as a two-char string (but then center() and friends should logically be
> extended to accept strings of arbitrary lengths)?

No.  For better or worse, on wide builds these methods effectively
operate on code points.  They don't interpret multi-code-point-
graphemes or take grapheme width into account:

--------------------
?????????????????123
--------------------

Application code has to ascertain that it is dealing with with fixed
width characters in the target font before using these methods for
text alignment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Wed Nov 24 20:12:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Wed, 24 Nov 2010 19:12:47 +0000
Subject: [issue8938] Mac OS  dialogs(Save As..., Load) translation
In-Reply-To: <1275996872.25.0.17428013193.issue8938@psf.upfronthosting.co.za>
Message-ID: <1290625967.87.0.692385565979.issue8938@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/issue8938>
_______________________________________

From report at bugs.python.org  Wed Nov 24 20:13:18 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Nov 2010 19:13:18 +0000
Subject: [issue10519] setobject.c no-op typo
In-Reply-To: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>
Message-ID: <1290625998.13.0.291063859353.issue10519@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Try to match the whitespace convention of the surrounding code.

----------
assignee: rhettinger -> anthonybaxter
nosy: +anthonybaxter
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10519>
_______________________________________

From report at bugs.python.org  Wed Nov 24 20:44:55 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Nov 2010 19:44:55 +0000
Subject: [issue9807] deriving configuration information for different
	builds	with the same prefix
In-Reply-To: <1283995465.51.0.237120332009.issue9807@psf.upfronthosting.co.za>
Message-ID: <1290627895.35.0.452681553233.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r86731

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Wed Nov 24 20:45:52 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 24 Nov 2010 19:45:52 +0000
Subject: [issue10519] setobject.c no-op typo
In-Reply-To: <1290604912.22.0.805941326016.issue10519@psf.upfronthosting.co.za>
Message-ID: <1290627952.68.0.835323197584.issue10519@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

A few lines later, a similar change can be made for set_discard.

----------
assignee: anthonybaxter -> arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10519>
_______________________________________

From report at bugs.python.org  Wed Nov 24 20:55:56 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Nov 2010 19:55:56 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290628556.77.0.0719452540931.issue10521@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/issue10521>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:13:46 2010
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 24 Nov 2010 20:13:46 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290629626.75.0.274015863049.issue9509@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I'm not sure about the patch - this will convert *all* IOErrors into command line error messages, while we should really only be converting the ones raised by FileType. Instead, the try/except should be in FileType.__call__, and you should raise an ArgumentTypeError there.

The test looks fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:17:36 2010
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 24 Nov 2010 20:17:36 +0000
Subject: [issue10497] Incorrect use of gettext in argparse
In-Reply-To: <1290393086.01.0.235126341394.issue10497@psf.upfronthosting.co.za>
Message-ID: <1290629856.69.0.962684154091.issue10497@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Looks like a great fix.

And yes, anyone who knows anything about gettext, please feel free to add a test or ten. ;-) I just copied optparse when I put that stuff in, so I have no confidence in how it's done now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10497>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:22:11 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Nov 2010 20:22:11 +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: <1290630131.15.0.864910524613.issue10299@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Committed in r86732 on py3k, will backport on 3.1/2.7 if Benjamin is OK with that.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:25:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 24 Nov 2010 20:25:48 +0000
Subject: [issue10299] Add index with links section for built-in functions
In-Reply-To: <1290630131.15.0.864910524613.issue10299@psf.upfronthosting.co.za>
Message-ID: <AANLkTik461UEQ_DamMwEboD5zGTcUkXbNB-e_TuZ0eY1@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

Okay.

2010/11/24 Ezio Melotti <report at bugs.python.org>:
>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> Committed in r86732 on py3k, will backport on 3.1/2.7 if Benjamin is OK with that.
>
> ----------
> nosy: +benjamin.peterson
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10299>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:26:24 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 24 Nov 2010 20:26:24 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1290630384.96.0.290036520808.issue8879@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Removing link to #10027. It's fixed for py3k but the issue should stay open for backport to other branches.

----------
dependencies:  -os.lstat/os.stat don't set st_nlink on Windows
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:26:48 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 24 Nov 2010 20:26:48 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1290630408.66.0.0351607751448.issue8879@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in r86733.

----------
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:30:20 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Nov 2010 20:30:20 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290630620.45.0.668098696011.issue10520@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r86734

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:31:00 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 24 Nov 2010 20:31:00 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290630660.43.0.540334115723.issue10520@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

BTW, I am not sure it's worth backporting this to 3.1 and 2.7.  It seems like a corner case that will not affect most users.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:35:13 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Nov 2010 20:35:13 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290630913.87.0.807686460466.issue10518@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I'm not sure it's worth bringing callable() back at this point.
It would have made more sense for 3.1, but now we already have 2  callable()-less versions of Python if we do it for 3.2 (what about the moratorium though?) or 3 if we do it for 3.3.  Also if isinstance(obj, collections.Callable) is correct in what it does, it's trivial to do something like:

def callable(obj):
  return isinstance(obj, collections.Callable)


If it goes in the `iscallable` name suggested on python-dev might be better (IMHO).  At least people will realize that it's something "new" and don't assume that the old callable() has been there all the time (it also clear that it returns a boolean and reads better in e.g. `if iscallable(obj): ...`).
(The patch should also include an entry in the table at the top of functions.rst now that I committed #10299 in r86732.)

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:37:51 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 24 Nov 2010 20:37:51 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <4CED7798.3080901@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Alexander Belopolsky wrote:
> 
> New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:
> 
>>>> 'xyz'.center(20, '\U00100140')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: The fill character must be exactly one character long
> 
> str.ljust and str.rjust are similarly affected.

I don't think we should change that for the formatting methods.

See my reply on python-dev:

str.center(n) centers the string in a padded string that
is composed of n code units. Whether that operation will result
in a text that's centered visually on output is a completely
different story. The original string could contain surrogates,
it could also contain combing code points, so the visual
presentation of the result may very well not be centered at
all; it may not even appear as having the length n to the user.

Since we're not going change the semantics of those APIs,
it is OK to not support padding with non-BMP code points on
UCS-2 builds.

Supporting such cases would only cause problems:

* if the methods would pad with surrogates, the resulting
  string would no longer have length n; breaking the
  assumption that len(str.center(n)) == n

* if the methods would pad with half the number of surroagtes
  to make sure that len(str.center(n)) == n, the resulting
  output to e.g. a terminal would be further off, than what
  you already have with surrogates and combining code points
  in the original string.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:39:05 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Nov 2010 20:39:05 +0000
Subject: [issue8938] Mac OS  dialogs(Save As..., Load) translation
In-Reply-To: <1275996872.25.0.17428013193.issue8938@psf.upfronthosting.co.za>
Message-ID: <1290631145.06.0.175106642743.issue8938@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

There seem to be several different issues being reported here.  As far as I can tell, the only issue that directly relates to code in the Python standard library is the lack of internationalization for EasyDialogs.  EasyDialogs depends on deprecated OS X Carbon interfaces that do not exist in 64-bit mode.  For that reason, EasyDialogs is itself deprecated and has been removed in Python 3; further, new features are not being added in Python 2.  All the other issues mentioned have to do with 3rd-party packages like Aqua Tk (which as far as I can tell, does not ship with i18n resources for its GUI interfaces like the file dialogs) and PyQt.  Those issues should be pursued with those other projects.

----------
nosy: +ned.deily
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8938>
_______________________________________

From report at bugs.python.org  Wed Nov 24 21:42:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 24 Nov 2010 20:42:19 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290631339.61.0.892193369884.issue10520@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +benjamin.peterson, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Wed Nov 24 22:07:01 2010
From: report at bugs.python.org (Martin Budaj)
Date: Wed, 24 Nov 2010 21:07:01 +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: <1290632821.44.0.690735215151.issue10515@psf.upfronthosting.co.za>


Martin Budaj <m.budaj at gmail.com> added the comment:

Units test and two patches for 2.7 are included.

p1.patch fixes testEnd case reported yesterday

After running unittest it seems that also other case is broken (testAl -- if there is just one data item on the line, enclosed in quotes). Patch p2 fixes it, but should be checked for side-effects.

----------
Added file: http://bugs.python.org/file19799/fix.tar.gz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Wed Nov 24 22:23:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 24 Nov 2010 21:23:59 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <4CED7798.3080901@egenix.com>
Message-ID: <AANLkTikTkKbPG-D-jOe1YzzTZivg+WpV-CtkpctBcXKw@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Nov 24, 2010 at 3:37 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> I don't think we should change that for the formatting methods.

That's a reasonable position.  What about

'Lo'
>>> '\N{OLD ITALIC LETTER A}'.isalpha()
False

the str.isalpha() method is underspecified in the reference manual,
but a comment in unicodectype.c describes Py_UNICODE_ISALPHA as
follows:

/* Returns 1 for Unicode characters having the category 'Ll', 'Lu',
'Lt',
   'Lo' or 'Lm',  0 otherwise. */

I don't have a wide build handy, but I am fairly sure  '\N{OLD ITALIC
LETTER A}'.isalpha() would produce True there.  The result above is
simply consequence of surrogates considered to be non-letters:

[False, False]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Wed Nov 24 22:47:47 2010
From: report at bugs.python.org (Michal Pomorski)
Date: Wed, 24 Nov 2010 21:47:47 +0000
Subject: [issue10523] argparse has problem parsing option files containing
	empty rows
In-Reply-To: <1290635267.13.0.585990858581.issue10523@psf.upfronthosting.co.za>
Message-ID: <1290635267.13.0.585990858581.issue10523@psf.upfronthosting.co.za>


New submission from Michal Pomorski <misieck at gmail.com>:

When using the argument file option, i.e  @file_with_arguments the following problems arise:

1. argparse crashes when the file contains an empty line (even if it is the last line) - arg_string[0] is done when arg_string is empty. 
    This is caused by the use of splitlines() instead of strip().split() in the function _read_args_from_files(self, arg_strings)

2. options separated by spaces in one row are passed as a single long option, meaning each option has to be on its own line.
    This is caused by the new function 
   def convert_arg_line_to_args(self, arg_line):
        return [arg_line]
   which should be 
        return arg_line.split()


Both problems are caused by a modification in
    def _read_args_from_files(self, arg_strings)
The version from argparse 1.0.1 worked well and was correct, it should be sufficient to reverse the changes done from 1.0.1 to 1.1.

Here is the old implementation:

    def _read_args_from_files(self, arg_strings):
        # expand arguments referencing files
        new_arg_strings = []
        for arg_string in arg_strings:

            # for regular arguments, just add them back into the list
            if arg_string[0] not in self.fromfile_prefix_chars:
                new_arg_strings.append(arg_string)

            # replace arguments referencing files with the file content
            else:
                try:
                    args_file = open(arg_string[1:])
                    try:
                        arg_strings = args_file.read().strip().split()
                        arg_strings = self._read_args_from_files(arg_strings)
                        
                        new_arg_strings.extend(arg_strings)
                    finally:
                        args_file.close()
                except IOError:
                    err = _sys.exc_info()[1]
                    self.error(str(err))

        # return the modified argument list
        return new_arg_strings

----------
components: Library (Lib)
messages: 122314
nosy: Michal.Pomorski
priority: normal
severity: normal
status: open
title: argparse has problem parsing option files containing empty rows
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10523>
_______________________________________

From report at bugs.python.org  Wed Nov 24 22:48:06 2010
From: report at bugs.python.org (Michal Pomorski)
Date: Wed, 24 Nov 2010 21:48:06 +0000
Subject: [issue10523] argparse has problem parsing option files containing
	empty rows
In-Reply-To: <1290635267.13.0.585990858581.issue10523@psf.upfronthosting.co.za>
Message-ID: <1290635286.58.0.496544697573.issue10523@psf.upfronthosting.co.za>


Changes by Michal Pomorski <misieck at gmail.com>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10523>
_______________________________________

From report at bugs.python.org  Wed Nov 24 23:00:25 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Nov 2010 22:00:25 +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: <1290636025.85.0.519172398288.issue10515@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file19800/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Wed Nov 24 23:00:29 2010
From: report at bugs.python.org (=?utf-8?b?T251ciBLw7zDp8O8aw==?=)
Date: Wed, 24 Nov 2010 22:00:29 +0000
Subject: [issue10524] Patch to add Pardus to supported dists in platform
In-Reply-To: <1290636029.57.0.718093237455.issue10524@psf.upfronthosting.co.za>
Message-ID: <1290636029.57.0.718093237455.issue10524@psf.upfronthosting.co.za>


New submission from Onur K???k <onur at pardus.org.tr>:

Attached patch adds Pardus to supported dists in platform. Diff is against current release27-maint, but it applies to release31-maint and py3k too.

----------
components: Library (Lib)
files: pardus_platform_release27-maint.patch
keywords: patch
messages: 122315
nosy: zaburt
priority: normal
severity: normal
status: open
title: Patch to add Pardus to supported dists in platform
Added file: http://bugs.python.org/file19801/pardus_platform_release27-maint.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10524>
_______________________________________

From report at bugs.python.org  Wed Nov 24 23:01:41 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Nov 2010 22:01: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: <1290636101.36.0.86095999402.issue10515@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19802/p1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Wed Nov 24 23:04:23 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 24 Nov 2010 22:04:23 +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: <1290636263.88.0.942559690659.issue10515@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Thanks. I've unpacked and uploaded the three files from your tar file.)

----------
stage: unit test needed -> patch review
Added file: http://bugs.python.org/file19803/p2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10515>
_______________________________________

From report at bugs.python.org  Wed Nov 24 23:06:23 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 24 Nov 2010 22:06:23 +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: <1290636383.15.0.934548497911.issue10299@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Backported in r86735 (3.1) and r86736 (2.7).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Wed Nov 24 23:52:08 2010
From: report at bugs.python.org (SilentGhost)
Date: Wed, 24 Nov 2010 22:52:08 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290639128.33.0.191612812514.issue5800@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Here is the correction for the docs. I would love to see this making it into 3.2 release.

----------
Added file: http://bugs.python.org/file19804/wsgiref.rst.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Thu Nov 25 01:11:33 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Nov 2010 00:11:33 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1290643893.19.0.596666408364.issue8879@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch uses the ANSI version, and converts the filename from unicode to bytes; this will fail for names that cannot be encoded with the "mbcs" codec.

All other functions in the posix module first try the Wide version of the win32 API, and use the ANSI version as a fallback, when the argument is a bytes string. PyUnicode_FSConverter should be avoided on Windows. See posix_mkdir() for a good example.

Here is an example that fails on a Western Windows (where ANSI=cp1252).  Note that even the file name is not encodable in mbcs, it is correctly displayed in the Explorer for example.

>>> name = "\u65e5\u672c"     # "Japan"
>>> open(name, "w").close()   # Appears correctly in the explorer
>>> import os
>>> os.link(name, name + "_1")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'mbcs' codec can't encode characters in position 0--1: invalid character

----------
nosy: +amaury.forgeotdarc
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Thu Nov 25 01:13:15 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 25 Nov 2010 00:13:15 +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: <1290643995.09.0.624878697988.issue10517@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

FWIW, I was able to do an almost full run of regrtest on this box with:
  -x test_multiprocessing test_concurrent_futures

Other than those two, all tests pass.

So _something_ is going wrong w.r.t. threads, though I'm not sure what at this stage.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10517>
_______________________________________

From report at bugs.python.org  Thu Nov 25 01:25:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Nov 2010 00:25:25 +0000
Subject: [issue3063] memory leak in random number generation
In-Reply-To: <1212939967.99.0.941797469942.issue3063@psf.upfronthosting.co.za>
Message-ID: <1290644725.39.0.940205390772.issue3063@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

For the record, this was finally fixed with issue2862: gc.collect() now clears the free-lists during the collection of the highest generation.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3063>
_______________________________________

From report at bugs.python.org  Thu Nov 25 01:35:03 2010
From: report at bugs.python.org (SilentGhost)
Date: Thu, 25 Nov 2010 00:35:03 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290645303.66.0.99316351005.issue9509@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Attached patch with the try-except clause as suggested by Steven, Doug's example now produces the following output:

$ ./python argparse_filetype_error.py
usage: argparse_filetype_error.py [-h] [-i I]
argparse_filetype_error.py: error: no such file or directory 'file-does-not-exist.txt'

I have digressed and fixed an issue with _bufsize 0. I thought it would be just natural to default to -1 which is default buffering size for a simple open call anyway. It also makes for a cleaner try-except clause. All tests pass, including akira's.

----------
nosy: +SilentGhost
Added file: http://bugs.python.org/file19805/argparse.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Thu Nov 25 02:33:04 2010
From: report at bugs.python.org (Ramiro Batista da Luz)
Date: Thu, 25 Nov 2010 01:33:04 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290648784.07.0.924566492667.issue5800@psf.upfronthosting.co.za>


Ramiro Batista da Luz <ramiroluz at gmail.com> added the comment:

I reviewed the patch.

 - I applied all the patchs(3 files).
 - Ran make and make html in the Doc directory.
 - Ran the test_wsgiref.py
 - Ran the python interpreter and typed the suggested code:

>>> from wsgiref.headers import Headers
>>> headers = Headers([])
>>> headers.add_header('Content-Type', 'text/plain')
>>> headers = Headers()
>>> headers.add_header('Content-Type', 'text/plain')
>>> 

 - Read the documentation in a web browser.

All in the revision 86742.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Thu Nov 25 03:01:51 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 25 Nov 2010 02:01:51 +0000
Subject: [issue10027] os.lstat/os.stat don't set st_nlink on Windows
In-Reply-To: <1286289327.29.0.159315245099.issue10027@psf.upfronthosting.co.za>
Message-ID: <1290650511.55.0.922949092241.issue10027@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you for commit!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Thu Nov 25 03:12:40 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Thu, 25 Nov 2010 02:12:40 +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: <1290651160.35.0.511925652784.issue10154@psf.upfronthosting.co.za>


Changes by MunSic JEONG <ruseel at gmail.com>:


----------
nosy: +ruseel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Thu Nov 25 04:31:01 2010
From: report at bugs.python.org (akira)
Date: Thu, 25 Nov 2010 03:31:01 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290655861.61.0.461140998342.issue9509@psf.upfronthosting.co.za>


akira <4kir4.1i at gmail.com> added the comment:

I've added tests for readonly files. SilentGhost's patch doesn't handle this case.

----------
Added file: http://bugs.python.org/file19806/test_argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Thu Nov 25 04:40:57 2010
From: report at bugs.python.org (akira)
Date: Thu, 25 Nov 2010 03:40:57 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290656457.76.0.658055909066.issue9509@psf.upfronthosting.co.za>


akira <4kir4.1i at gmail.com> added the comment:

Attached patch for argparse.py (argparse.diff -- without tests, see tests in test_argparse.diff) where ValueError is raises in FileType.__call__ and additional details printed on ArgumentError

----------
Added file: http://bugs.python.org/file19807/argparse.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Thu Nov 25 05:08:56 2010
From: report at bugs.python.org (akira)
Date: Thu, 25 Nov 2010 04:08:56 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290658136.97.0.434646817983.issue9509@psf.upfronthosting.co.za>


akira <4kir4.1i at gmail.com> added the comment:

updated patch on http://codereview.appspot.com/3251041/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Thu Nov 25 05:13:50 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 25 Nov 2010 04:13:50 +0000
Subject: [issue8481] doc: ctypes no need to explicitly allocate writable
	memory with Structure
In-Reply-To: <1271834227.47.0.0148350492358.issue8481@psf.upfronthosting.co.za>
Message-ID: <1290658430.57.0.178415379666.issue8481@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

I think not only Structures but also other ctypes can be passed with byref() to functions expecting pointer to mutable memory.

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8481>
_______________________________________

From report at bugs.python.org  Thu Nov 25 06:01:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 25 Nov 2010 05:01:40 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290661300.37.0.975605523775.issue10521@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Nov 24, 2010 at 3:37 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> I don't think we should change that for the formatting methods.

That's a reasonable position.  What about

>>> unicodedata.category('\N{OLD ITALIC LETTER A}')
'Lo'
>>> '\N{OLD ITALIC LETTER A}'.isalpha()
False

the str.isalpha() method is underspecified in the reference manual,
but a comment in unicodectype.c describes Py_UNICODE_ISALPHA as
follows:

/* Returns 1 for Unicode characters having the category 'Ll', 'Lu',
'Lt',
  'Lo' or 'Lm',  0 otherwise. */

I don't have a wide build handy, but I am fairly sure  '\N{OLD ITALIC
LETTER A}'.isalpha() would produce True there.  The result above is
simply consequence of surrogates considered to be non-letters:

>>> [c.isalpha() for c in '\N{OLD ITALIC LETTER A}']
[False, False]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Thu Nov 25 06:01:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 25 Nov 2010 05:01:52 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290661312.79.0.809743889453.issue10521@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg122313

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Thu Nov 25 06:04:00 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 25 Nov 2010 05:04:00 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290661440.41.0.514759656337.issue10521@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Here is another str method not ready for non-BMP chars:


>>> u = '\U00010140'
>>> u.translate({ord(u):ord('A')})
'?'

(expected 'A')

>>> u = 'B'
>>> u.translate({ord(u):ord('A')})
'A'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Thu Nov 25 06:10:44 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 25 Nov 2010 05:10:44 +0000
Subject: [issue10402] sporadic test_bsddb3 failures
In-Reply-To: <1289609497.28.0.489511317462.issue10402@psf.upfronthosting.co.za>
Message-ID: <1290661844.53.0.853109671706.issue10402@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This should be duplicate of #3892.

I suppose timeout in this test might be very short. Refers to
http://www.systomath.eu/doc/BerkeleyDb-4.7/html/api_c/rep_timeout.html
timeout is in microseconds, so
  self.dbenvMaster.rep_set_timeout(db.DB_REP_CONNECTION_RETRY,100123)
means only 100 milliseconds. (I don't know BSDDB entirely, so maybe this
might be valid value though)

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10402>
_______________________________________

From report at bugs.python.org  Thu Nov 25 06:44:22 2010
From: report at bugs.python.org (Dafydd Crosby)
Date: Thu, 25 Nov 2010 05:44:22 +0000
Subject: [issue10525] Added mouse and colour support to Game of Life curses
	demo
In-Reply-To: <1290663861.94.0.159219260836.issue10525@psf.upfronthosting.co.za>
Message-ID: <1290663861.94.0.159219260836.issue10525@psf.upfronthosting.co.za>


New submission from Dafydd Crosby <dtcrsby at gmail.com>:

I was just going through the source of the curses demo Game of Life (life.py), and saw that the TODO had mouse support and colour.

I created a patch that adds those two wishlist items. Given that mouse support and the use of curses.flash() are missing from the demo programs, I think it's a bit of an upgrade ;-)

----------
components: Demos and Tools
files: mouse_and_colour.diff
keywords: patch
messages: 122332
nosy: Dafydd.Crosby
priority: normal
severity: normal
status: open
title: Added mouse and colour support to Game of Life curses demo
type: behavior
Added file: http://bugs.python.org/file19808/mouse_and_colour.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10525>
_______________________________________

From report at bugs.python.org  Thu Nov 25 07:07:39 2010
From: report at bugs.python.org (Ray.Allen)
Date: Thu, 25 Nov 2010 06:07:39 +0000
Subject: [issue9014] Incorrect documentation of the PyObject_HEAD macro
In-Reply-To: <1276718330.85.0.16685449654.issue9014@psf.upfronthosting.co.za>
Message-ID: <1290665259.1.0.309052164137.issue9014@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Additionally, I prefer move the discussion of Py_TRACE_REFS under the documentation of PyObject: http://docs.python.org/dev/py3k/c-api/structures.html?highlight=pyobject_head#PyObject, since they'are connected directly. The doc of PyObject_HEAD should only saying like "expands to a PyObject variable".

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9014>
_______________________________________

From report at bugs.python.org  Thu Nov 25 07:11:32 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 25 Nov 2010 06:11:32 +0000
Subject: [issue10525] Added mouse and colour support to Game of Life
	curses	demo
In-Reply-To: <1290663861.94.0.159219260836.issue10525@psf.upfronthosting.co.za>
Message-ID: <20101125061119.GB1239@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Thu, Nov 25, 2010 at 05:44:21AM +0000, Dafydd Crosby wrote:
> I created a patch that adds those two wishlist items. Given that
> mouse support and the use of curses.flash() are missing from the
> demo programs, I think it's a bit of an upgrade ;-)
> 

Pretty cool. Do you think, the '*' themselves should be colored or
randomly colored? ( No, I have not seen a Game of 'Random-Colored' life )

----------
nosy: +orsenthil
title: Added mouse and colour support to Game of Life curses demo -> Added mouse and colour support to Game of Life curses	demo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10525>
_______________________________________

From report at bugs.python.org  Thu Nov 25 07:27:30 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 25 Nov 2010 06:27:30 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1290666450.16.0.484428901116.issue2986@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since I am not sure I will be able to do any more before the 3.2b1 feature freeze, I went ahead with the minimal patch after checking the differences from the 2.7 version and redoing the Misc/News entry.
(I suspect putting a new entry immediately after the appropriate heading, instead of between other headings, is probably least likely to fatally conflict with intervening changes.) r86745 Thank you Eli and Simon.

Leaving this open for possible further changes.

----------
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Thu Nov 25 07:28:50 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 25 Nov 2010 06:28:50 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290666530.87.0.824189289576.issue10521@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think that methods like str.isalpha can and should be fixed. Since _PyUnicode_IsAlpha now accepts a Py_UCS4, the body of unicode_isalpha can be changed to convert normal chars and surrogates pairs to a Py_UCS4 before calling Py_UNICODE_ISALPHA.
The attached patch is a proof of concept of this approach and returns True for '\N{OLD ITALIC LETTER A}'.isalpha() on a narrow build.
It still has a number of issues that should be addressed (check for narrow builds, check for lone surrogates, check for high surrogate at the end of a string, fix compiler warnings ...) but it should be good enough as a PoC.

I would also suggest to introduce a set of macros to handle surrogates (e.g. detect, combine) and use it in all the functions that need to work with them.

----------
keywords: +patch
Added file: http://bugs.python.org/file19809/issue10521-isalpha.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Thu Nov 25 07:48:03 2010
From: report at bugs.python.org (Simon Cross)
Date: Thu, 25 Nov 2010 06:48:03 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1290667683.95.0.346278773192.issue2986@psf.upfronthosting.co.za>


Simon Cross <hodgestar at gmail.com> added the comment:

My vote is that this bug be closed and a new feature request be opened. Failing that, it would be good to have a concise description of what else we would like done (and the priority should be downgraded, I guess).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Thu Nov 25 07:59:25 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Thu, 25 Nov 2010 06:59:25 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1290668365.22.0.789761779277.issue2986@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Terry, I agree with Simon re closing and opening a new feature request. This issue has too much baggage in it, and you we always link to it. A new feature request should be opened strictly for 3.2

If you want I can close this issue and open a new one, but I'm waiting for your approval.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Thu Nov 25 08:13:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 25 Nov 2010 07:13:26 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290669206.16.0.491013770926.issue10521@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Here is another proof of concept patch for the isalpha issue that introduces a higher level abstraction macro - Py_UNICODE_NEXT.  It should be possible to reuse this macro in all isxyz methods and other places where surrogates are currently processed.  I should be possible to come up with a pure macro definition of Py_UNICODE_NEXT.

----------
Added file: http://bugs.python.org/file19810/issue10521-unicode-next.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Thu Nov 25 08:31:12 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 25 Nov 2010 07:31:12 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290670272.91.0.779347180607.issue10521@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Thu Nov 25 08:44:38 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 25 Nov 2010 07:44:38 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290671078.24.0.431035137026.issue10521@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

issue9200 already proposes a similar change to str.is* methods.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Thu Nov 25 08:58:05 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 25 Nov 2010 07:58:05 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1290671885.03.0.762931321309.issue8879@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

r86733 introduces st_ino setup in attribute_data_to_stat(),
but Fild ID is not guaranteed to be same when file is not opened.
So I think it's meaningful only for os.fstat().

Please see
http://msdn.microsoft.com/en-us/library/aa363788%28v=VS.85%29.aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Thu Nov 25 09:43:51 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 25 Nov 2010 08:43:51 +0000
Subject: [issue1508475] transparent gzip compression in urllib
In-Reply-To: <1290547588.69.0.556301961789.issue1508475@psf.upfronthosting.co.za>
Message-ID: <20101125084336.GE1239@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The transparent gzip Content-Encoding support should be done at the
http.client level code.

Before adding this feature, a question needs to be sorted out.

If we support the transparent gzip and wrap the file pointer to a
GzipFile filepointer, should reset the Content-Length value?

What if a user of urllib is relying on the Content-Length of response
to do something further?

I observed that google-chrome returns the uncompressed output (which
is correct for a browser), but has the Content-Length set the
compressed output length.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1508475>
_______________________________________

From report at bugs.python.org  Thu Nov 25 09:49:50 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 25 Nov 2010 08:49:50 +0000
Subject: [issue1508475] transparent gzip compression in urllib
Message-ID: <1290674990.75.0.381850412176.issue1508475@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Patch for py3k.

----------
stage: unit test needed -> patch review
Added file: http://bugs.python.org/file19811/issue1508475.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1508475>
_______________________________________

From report at bugs.python.org  Thu Nov 25 09:53:54 2010
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 25 Nov 2010 08:53:54 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1290675234.31.0.613131292494.issue10399@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

> But this seems to me like a contrived example: how often in real
> code do people pass around these builtins, rather than calling
> them directly?

>From experience developing PyPy, every argument that goes "this theoretically breaks obscure code, but who writes it in that way?" is inherently broken: there *is* code out there that uses any and all Python strangenesses.  The only trade-offs you can make is in how much existing code you are going to break -- or make absolutely sure that you don't change semantics in any case.

----------
nosy: +arigo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Thu Nov 25 10:49:43 2010
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Thu, 25 Nov 2010 09:49:43 +0000
Subject: [issue10399] AST Optimization: inlining of function calls
In-Reply-To: <1289593012.28.0.71054855235.issue10399@psf.upfronthosting.co.za>
Message-ID: <1290678583.81.0.792926900876.issue10399@psf.upfronthosting.co.za>


Changes by Maciej Fijalkowski <fijall at gmail.com>:


----------
nosy: +fijall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10399>
_______________________________________

From report at bugs.python.org  Thu Nov 25 10:56:13 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 25 Nov 2010 09:56:13 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290678973.51.0.496980119878.issue10518@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

I was originally surprised to find that callable() was gone. I pointed it out at Europython and got a very informative explanation from Brett. The isinstance(obj, collections.Callable) was introduced and it works well.

I'm with Ezio here. I'm -1 for callable(), +0 for iscallable() (there should be preferably one obvious way to do it and using isinstance() seems to be that way at this point).

----------
nosy: +brett.cannon, lukasz.langa

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Thu Nov 25 11:27:53 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 25 Nov 2010 10:27:53 +0000
Subject: [issue10122] Documentation typo fix and a side question
In-Reply-To: <1290155996.63.0.683219536399.issue10122@psf.upfronthosting.co.za>
Message-ID: <20101125102735.GA1048@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Bo?tjan, it is fixed. The change will reflect when the docs get served
from the updated version. 

Also, Georg will take care of merging it to other branches.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10122>
_______________________________________

From orsenthil at gmail.com  Thu Nov 25 11:27:36 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Thu, 25 Nov 2010 18:27:36 +0800
Subject: [issue10122] Documentation typo fix and a side question
In-Reply-To: <1290155996.63.0.683219536399.issue10122@psf.upfronthosting.co.za>
References: <1287238144.34.0.432770346734.issue10122@psf.upfronthosting.co.za>
	<1290155996.63.0.683219536399.issue10122@psf.upfronthosting.co.za>
Message-ID: <20101125102735.GA1048@rubuntu>


Bo?tjan, it is fixed. The change will reflect when the docs get served
from the updated version. 

Also, Georg will take care of merging it to other branches.

From report at bugs.python.org  Thu Nov 25 11:45:42 2010
From: report at bugs.python.org (Petter Remen)
Date: Thu, 25 Nov 2010 10:45:42 +0000
Subject: [issue10526] Minor typo in What's New in Python 2.7
In-Reply-To: <1290681942.88.0.460201126168.issue10526@psf.upfronthosting.co.za>
Message-ID: <1290681942.88.0.460201126168.issue10526@psf.upfronthosting.co.za>


New submission from Petter Remen <petter.remen at gmail.com>:

There's a word missing in section "PEP 372: Adding an Ordered Dictionary to collections"

The ConfigParser module uses them by default, meaning that
configuration files can now read, modified, and then written [...]
                        ~~~~~~~~

should be "now be read".

----------
assignee: docs at python
components: Documentation
messages: 122347
nosy: Petter.Remen, docs at python
priority: normal
severity: normal
status: open
title: Minor typo in What's New in Python 2.7
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10526>
_______________________________________

From report at bugs.python.org  Thu Nov 25 12:14:23 2010
From: report at bugs.python.org (Nadeem Vawda)
Date: Thu, 25 Nov 2010 11:14:23 +0000
Subject: [issue10512] regrtest ResourceWarning - unclosed sockets and files
In-Reply-To: <1290506536.77.0.313292165719.issue10512@psf.upfronthosting.co.za>
Message-ID: <1290683663.63.0.434532872969.issue10512@psf.upfronthosting.co.za>


Nadeem Vawda <nadeem.vawda at gmail.com> added the comment:

test_cgi causes a strange filehandle leak that only causes a warning when regrtest terminates, and for some reason doesn't show up if you run just test_cgi by itself.  I've attached a patch that closes the filehandle.

----------
nosy: +lukasz.langa
Added file: http://bugs.python.org/file19812/resourcewarning-fixes-3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10512>
_______________________________________

From report at bugs.python.org  Thu Nov 25 12:15:13 2010
From: report at bugs.python.org (=?utf-8?q?Gergely_K=C3=A1lm=C3=A1n?=)
Date: Thu, 25 Nov 2010 11:15:13 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>


New submission from Gergely K?lm?n <kalman.gergely at duodecad.hu>:

Hello,

I have a code that uses multiprocessing.Pipe to communicate with subprocesses. Spawning 500 subprocesses this way works like a charm, but when spawning about 600 of them the pipe ends raise the exception: "handle out of range in select()". I realized that this is because of the FD_SETSIZE limit. To address the situation I quickly hacked together a patch that uses poll() instead of select(), which solves the problem for me. I don't know the reason why select() was chosen for this task (maybe because of windows) but wouldn't it be better to use polling where possible?

I've attached the tester. Beware, running it may use up all memory in your system, so be careful!

Gergely Kalman

----------
components: Library (Lib)
files: tester.py
messages: 122349
nosy: synapse
priority: normal
severity: normal
status: open
title: multiprocessing.Pipe problem: "handle out of range in select()"
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19813/tester.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Thu Nov 25 12:16:12 2010
From: report at bugs.python.org (=?utf-8?q?Gergely_K=C3=A1lm=C3=A1n?=)
Date: Thu, 25 Nov 2010 11:16:12 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1290683772.77.0.336902733049.issue10527@psf.upfronthosting.co.za>


Gergely K?lm?n <kalman.gergely at duodecad.hu> added the comment:

And this is the patch that I wrote.

It applies to python 3.2.

Hope this helps

Gergely Kalman

----------
keywords: +patch
Added file: http://bugs.python.org/file19814/multiproc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Thu Nov 25 12:30:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 11:30:27 +0000
Subject: [issue5800] make wsgiref.headers.Headers accept empty constructor
In-Reply-To: <1240243265.38.0.0946630520568.issue5800@psf.upfronthosting.co.za>
Message-ID: <1290684627.51.0.349410322086.issue5800@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

LGTM.

----------
assignee:  -> pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5800>
_______________________________________

From report at bugs.python.org  Thu Nov 25 12:39:01 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 25 Nov 2010 11:39:01 +0000
Subject: [issue10362] AttributeError: addinfourl instance has no attribute
	'tell'
In-Reply-To: <1289237897.0.0.279670034262.issue10362@psf.upfronthosting.co.za>
Message-ID: <1290685141.95.0.669915134969.issue10362@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

If you want to quickly solve this, do like this:

import urllib
import tarfile

tarfile.open(urllib.urlretrieve('http://plugins.supybot-fr.tk/GoodFrench.tar')[0], mode='r:') # Works

The problem is tarfile is expecting a "file-object" with a tell method for seeking, whereas urllib2 returns a file-like object, which does have a tell method. It seems to not have because, the underlying socket._fileobject is not exposing one (for whatever reason). Let me try to figure out reason for fixing/closing this bug.
(BTW, http module is relying on .tell() of the socket._fileobject too and I wonder it did not get noticed earlier because the has not taken that path yet? Strange!)

----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10362>
_______________________________________

From report at bugs.python.org  Thu Nov 25 12:56:08 2010
From: report at bugs.python.org (SilentGhost)
Date: Thu, 25 Nov 2010 11:56:08 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290686168.9.0.65520418404.issue9509@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Ammended akira's patch for Lib/test/test_argparse.py to include suggested in review changes: with statement, import statement

----------
Added file: http://bugs.python.org/file19815/test_argparse.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Thu Nov 25 12:58:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 11:58:39 +0000
Subject: [issue10524] Patch to add Pardus to supported dists in platform
In-Reply-To: <1290636029.57.0.718093237455.issue10524@psf.upfronthosting.co.za>
Message-ID: <1290686319.43.0.454567081648.issue10524@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, lemburg
type:  -> feature request
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10524>
_______________________________________

From report at bugs.python.org  Thu Nov 25 13:11:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 12:11:55 +0000
Subject: [issue10497] Incorrect use of gettext in argparse
In-Reply-To: <1290393086.01.0.235126341394.issue10497@psf.upfronthosting.co.za>
Message-ID: <1290687115.29.0.292873846287.issue10497@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A bit of rationale behind the patch.  You probably know that the gettext/_ functions serves two roles: Identifying the strings to translate, and retrieving the translation from a catalog.

At strings extraction time, the string in the line
            msg = _('unknown parser %r (choices: %s)' % tup)
will be found by xgettext (just checked), so the .pot and .po files will include it.  So far, so good.

At runtime however, the gettext function will get "unknown parser 'parserr' (choices: ('some', 'tuple'))" as argument, which isn?t in the translation catalogs.  Doing the string interpolation after the gettext call (my patch) avoids this problem.

I will write a test for those two strings.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10497>
_______________________________________

From report at bugs.python.org  Thu Nov 25 13:23:35 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 25 Nov 2010 12:23:35 +0000
Subject: [issue10524] Patch to add Pardus to supported dists in platform
In-Reply-To: <1290636029.57.0.718093237455.issue10524@psf.upfronthosting.co.za>
Message-ID: <1290687815.42.0.252577313453.issue10524@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Looks good.

BTW: What is "pardus" ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10524>
_______________________________________

From report at bugs.python.org  Thu Nov 25 13:25:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 12:25:39 +0000
Subject: [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

When you run xgettext other argparse.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.?

I don?t know if people already rely on strings from argparse, but for safety I think we should change them only in 3.2, if Steven agrees.

(I have to check other stdlib modules.)

----------
components: Library (Lib)
messages: 122357
nosy: belopolsky, bethard, eric.araujo
priority: normal
severity: normal
status: open
title: argparse uses %s in gettext calls
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10528>
_______________________________________

From report at bugs.python.org  Thu Nov 25 13:28:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 12:28:09 +0000
Subject: [issue10529] Write argparse i18n howto
In-Reply-To: <1290688089.28.0.749623528369.issue10529@psf.upfronthosting.co.za>
Message-ID: <1290688089.28.0.749623528369.issue10529@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

argparse helpfully makes its messages with gettext.gettext.  The docs should explain how to benefit from that in one?s program.

----------
assignee: docs at python
components: Documentation
messages: 122358
nosy: bethard, docs at python, eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Write argparse i18n howto
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10529>
_______________________________________

From report at bugs.python.org  Thu Nov 25 13:30:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 12:30:51 +0000
Subject: [issue10529] Write argparse i18n howto
In-Reply-To: <1290688089.28.0.749623528369.issue10529@psf.upfronthosting.co.za>
Message-ID: <1290688251.66.0.336880414485.issue10529@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

s/makes/marks/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10529>
_______________________________________

From report at bugs.python.org  Thu Nov 25 13:37:44 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Nov 2010 12:37:44 +0000
Subject: [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1290688664.05.0.809517085659.issue10528@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/issue10528>
_______________________________________

From report at bugs.python.org  Thu Nov 25 13:54:11 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 25 Nov 2010 12:54:11 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1290689651.21.0.0794369533603.issue9915@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/issue9915>
_______________________________________

From report at bugs.python.org  Thu Nov 25 14:16:27 2010
From: report at bugs.python.org (=?utf-8?q?Miroslav_Such=C3=BD?=)
Date: Thu, 25 Nov 2010 13:16:27 +0000
Subject: [issue9664] Make gzip module not require that underlying file object
	support seek
In-Reply-To: <1282550810.11.0.164823540463.issue9664@psf.upfronthosting.co.za>
Message-ID: <1290690987.65.0.512895910119.issue9664@psf.upfronthosting.co.za>


Miroslav Such? <msuchy at redhat.com> added the comment:

I'm proposing GzipStream class which inherit from gzip.GzipFile and handle streaming gzipped data.

You can use this module under both Python or GPLv2 license.

We use this module under python 2.6. Not sure if it will work under Python3.

----------
nosy: +msuchy at redhat.com
Added file: http://bugs.python.org/file19816/gzipstream.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9664>
_______________________________________

From report at bugs.python.org  Thu Nov 25 14:46:14 2010
From: report at bugs.python.org (=?utf-8?b?T251ciBLw7zDp8O8aw==?=)
Date: Thu, 25 Nov 2010 13:46:14 +0000
Subject: [issue10524] Patch to add Pardus to supported dists in platform
In-Reply-To: <1290636029.57.0.718093237455.issue10524@psf.upfronthosting.co.za>
Message-ID: <1290692774.25.0.842084267956.issue10524@psf.upfronthosting.co.za>


Onur K???k <onur at pardus.org.tr> added the comment:

Pardus is a Linux distribution, developed under Scientific and Technological Research Council of Turkey, by both paid and voluntary developers. We are getting pretty good attention lately actually, for example we were chosen 5th best Linux distro of 2010. More info can be found in [2], [3], etc.

[1] http://www.linuxjournal.com/content/readers-choice-awards-2010
[2] http://en.wikipedia.org/wiki/Pardus_%28operating_system%29
[3] http://www.pardus.org.tr/eng/about/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10524>
_______________________________________

From report at bugs.python.org  Thu Nov 25 15:42:52 2010
From: report at bugs.python.org (Dafydd Crosby)
Date: Thu, 25 Nov 2010 14:42:52 +0000
Subject: [issue10525] Added mouse and colour support to Game of Life
	curses	demo
In-Reply-To: <1290663861.94.0.159219260836.issue10525@psf.upfronthosting.co.za>
Message-ID: <1290696172.97.0.854064828089.issue10525@psf.upfronthosting.co.za>


Dafydd Crosby <dtcrsby at gmail.com> added the comment:

Sounds like an awesome idea.

The new patch now coloured cells :-)

----------
Added file: http://bugs.python.org/file19817/mouse_and_colour.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10525>
_______________________________________

From report at bugs.python.org  Thu Nov 25 15:43:00 2010
From: report at bugs.python.org (Dafydd Crosby)
Date: Thu, 25 Nov 2010 14:43:00 +0000
Subject: [issue10525] Added mouse and colour support to Game of Life
	curses	demo
In-Reply-To: <1290663861.94.0.159219260836.issue10525@psf.upfronthosting.co.za>
Message-ID: <1290696180.32.0.303343032773.issue10525@psf.upfronthosting.co.za>


Changes by Dafydd Crosby <dtcrsby at gmail.com>:


Removed file: http://bugs.python.org/file19808/mouse_and_colour.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10525>
_______________________________________

From report at bugs.python.org  Thu Nov 25 15:52:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 25 Nov 2010 14:52:23 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1290696743.39.0.846660294189.issue8879@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'll come up with a patch for Amaury's message.

Hirokazu - I didn't see that MSDN page, thanks. Without st_ino, I'll need to find a way around the block of lines 1941-1954 in Lib/tarfile.py. That's what was causing a test failure in the first place because it ends up assuming Windows files are always REGTYPE, which sets some things later on in that function differently than they should be for links, namely tarinfo.size.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Thu Nov 25 15:55:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Nov 2010 14:55:17 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290678973.51.0.496980119878.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290696910.3556.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'm with Ezio here. I'm -1 for callable(), +0 for iscallable() (there
> should be preferably one obvious way to do it and using isinstance()
> seems to be that way at this point).

The thing is, "isisinstance(x, collections.Callable)" is hardly obvious
to anybody, while callable() is.
As for the naming, it's the same as in 2.x, which is a good enough
reason for me. Nobody stops you from calling your callables "callable"
anyway, or your maxima "max" and your sums "sum".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Thu Nov 25 15:57:49 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 25 Nov 2010 14:57:49 +0000
Subject: [issue10525] Added mouse and colour support to Game of Life
	curses	demo
In-Reply-To: <1290663861.94.0.159219260836.issue10525@psf.upfronthosting.co.za>
Message-ID: <1290697069.77.0.974776516213.issue10525@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Committed in r86750. Thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10525>
_______________________________________

From report at bugs.python.org  Thu Nov 25 16:01:32 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 25 Nov 2010 15:01:32 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290697292.29.0.107378850218.issue10518@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Bringing back callable but with a different name is horrible. Just bring it back for goodness sake.

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Thu Nov 25 16:05:40 2010
From: report at bugs.python.org (SilentGhost)
Date: Thu, 25 Nov 2010 15:05:40 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290697540.99.0.718991608499.issue10518@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Just for the reference: "What's new in Python 3.0" page says:

> Removed callable(). Instead of callable(f) you can use isinstance(f, collections.Callable). The operator.isCallable() function is also gone.

There doesn't seem to be any indication than in two-versions time anyone would feel a need to resurrect it.

It might be not "obvious", but it's consistent with the check for other attributes. And I doubt that it's any more non-obvious than the need to use it in a first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Thu Nov 25 16:06:51 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 25 Nov 2010 15:06:51 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290697611.65.0.856124810672.issue10518@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Well, Guido has already approved its return - so further debate is relatively pointless. (Not that that usually stops us...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Thu Nov 25 16:12:04 2010
From: report at bugs.python.org (Xuanji Li)
Date: Thu, 25 Nov 2010 15:12:04 +0000
Subject: [issue10464] netrc module not parsing passwords containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1290697924.61.0.721381578771.issue10464@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

The patch attached (issue_10464_fix) moves handling of the '#' character from shlex to netrc, and makes netrc consider as comments lines whose first not-whitespace character is '#' instead of all text following '#' (which is what shlex does and which causes this bug). It also includes a test case.

----------
Added file: http://bugs.python.org/file19818/issue_10464_fix.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10464>
_______________________________________

From report at bugs.python.org  Thu Nov 25 16:12:11 2010
From: report at bugs.python.org (SilentGhost)
Date: Thu, 25 Nov 2010 15:12:11 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290697931.68.0.158732914739.issue10518@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

surely, such a relevant bit of information is worth linking to!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Thu Nov 25 16:13:17 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 25 Nov 2010 15:13:17 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290697997.54.0.909934093928.issue10518@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

It was on python-ideas in the recent thread about bringing back callable. Feel free to post a link here for the record.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Thu Nov 25 16:16:55 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 25 Nov 2010 15:16:55 +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: <1290698215.47.0.78092585837.issue10530@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

As discussed with tarek. It shouldn't be up to distutils2 to decide whether or not a Python file that has been included in the package should be installed or not if it is included in the set of files the developer has *asked* to be installed.

Possible use cases include deliberately broken modules for testing or an ast-transformer import hook that works with otherwise-invalid syntax files. (e.g. transforming the with statement to work on Python 2.4)

Allowing for the install of invalid syntax files will require ignoring SyntaxErrors during bytecode compile phase. A --strict option could be provided to allow these to remain an error.

----------
assignee: tarek
components: Distutils2
messages: 122372
nosy: eric.araujo, michael.foord, tarek
priority: normal
severity: normal
status: open
title: distutils2 should allow the installing of python files with invalid syntax

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10530>
_______________________________________

From report at bugs.python.org  Thu Nov 25 16:22:42 2010
From: report at bugs.python.org (SilentGhost)
Date: Thu, 25 Nov 2010 15:22:42 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290698562.21.0.610427441601.issue10518@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

I wouldn't consider it "approving", what Guido says is:

> I admit defeat on this one

<http://mail.python.org/pipermail/python-ideas/2010-November/008747.html>

Which incidentally is in response to your e-mails with the actual discussion following it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Thu Nov 25 16:36:58 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 25 Nov 2010 15:36:58 +0000
Subject: [issue1759169] clean up Solaris port and allow C99 extension modules
Message-ID: <1290699418.09.0.214788348921.issue1759169@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759169>
_______________________________________

From report at bugs.python.org  Thu Nov 25 16:42:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 25 Nov 2010 15:42:50 +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: <1290699770.14.0.485121456085.issue10154@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Mandriva and Debian also work fine with both "UTF8" and "UTF-8". For the record, the canonical spelling inside /usr/share/locale is "UTF-8". I suppose glibc does its own normalization.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Thu Nov 25 17:09:09 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Nov 2010 16:09:09 +0000
Subject: [issue7094] Add alternate float formatting styles to new-style
	formatting.
In-Reply-To: <1255118044.58.0.727731702587.issue7094@psf.upfronthosting.co.za>
Message-ID: <1290701349.67.0.344997986882.issue7094@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Checked in r86751. I'm leaving this open until I fix the remaining issue with '#g' for Decimal.

----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7094>
_______________________________________

From report at bugs.python.org  Thu Nov 25 17:11:00 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Nov 2010 16:11:00 +0000
Subject: [issue10524] Patch to add Pardus to supported dists in platform
In-Reply-To: <1290636029.57.0.718093237455.issue10524@psf.upfronthosting.co.za>
Message-ID: <1290701460.93.0.181074449986.issue10524@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The patch name has 2.7 in it, although "Versions" says 3.2. As this is a feature request, it can't be added to 2.7.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10524>
_______________________________________

From report at bugs.python.org  Thu Nov 25 17:11:03 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 25 Nov 2010 16:11:03 +0000
Subject: [issue10493] test_strptime failures under OpenIndiana
In-Reply-To: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>
Message-ID: <1290701463.51.0.126637719108.issue10493@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I verified that the bug was present too in the py3k patch sometime ago, but not currently. So I have spend some time doing bisection in the py3k branch to know WHEN the problem was solved.

If was solved in r81583:

"""
------------------------------------------------------------------------
r81583 | martin.v.loewis | 2010-05-28 17:44:20 +0200 (Fri, 28 May 2010) | 9 lines

Merged revisions 81582 via svnmerge from 
svn+ssh://pythondev at svn.python.org/python/trunk

........
  r81582 | martin.v.loewis | 2010-05-28 17:28:47 +0200 (Fr, 28 Mai 2010) | 2 lines
  
  Issue #1759169: Drop _XOPEN_SOURCE on Solaris.
........

------------------------------------------------------------------------
"""

The fix was ported from trunk (2.7) to py3k branch, but it was not applied to 3.1 branch, though. I don't know why, but seems to be an oversight.

Since the patch has been "tested" in py3k branch since late May, it is simple and solves the problem in 3.1 branch, I request this patch to be applied to 3.1 too.

Martin, do you have an opinion?.

Must the release manager to be involved?.

PS: I have verified that with the change, the buildslave in OpenIndiana passes the test.

The issue is that we have checks for "SunOS/5.10", but OpenIndiana and the new Solaris 11 Express are "SunOS/5.11". We have to add them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10493>
_______________________________________

From report at bugs.python.org  Thu Nov 25 17:24:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 25 Nov 2010 16:24:18 +0000
Subject: [issue10493] test_strptime failures under OpenIndiana
In-Reply-To: <1290701463.51.0.126637719108.issue10493@psf.upfronthosting.co.za>
Message-ID: <4CEE8DAE.3030407@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The fix was ported from trunk (2.7) to py3k branch, but it was not
> applied to 3.1 branch, though. I don't know why, but seems to be an
> oversight.

No, it was deliberate: it was not backported all, neither to 3.1, nor
to 2.6. I was concerned that doing so may break stuff that currently
works.

> Since the patch has been "tested" in py3k branch since late May, it
> is simple and solves the problem in 3.1 branch, I request this patch
> to be applied to 3.1 too.
> 
> Martin, do you have an opinion?.

I remain skeptical. The test on the 3k branch is irrelevant; the

> Must the release manager to be involved?.

At this point: definitely. After the 3.1.3 release: the test in the
2.7 release may not give significant insight yet.

> The issue is that we have checks for "SunOS/5.10", but OpenIndiana
> and the new Solaris 11 Express are "SunOS/5.11". We have to add
> them.

That is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10493>
_______________________________________

From report at bugs.python.org  Thu Nov 25 17:36:14 2010
From: report at bugs.python.org (Yingjie)
Date: Thu, 25 Nov 2010 16:36:14 +0000
Subject: [issue10531] write tilted text in turtle
In-Reply-To: <1290702974.67.0.695196946667.issue10531@psf.upfronthosting.co.za>
Message-ID: <1290702974.67.0.695196946667.issue10531@psf.upfronthosting.co.za>


New submission from Yingjie <lanyjie at yahoo.com>:

First of all, I'd like to express my deep gratidute to the author of this module, it is such a fun module to work with and to teach python as a first programming language.

Secondly, I would like to request a feature if it is not too hard to achieve. Currently, you can only write texts horizontally, no matter what is the current orientation of the turtle pen. I wonder if it is possible to write text in any direction when we control the heading of the turtle? For example, the following code would write a vertically oriented text:

>>> setheading(90) #turtle facing up
>>> write("vertical text!")

Thanks a lot!

Yingjie

----------
components: Library (Lib)
messages: 122379
nosy: lanyjie
priority: normal
severity: normal
status: open
title: write tilted text in turtle
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10531>
_______________________________________

From report at bugs.python.org  Thu Nov 25 17:39:15 2010
From: report at bugs.python.org (Yingjie)
Date: Thu, 25 Nov 2010 16:39:15 +0000
Subject: [issue10532] A bug related to matching the empty string
In-Reply-To: <1290703155.74.0.717125241032.issue10532@psf.upfronthosting.co.za>
Message-ID: <1290703155.74.0.717125241032.issue10532@psf.upfronthosting.co.za>


New submission from Yingjie <lanyjie at yahoo.com>:

Here are some puzzling results I have got (I am using Python 3, I suppose similar results for python 2).

When I do the following, I got an exception:
>>> re.findall('(d*)*', 'adb')
>>> re.findall('((d)*)*', 'adb')

When I do this, I am fine but the result is wrong:
>>> re.findall('((.d.)*)*', 'adb')
[('', 'adb'), ('', '')]

Why is it wrong?

The first mactch of groups:
('', 'adb')
indicates the outer group ((.d.)*) captured
the empty string, while the inner group (.d.)
captured 'adb', so the outer group must have
captured the empty string at the end of the
provided string 'adb'.

Once we have matched the final empty string '',
there should be no more matches, but we got
another match ('', '')!!!

So, findall matched the empty string in
the end of the string twice!!!

Isn't this a bug?

Yingjie

----------
components: Regular Expressions
messages: 122380
nosy: lanyjie
priority: normal
severity: normal
status: open
title: A bug related to matching the empty string
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10532>
_______________________________________

From report at bugs.python.org  Thu Nov 25 17:39:53 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 25 Nov 2010 16:39:53 +0000
Subject: [issue10524] Patch to add Pardus to supported dists in platform
In-Reply-To: <1290701460.93.0.181074449986.issue10524@psf.upfronthosting.co.za>
Message-ID: <4CEE9155.6090807@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Eric Smith wrote:
> 
> Eric Smith <eric at trueblade.com> added the comment:
> 
> The patch name has 2.7 in it, although "Versions" says 3.2. As this is a feature request, it can't be added to 2.7.

I consider missing distros in the list of supported dists
a bug, not a feature request.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10524>
_______________________________________

From report at bugs.python.org  Thu Nov 25 17:40:37 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 25 Nov 2010 16:40:37 +0000
Subject: [issue10524] Patch to add Pardus to supported dists in platform
In-Reply-To: <1290636029.57.0.718093237455.issue10524@psf.upfronthosting.co.za>
Message-ID: <1290703237.49.0.605001869661.issue10524@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
stage:  -> commit review
type: feature request -> behavior
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10524>
_______________________________________

From report at bugs.python.org  Thu Nov 25 17:41:06 2010
From: report at bugs.python.org (Yingjie)
Date: Thu, 25 Nov 2010 16:41:06 +0000
Subject: [issue10532] A bug related to matching the empty string
In-Reply-To: <1290703155.74.0.717125241032.issue10532@psf.upfronthosting.co.za>
Message-ID: <1290703266.98.0.381260529631.issue10532@psf.upfronthosting.co.za>


Changes by Yingjie <lanyjie at yahoo.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10532>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:00:49 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 25 Nov 2010 17:00:49 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>


New submission from ?ukasz Langa <lukasz at langa.pl>:

Currently the constructor in defaultdict only accepts factories. It would be very handy to allow for concrete values as well. It's implementable either by checking if the argument is callable or by a new keyword argument.

----------
assignee: lukasz.langa
components: Library (Lib)
keywords: easy
messages: 122382
nosy: holdenweb, lukasz.langa, michael.foord
priority: low
severity: normal
status: open
title: defaultdict constructor with a concrete value
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:07:24 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 25 Nov 2010 17:07:24 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290704844.19.0.0527518216786.issue10533@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I would love this functionality (I almost always initialise defaultdict with a lambda that just returns a concrete value).

Unfortunately it seems like adding a keyword argument isn't possible because defaultdict takes arbitrary keyword args (and populates the dict with them).

    defaultdict(lambda: 1, foo=1, bar=2, baz=3)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:24:29 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 25 Nov 2010 17:24:29 +0000
Subject: [issue10532] A bug related to matching the empty string
In-Reply-To: <1290703155.74.0.717125241032.issue10532@psf.upfronthosting.co.za>
Message-ID: <1290705869.48.0.920711702276.issue10532@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

The spans say this:

>>> for m in re.finditer('((.d.)*)*', 'adb'):
    print(m.span())

    
(0, 3)
(3, 3)

There's an non-empty match followed by an empty match.

IHMO, not a bug.

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10532>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:28:02 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Thu, 25 Nov 2010 17:28:02 +0000
Subject: [issue10493] test_strptime failures under OpenIndiana
In-Reply-To: <1290373528.4.0.726393242886.issue10493@psf.upfronthosting.co.za>
Message-ID: <1290706082.27.0.798145524933.issue10493@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I have made several experiments to get the minimal patch. It is committed in r86752.

It is trivial enough, and risk-free enough, to commit even in RC state (In my opinion).

Python 2.7 and 3.2 are not affected. They don't look for "SunOS/5.10" in their configure script.

The buildslave is now green. Finally. http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.1/builds/36

----------
assignee:  -> jcea
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10493>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:31:17 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Nov 2010 17:31:17 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290706277.08.0.525700798042.issue10533@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

-1 from me. You can't use keywords, and if you make the value callable at a later date then suddenly you'll change the behavior of seemingly unrelated code. Is a lambda so bad?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:36:52 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 25 Nov 2010 17:36:52 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290706612.85.0.157018776283.issue10533@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Both arguments are true and definitive. Last possibility would be to introduce a factory function for defaultdicts that would only accept concrete values:

  from collections import fallbackdict

Then this factory could produce defaultdict instances like this:

  fallbackdict(0, some_key=1) --> defaultdict(lambda: 0, some_key=1)

That would be safe for future type changes as well.

If this version does not sound appealing, I can't see any other way of reliably introducing this shortcut.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:48:10 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 25 Nov 2010 17:48:10 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290707290.51.0.623270227124.issue10533@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

How about:

from collections import defaultdict

class defaultdict_value(defaultdict):
    def __init__(self, value):
        defaultdict.__init__(self, lambda : value)

x = defaultdict_value(3)
print(x[1])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:54:35 2010
From: report at bugs.python.org (Steve Holden)
Date: Thu, 25 Nov 2010 17:54:35 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290707290.51.0.623270227124.issue10533@psf.upfronthosting.co.za>
Message-ID: <4CEEA2AE.70304@holdenweb.com>


Steve Holden <steve at holdenweb.com> added the comment:

On 11/25/2010 11:48 AM, Eric Smith wrote:
> 
> Eric Smith <eric at trueblade.com> added the comment:
> 
> How about:
> 
> from collections import defaultdict
> 
> class defaultdict_value(defaultdict):
>     def __init__(self, value):
>         defaultdict.__init__(self, lambda : value)
> 
> x = defaultdict_value(3)
> print(x[1])
> 
> ----------

+1

But I'd call it defaultdict_const().

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
PyCon 2011 Atlanta March 9-17       http://us.pycon.org/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:54:39 2010
From: report at bugs.python.org (Shannon -jj Behrens)
Date: Thu, 25 Nov 2010 17:54:39 +0000
Subject: [issue1649329] Extract file-finding and language-handling code from
	gettext.find
Message-ID: <1290707679.65.0.743174545122.issue1649329@psf.upfronthosting.co.za>


Shannon -jj Behrens <jjinux at users.sourceforge.net> added the comment:

> OTOH maybe a lightweight ABC with mixin methods and a concrete implementation of the full gettext logic may be clear and educational here.  Shannon, if you?re still getting those emails, what do you think?

Yep, that'd be fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1649329>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:55:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 17:55:21 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290707721.7.0.928422262791.issue10533@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Like three-liners?  whatsnew/2.5 gives us this one:

class zerodict(dict):
    def __missing__(self, key):
        return 0

I don?t think it?s too painful to have to use defaultdict with a lambda.  We can?t use a keyword argument and I?m -0.5 on changing behavior depending on the type of the first argument.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:55:25 2010
From: report at bugs.python.org (John Levon)
Date: Thu, 25 Nov 2010 17:55:25 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1290707725.83.0.58821193051.issue4111@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

configure.in has:

AC_MSG_RESULT([$with_dtrace])
...
AC_MSG_RESULT($with_dtrace)

Why twice? It looks confusing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:55:30 2010
From: report at bugs.python.org (Shannon -jj Behrens)
Date: Thu, 25 Nov 2010 17:55:30 +0000
Subject: [issue1649329] Extract file-finding and language-handling code from
	gettext.find
Message-ID: <1290707730.25.0.016072026593.issue1649329@psf.upfronthosting.co.za>


Shannon -jj Behrens <jjinux at users.sourceforge.net> added the comment:

Although, perhaps this bug is going away.  It seems like using zip files for eggs is going out of vogue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1649329>
_______________________________________

From report at bugs.python.org  Thu Nov 25 18:59:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 17:59:18 +0000
Subject: [issue1649329] Extract file-finding and language-handling code from
	gettext.find
Message-ID: <1290707958.97.0.423856716656.issue1649329@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Would you like to propose a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1649329>
_______________________________________

From report at bugs.python.org  Thu Nov 25 19:00:52 2010
From: report at bugs.python.org (Shannon -jj Behrens)
Date: Thu, 25 Nov 2010 18:00:52 +0000
Subject: [issue1649329] Extract file-finding and language-handling code from
	gettext.find
Message-ID: <1290708052.33.0.653983386319.issue1649329@psf.upfronthosting.co.za>


Shannon -jj Behrens <jjinux at users.sourceforge.net> added the comment:

I've never managed to get a patch into Python, but I wouldn't mind trying ;)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1649329>
_______________________________________

From report at bugs.python.org  Thu Nov 25 19:07:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 18:07:39 +0000
Subject: [issue10524] Patch to add Pardus to supported dists in platform
In-Reply-To: <1290636029.57.0.718093237455.issue10524@psf.upfronthosting.co.za>
Message-ID: <1290708459.82.0.751262432748.issue10524@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10524>
_______________________________________

From report at bugs.python.org  Thu Nov 25 19:54:29 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Nov 2010 18:54:29 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290711269.86.0.0010867623456.issue10533@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: lukasz.langa -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 20:09:16 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Nov 2010 19:09:16 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290712156.31.0.802571715367.issue10533@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> It would be very handy to allow for concrete values as well.

Do you have use cases for a concrete integer value that isn't zero?

Since we can currently use defaultdict(int) or defaultdict(tuple), is the purpose just to create a more direct spelling of the same thing?  The docs for defaultdict also show a general purpose way to generate any default constant (though that way isn't obvious if you haven't seen it in the docs).

I'm reluctant to add yet another variant.  We already have __missing__, defaultdict, Counter, dict.get, and dict.setdefault().

The docs for dictionaries need to make clear that Guido has already provided an idiom to be the one obvious way to do it:

    class MyConst(dict):
        def __missing__(self, key):
            return myconst

That was really the whole point of adding __missing__ in the first place.  The OP's proposal amounts to rejecting Guido's design which provides a very good general purpose solution.

----------
keywords:  -easy
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 20:25:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 19:25:56 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290713156.69.0.423893000158.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the patch Stefan.  I can?t test on Windows now; can you/have you?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Thu Nov 25 20:28:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 19:28:38 +0000
Subject: [issue6166] encoding error for 'setup.py --author' when read via
	subprocess pipe
In-Reply-To: <1243881147.82.0.337721955444.issue6166@psf.upfronthosting.co.za>
Message-ID: <1290713318.36.0.621880423923.issue6166@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I agree with Tarek this is not a bug, and there is a workaround, so I?m closing this.

----------
resolution:  -> works for me
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6166>
_______________________________________

From report at bugs.python.org  Thu Nov 25 20:44:17 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Thu, 25 Nov 2010 19:44:17 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290714257.34.0.470557756443.issue10533@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

A couple of points:

1. Eric's proposal is what I had in mind with the `fallbackdict' idea.
2. I'm also reluctant to add more variants to the standard library. Then again if it contained a `fallbackdict' I wouldn't probably ever use `defaultdict' again. How often do you need to provide a factory?
3. Naming the other variant `defaultdict_const', `defaultdict_value', `defaultdict_whatever' beats the purpose because it's actually more characters to type than `defaultdict(lambda:', especially when you count the longer import name.
4. I cannot come up with another typical integer value that would be useful, then again I've used "", [] and set() numerous times. Adding zerodict, stringdict, listdict, setdict is obviously absurd.
5. The discussion started on Twitter amongst a couple of core devs and __missing__ didn't appear to be the one obvious way to anyone.
6. Of course I'm in no position to reject Guido's design on anything. Then again even `defaultdict(lambda:' is simply so much shorter than subclassing dict.

To sum up: if you don't find the idea of adding `fallbackdict' (possibly with an different *short* name) worth it, then I'm +1 on correcting the docs in terms of __missing__ and leaving the implementation as is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:12:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 25 Nov 2010 20:12:57 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1290715977.0.0.392416399578.issue10527@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +jnoller
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:16:02 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 25 Nov 2010 20:16:02 +0000
Subject: [issue10464] netrc module not parsing passwords containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1290716162.16.0.84752741627.issue10464@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10464>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:19:55 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 25 Nov 2010 20:19:55 +0000
Subject: [issue10531] write tilted text in turtle
In-Reply-To: <1290702974.67.0.695196946667.issue10531@psf.upfronthosting.co.za>
Message-ID: <1290716395.51.0.685922931682.issue10531@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +belopolsky, gregorlingl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10531>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:20:58 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 25 Nov 2010 20:20:58 +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: <1290716458.66.0.163816874785.issue10534@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Expose and document the junk and popular sets as attributes of the SequenceMatcher object.

self.junk = junk
self.popular = popular

Deprecate the then unneeded and undocumented isbjunk and isbpopular functions, currently defined as
    self.isbjunk = junk.__contains__
    self.isbpopular = popular.__contains__
(and slightly modify the matcher function that localizes and uses one of the above).

Question, (how) do we  document deprecation/removal of undocumented function?

In discussions that included Tim Peters, the idea of exposing the tuning parameters of the heuristic was discussed. Now that the heuristic can be turned off, I think this is YAGNI until someone specifically requests it.

----------
assignee: terry.reedy
messages: 122400
nosy: eli.bendersky, hodgestar, terry.reedy
priority: normal
severity: normal
stage: unit test needed
status: open
title: difflib.SequenceMatcher: expose junk sets, deprecate undocumented isb... functions.
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10534>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:23:39 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 25 Nov 2010 20:23:39 +0000
Subject: [issue2986] difflib.SequenceMatcher not matching long sequences
In-Reply-To: <1211920199.48.0.934398772587.issue2986@psf.upfronthosting.co.za>
Message-ID: <1290716619.86.0.462835274725.issue2986@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Agreed. #10534. This is really a 'follow-on' rather than 'superseder',
but the forward reference should be easy for anyone to find.

----------
resolution:  -> fixed
status: open -> closed
superseder:  -> difflib.SequenceMatcher: expose junk sets, deprecate undocumented isb... functions.
type: feature request -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2986>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:24:09 2010
From: report at bugs.python.org (Steve Holden)
Date: Thu, 25 Nov 2010 20:24:09 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290714257.34.0.470557756443.issue10533@psf.upfronthosting.co.za>
Message-ID: <4CEEC5C0.1040603@holdenweb.com>


Steve Holden <steve at holdenweb.com> added the comment:

On 11/25/2010 1:44 PM, ?ukasz Langa wrote:
> To sum up: if you don't find the idea of adding `fallbackdict'
> (possibly with an different *short* name) worth it, then I'm +1 on
> correcting the docs in terms of __missing__ and leaving the
> implementation as is.

+1

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
PyCon 2011 Atlanta March 9-17       http://us.pycon.org/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:25:48 2010
From: report at bugs.python.org (Alex)
Date: Thu, 25 Nov 2010 20:25:48 +0000
Subject: [issue10533] defaultdict constructor with a concrete value
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290716748.75.0.847616150911.issue10533@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

I agree with ?ukasz, it's more clutter than is worth for what amounts to: fallbackdict = lambda c, **kwargs: defaultdict(lambda c, **kwargs)

I will note, however, that almost all my use cases are with factories, primarily list set or int, and it was only this week that I first needed something else!

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:32:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 20:32:46 +0000
Subject: [issue10533] Need example of using __missing__
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290717166.63.0.558809682567.issue10533@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> 4. I cannot come up with another typical integer value that would be
> useful, then again I've used "", [] and set() numerous times.
You can get '' with str as default factory and [] with list.

I think we agree on reclassifying this as a doc problem.  Proposal:

1) Add a small example in stdtypes.rst:dict section.

2) Add examples of giving dict or int to collections.defaultdict to get {} or 0 as default value.

3) Find a way to link to that example from the index.  It is not currently indexed because there is no dict.__missing__ method, hence no method markup that would trigger indexing.

4) Cross-link collections.rst:defaultdict, collections.rst:Counter and stdtypes.rst:__missing__ example.

----------
components: +Documentation -Library (Lib)
nosy: +docs at python
stage:  -> needs patch
title: defaultdict constructor with a concrete value -> Need example of using __missing__
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:34:50 2010
From: report at bugs.python.org (Michael Foord)
Date: Thu, 25 Nov 2010 20:34:50 +0000
Subject: [issue10533] Need example of using __missing__
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290717290.12.0.772900280627.issue10533@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Well, I was perfectly aware of __missing__ - it's just a three liner to do it when using a lambda isn't *that* bad... I'm sure the documentation could be improved to highlight __missing__ though. It's almost always the case that documentation can be improved. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:36:54 2010
From: report at bugs.python.org (Steven Bethard)
Date: Thu, 25 Nov 2010 20:36:54 +0000
Subject: [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1290717414.13.0.775296073614.issue10528@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

I think it's fine to fix this in 3.2 by switching to mappings where necessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10528>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:40:35 2010
From: report at bugs.python.org (Daniel Urban)
Date: Thu, 25 Nov 2010 20:40:35 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290717635.99.0.886153969866.issue10518@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/issue10518>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:40:58 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Thu, 25 Nov 2010 20:40:58 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290717658.21.0.209984775869.issue10520@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

It is wort to fix regression if all directories are absolute. 

diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -54,7 +54,8 @@
     for i, path in enumerate(dirlist):
         if not os.path.isabs(path):
             dirlist.insert(i + 1, dir)
-            break
+            return
+    dirlist.insert(0, dir)

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:46:23 2010
From: report at bugs.python.org (Jesse Noller)
Date: Thu, 25 Nov 2010 20:46:23 +0000
Subject: [issue10527] multiprocessing.Pipe problem: "handle out of range in
	select()"
In-Reply-To: <1290683713.67.0.950545103714.issue10527@psf.upfronthosting.co.za>
Message-ID: <1290717983.24.0.0416348151521.issue10527@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10527>
_______________________________________

From report at bugs.python.org  Thu Nov 25 21:51:12 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 25 Nov 2010 20:51:12 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1290718272.12.0.663999142717.issue2650@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

Re the regex module (issue #2636), would a good compromise be:

    regex.escape(user_input, special_only=True)

to maintain compatibility?

----------
nosy: +mrabarnett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
_______________________________________

From report at bugs.python.org  Thu Nov 25 22:46:10 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Nov 2010 21:46:10 +0000
Subject: [issue10533] Need example of using __missing__
In-Reply-To: <1290704449.7.0.95801510837.issue10533@psf.upfronthosting.co.za>
Message-ID: <1290721570.97.0.379925883636.issue10533@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

[?ukasz Langa]

> __missing__ didn't appear to be the one obvious way to anyone.

Two thoughts:

* There is part of the Zen that says that way may not be obvious unless your Dutch.  In this case,  __missing__ was the API designed by Guido to handle the problem.  If it isn't obvious, it is up to us to popularize the idiom in talks, in tutorials, in newsgroup discussions, etc.  And FWIW, it is not unprecedented -- Lua's dicts have a similar hook and most of the interesting programming in Lua relies on it.

* The __missing__ method should not be considered a dark corner of Python.  Unlike the copy module, pickling, of weakrefs, it is not tucked away in the library.  The missing method is part of the basic API for one of Python's most fundamental objects.  If someone is going to be a Python programmer, they must at least learn about dicts, lists, strings, and tuples.

> then again I've used "", [] and set() numerous times. 
> Adding zerodict, stringdict, listdict, setdict is 
> obviously absurd.

Looking at those examples, you're probably already aware that the list and set versions are already served by defaultdict(), and that it would be basic (and probably common) mistake to accidentally use [] in your proposed constant dict.

A constant version of the defaultdict only makes sense with immutables such as numbers, strings, and tuples.  The common case would be the number zero and we have Counter() for that.  So, you're left with very few use cases and with a hazard for users who may write: f = fallback_dict([]).   

> 4. I cannot come up with another typical integer value 
> that would be useful

FWIW, the Counter class *is* a ZeroDict.  It has a few extra methods but is basically a dict with __missing__ set to return zero.

> ... then I'm +1 on correcting the docs in terms of 
> __missing__ and leaving the implementation as is.

Thank you.  Will reclassify this as a doc issue.



[?ric Araujo]
> 2) Add examples of giving dict or int to 
> collections.defaultdict to get {} or 0 as default value.

Those examples have been there since day one.

[Michael Foord]
> I'm sure the documentation could be improved to highlight
> __missing__ though.

I'll add another example and perhaps include on in the tutorial.

> It's almost always the case that documentation can be improved. :-)

Getting people to read it is another story ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10533>
_______________________________________

From report at bugs.python.org  Thu Nov 25 22:58:38 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 25 Nov 2010 21:58:38 +0000
Subject: [issue9424] Deprecate assertEquals, assertNotEquals, assert_,
	assertAlmostEquals, assertNotAlmostEquals
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1290722318.23.0.117528840439.issue9424@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Instead of turning warnings on by default in regrtest, it would be better to do it directly in unittest. I'll close this and open a new issue for that.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed
title: Disable unittest.TestCase.assertEquals and assert_ during a regrtest run -> Deprecate assertEquals, assertNotEquals, assert_, assertAlmostEquals, assertNotAlmostEquals

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9424>
_______________________________________

From report at bugs.python.org  Thu Nov 25 23:08:36 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 25 Nov 2010 22:08:36 +0000
Subject: [issue10535] Enable warnings by default in unittest
In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>
Message-ID: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>


New submission from Ezio Melotti <ezio.melotti at gmail.com>:

Warnings should be on by default in unittest so that developers can see them while running the tests even if they are silenced by default in Python.

The plan is to add a "warnings" argument to TestProgram and the default TextTestRunner:
  * if the argument is passed always use it as a filter (e.g. default, ignore, all, ...) for warnings;
  * if the argument is not passed and sys.warnoptions is not [] (i.e. python has been called with "-W something") don't do anything (i.e. use the warnings specified by -W);
  * if the argument is not passed and sys.warnoptions is [], use 'default' (i.e. show warnings).

In order to prevent floods of warnings when the deprecated assertEquals, assert_, etc. are used (see #9424), a new type of warning could be created (e.g. _UnittestDeprecationWarning) and filtered so that these warnings are printed only once.

----------
assignee: ezio.melotti
messages: 122411
nosy: brett.cannon, ezio.melotti, michael.foord
priority: normal
severity: normal
stage: needs patch
status: open
title: Enable warnings by default in unittest
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10535>
_______________________________________

From report at bugs.python.org  Thu Nov 25 23:09:28 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 25 Nov 2010 22:09:28 +0000
Subject: [issue9424] Deprecate assertEquals, assertNotEquals, assert_,
	assertAlmostEquals, assertNotAlmostEquals
In-Reply-To: <1280448352.86.0.380978086896.issue9424@psf.upfronthosting.co.za>
Message-ID: <1290722968.6.0.935644047589.issue9424@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

See #10535.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9424>
_______________________________________

From report at bugs.python.org  Thu Nov 25 23:13:19 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Nov 2010 22:13:19 +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: <1290723199.32.0.0808695628296.issue10242@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: michael.foord -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10242>
_______________________________________

From report at bugs.python.org  Thu Nov 25 23:17:02 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 25 Nov 2010 22:17:02 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1290723422.24.0.944335374049.issue10273@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

After discussion with Michael and Guido, am limiting this to:

* Fixing assertItemsEqual as described in issue10242

* Moving the docs for type specific equality methods inside the docs for assertEqual to emphasize that those get dispatched automatically and need not be called directly.

* Changing assertRegexpMatches to assertRegex

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10273>
_______________________________________

From report at bugs.python.org  Thu Nov 25 23:31:06 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 25 Nov 2010 22:31:06 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290724266.08.0.393497050503.issue10453@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Yes, the patch is tested on Windows. Feel free to commit it if you have
a chance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Thu Nov 25 23:33:54 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 25 Nov 2010 22:33:54 +0000
Subject: [issue10441] some stdlib modules need to be updated to handle SSL
	certificate validation
In-Reply-To: <1289985992.42.0.118640057239.issue10441@psf.upfronthosting.co.za>
Message-ID: <1290724434.54.0.69428598624.issue10441@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/issue10441>
_______________________________________

From report at bugs.python.org  Thu Nov 25 23:34:00 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 25 Nov 2010 22:34:00 +0000
Subject: [issue10442] Please by default enforce ssl certificate checking in
	modules that can have user's which *depend* on the security of
	the ssl connection.
In-Reply-To: <1289985995.18.0.175353839662.issue10442@psf.upfronthosting.co.za>
Message-ID: <1290724440.67.0.212094138161.issue10442@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/issue10442>
_______________________________________

From report at bugs.python.org  Thu Nov 25 23:49:44 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 25 Nov 2010 22:49:44 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1290725384.37.0.783715600082.issue8879@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Umm, I'm not sure how to fix this yet, but
if we create the function like os._stat_with_open_handle()
which returns stat struct and open handle on windows,
I think we can set/use st_ino. (Because FileID won't change
while file is opened) I'm not sure if it is appropriate API
change or not, though. :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Thu Nov 25 23:56:46 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 25 Nov 2010 22:56:46 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1290725806.72.0.224664589328.issue10273@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> * Moving the docs for type specific equality methods inside the docs for assertEqual to emphasize that those get dispatched automatically and need not be called directly.

I already fixed this on py3k, adding a section where the type-specific methods are described[0] and added a reference in the assertEqual description[1].  I also clarified that usually there's no need to call them directly even thought I don't see why they shouldn't do it if they want to use a specific test.

> * Changing assertRegexpMatches to assertRegex

And assertNotRegexpMatches -> assertNotRegex,  assertRaisesRegexp -> assertRaisesRegex,  assertWarnsRegexp -> assertWarnRegex?
Will the *Regexp forms be deprecated too?

[0]: http://docs.python.org/dev/py3k/library/unittest.html#type-specific-methods
[1]: http://docs.python.org/dev/py3k/library/unittest.html#unittest.TestCase.assertEqual

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10273>
_______________________________________

From report at bugs.python.org  Fri Nov 26 00:03:50 2010
From: report at bugs.python.org (=?utf-8?q?Michele_Orr=C3=B9?=)
Date: Thu, 25 Nov 2010 23:03:50 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290726230.75.0.674066573893.issue10453@psf.upfronthosting.co.za>


Michele Orr? <maker.py at gmail.com> added the comment:

Thank you Stefan, these days I was a little busy and I hadn't the time to review my patch. I really appreciate you help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Fri Nov 26 00:44:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 25 Nov 2010 23:44:32 +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: <1290728672.07.0.0822441099106.issue10299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In 2.7, the functions are not sorted alphabetically.  I think they should, and I offer to do the boring work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Fri Nov 26 00:48:16 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Thu, 25 Nov 2010 23:48:16 +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: <1290728896.85.0.0315922878983.issue10299@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

The last 4 functions are "Non-essential Built-in Functions"[0] so I kept them at the end of the list to match the order they have in the page.

[0]: http://docs.python.org/library/functions.html#non-essential-built-in-functions

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Fri Nov 26 00:56:05 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Thu, 25 Nov 2010 23:56:05 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools
	is	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1290729365.81.0.166520613772.issue2562@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/issue2562>
_______________________________________

From report at bugs.python.org  Fri Nov 26 01:22:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 00:22:06 +0000
Subject: [issue10536] Enhancements to gettext docs
In-Reply-To: <1290730924.88.0.289473332428.issue10536@psf.upfronthosting.co.za>
Message-ID: <1290730924.88.0.289473332428.issue10536@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

A patch made for #2504 revealed a bug in gettext.rst, and I?ve found a number of other things to change in the file.  This is the first patch of a series of two or three.

Barry, as the original author of the module and doc, I?d like your opinion on points 3, a, and b particularly.

Patch is also uploaded to Rietveld for greater convenience: http://codereview.appspot.com/3333042/ (upload.py rocks)

Summary:

1) Markup: Use modern class/method directives combo (yay DRY).  Mark up variable parts in :file: constructs (e.g. :file:`{domain}.mo` will cause the HTML output to use var to indicate replaceable text).  Also change some ``gettext`` to :program:`gettext` for consistency.

2) Fix a typo in lngettext doc (originally included in patch by Franz Glasner for #2504).

3) I had started to remove information about private attributes (_info, _charset), advertising public getter methods instead.  Then I read the description of NullTranslations and realized the information was needed for subclasses.  I?ve reverted my removals, but I still think the private attributes should be listed in a specific section for people writing subclasses and not in the rest of the text.  If you?re okay, I?ll make a second patch.

4) Assorted wording changes, missing periods and hyphens, and other very small touch-ups: Turned a broken bare link into a working link with nice text; used the with statement in an example (we all love the with statement!); used two spaces after periods throughout (hello Fred Drake).

Final note: lines have not been rewrapped, for diff clarity.  When I commit part or all of this patch, I?ll make another commit to rewrap.


Not addressed:
a) The current docs is currently POSIX-specific.

b) The docs take great care to explain that Unicode strings will be returned in different places, but this should not be so accented in 3.x docs IMO.  I would just put a note somewhere near the top that all strings are str and remove the redundant sentences.  Following that line of thought, I could group all l*gettext variants at the end of the list of methods, explaining that regular usage should just be happy with str objects and that l*gettext are available if people really want bytes.

c) The file uses ?built-in namespace? and ?builtins namespace?, sometimes in neighbor paragraphs.  :mod:`builtins` is not used, even in explanations of the install function/method.  I don?t know if I should change that.

d) Some capitalization patterns look strange to me: I have seen ?I18N? and ?L10N? in upper case nowhere else.  Similarly, lower-case ?id? looks stranger than ?ID?.  The latter is used for example in official GNU gettext docs.  Am I going into foolish consistency territory or not?


Thanks in advance for reviews and opinions.

----------
assignee: eric.araujo
components: Documentation
files: gettext-docs-1.diff
keywords: needs review, patch
messages: 122420
nosy: barry, docs at python, eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: Enhancements to gettext docs
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19819/gettext-docs-1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10536>
_______________________________________

From report at bugs.python.org  Fri Nov 26 01:26:53 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Nov 2010 00:26:53 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1290731213.07.0.352248911673.issue8879@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Or, use GetFileInformationByHandleEx on Vista or above, and
NtQueryInformationFile under Vista. NtQueryInformationFile
is windows internal function and MS may change its behavior,
but probably we can think it won't happen on WinXP.

# These functions are needed to get real filename from
# open handle to set S_IEXEC.

And provide windows specific functions
  os._open/os._lopen: open windows handle same as
                      CreateFile in os.stat/os.lstat
  os._osfstat: stat for windows handle
  os._close: close windows handle

and if the file is hard link, store windows handle anywhere
in TarFile object. (I created branch for it, but I'm not sure
I can do it)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Fri Nov 26 01:42:25 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 26 Nov 2010 00:42:25 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1290732145.93.0.520843449371.issue8879@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
Removed message: http://bugs.python.org/msg122421

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Fri Nov 26 01:45:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 00:45:11 +0000
Subject: [issue10453] Add -h/--help option to compileall
In-Reply-To: <1290096427.94.0.882456547294.issue10453@psf.upfronthosting.co.za>
Message-ID: <1290732311.74.0.340240150175.issue10453@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Revision 86758, thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10453>
_______________________________________

From report at bugs.python.org  Fri Nov 26 01:50:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 00:50:05 +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: <1290732605.18.0.235872339598.issue10299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It?s fine to have them at the end of the page, but I think people want things to be sorted in an index.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Fri Nov 26 01:51:08 2010
From: report at bugs.python.org (Dan Stromberg)
Date: Fri, 26 Nov 2010 00:51:08 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1290732668.35.0.605147211242.issue6715@psf.upfronthosting.co.za>


Dan Stromberg <strombrg at gmail.com> added the comment:

While I realize Python extension modules are pretty much the norm in CPython, it'd be pretty cool if xz support could be written overtop of ctypes.  ctypes seems to be emerging as the way of doing FFI across different python implementations.

I've been working on a backup engine in my spare time, and I'd very much like to use a Python xz module in it.  However, the code I have so far runs about 4x faster on pypy than CPython, even if I turn on psyco in CPython.

IOW, I'd be pretty pleased to see an xz module that works equally well on CPython, pypy (seems to have pretty good ctypes), jython (has the beginnings of ctypes in 2.5.2rc*), iron python (supposedly included recently)...

----------
nosy: +strombrg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Nov 26 02:12:10 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 26 Nov 2010 01:12:10 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1290733930.29.0.380703382293.issue10273@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Yes, all the variants of RegexpMatches --> Regex 
No, on deprecations.  Just add a new alias and note in the docs that the oldname is obsolete.  Naming deprecations cause too much trouble for too little benefit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10273>
_______________________________________

From report at bugs.python.org  Fri Nov 26 02:21:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 01:21:00 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1290734460.64.0.966796252052.issue6715@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m afraid ctypes is too insecure for stdlib code.  Even using it in some tests had to be discussed and decided at EuroPython.

I?m told that PyPy has CPyExt now, so this may solved your compat concern :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Nov 26 02:36:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 01:36:12 +0000
Subject: [issue4015] Make installed scripts executable on windows
In-Reply-To: <1222949528.24.0.767744507339.issue4015@psf.upfronthosting.co.za>
Message-ID: <1290735372.32.0.808135618918.issue4015@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> tarek
components: +Distutils2 -Distutils
versions: +3rd party -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4015>
_______________________________________

From report at bugs.python.org  Fri Nov 26 03:02:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 02:02:04 +0000
Subject: [issue5616] Distutils 2to3 support doesn't have the doctest_only flag.
In-Reply-To: <1238452498.24.0.140926416369.issue5616@psf.upfronthosting.co.za>
Message-ID: <1290736924.84.0.661302463667.issue5616@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This feature is implemented in distutils2.

----------
components:  -Distutils
resolution:  -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5616>
_______________________________________

From report at bugs.python.org  Fri Nov 26 03:08:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 02:08:01 +0000
Subject: [issue8772] sysconfig: _get_default_scheme can be made public?
In-Reply-To: <1274315831.51.0.95937905223.issue8772@psf.upfronthosting.co.za>
Message-ID: <1290737281.67.0.692723317839.issue8772@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Library (Lib) -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8772>
_______________________________________

From report at bugs.python.org  Fri Nov 26 03:08:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 02:08:16 +0000
Subject: [issue5235] distutils seems to only work with VC++ 2008 (9.0)
In-Reply-To: <1234478580.55.0.077455747153.issue5235@psf.upfronthosting.co.za>
Message-ID: <1290737296.51.0.199092317612.issue5235@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file13060/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5235>
_______________________________________

From report at bugs.python.org  Fri Nov 26 03:09:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 02:09:15 +0000
Subject: [issue5235] distutils seems to only work with VC++ 2008 (9.0)
In-Reply-To: <1234478580.55.0.077455747153.issue5235@psf.upfronthosting.co.za>
Message-ID: <1290737355.71.0.161414529156.issue5235@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/issue5235>
_______________________________________

From report at bugs.python.org  Fri Nov 26 03:10:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 02:10:31 +0000
Subject: [issue6040] bdist_msi does not deal with pre-release version
In-Reply-To: <1242472106.67.0.523299229524.issue6040@psf.upfronthosting.co.za>
Message-ID: <1290737431.8.0.873326612089.issue6040@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils2 -Distutils
nosy: +eric.araujo
versions: +3rd party -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6040>
_______________________________________

From report at bugs.python.org  Fri Nov 26 03:13:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 02:13:21 +0000
Subject: [issue5747] knowing the parent command
In-Reply-To: <1239635801.31.0.779200404785.issue5747@psf.upfronthosting.co.za>
Message-ID: <1290737601.97.0.0412138835937.issue5747@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils2 -Distutils
stage:  -> needs patch
versions: +3rd party -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5747>
_______________________________________

From report at bugs.python.org  Fri Nov 26 03:15:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 02:15:06 +0000
Subject: [issue7918] distutils always ignores compile errors
In-Reply-To: <1265995747.45.0.532654407664.issue7918@psf.upfronthosting.co.za>
Message-ID: <1290737706.38.0.637970498017.issue7918@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  distutils is feature-frozen now and we?re building its successor at https://bitbucket.org/tarek/distutils2/

Would you like to work on a patch?

----------
components: +Distutils2 -Distutils
nosy: +eric.araujo
stage:  -> needs patch
versions: +3rd party -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7918>
_______________________________________

From report at bugs.python.org  Fri Nov 26 03:55:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 02:55:45 +0000
Subject: [issue6466] duplicate get_version() code between cygwinccompiler and
	emxccompiler
In-Reply-To: <1247386841.98.0.269164765319.issue6466@psf.upfronthosting.co.za>
Message-ID: <1290740145.35.0.0632055038797.issue6466@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This is done.

----------
components:  -Distutils
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6466>
_______________________________________

From report at bugs.python.org  Fri Nov 26 03:58:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 02:58:28 +0000
Subject: [issue6466] duplicate get_version() code between cygwinccompiler and
	emxccompiler
In-Reply-To: <1247386841.98.0.269164765319.issue6466@psf.upfronthosting.co.za>
Message-ID: <1290740308.14.0.349268065089.issue6466@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

To be more precise: the duplication is still present (and harmless) in distutils but fixed in distutils2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6466>
_______________________________________

From report at bugs.python.org  Fri Nov 26 04:04:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 03:04:33 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
	if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1290740673.29.0.701030651357.issue8027@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello Alexander, thanks for the report and patch.  Could you add a test for the fixed behavior?

----------
assignee: tarek -> eric.araujo
components: +Distutils2
nosy: +eric.araujo -terry.reedy
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Fri Nov 26 04:05:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 03:05:04 +0000
Subject: [issue8027] distutils fail to determine c++ linker with unixcompiler
	if using ccache
In-Reply-To: <1267284243.46.0.756608052144.issue8027@psf.upfronthosting.co.za>
Message-ID: <1290740704.56.0.85592630376.issue8027@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg113050

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8027>
_______________________________________

From report at bugs.python.org  Fri Nov 26 04:12:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 03:12:57 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
Message-ID: <1290741177.28.0.218386670253.issue6983@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Fri Nov 26 04:45:06 2010
From: report at bugs.python.org (Blair)
Date: Fri, 26 Nov 2010 03:45:06 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=gptvwN_-vAkwdfMxQtiyXE-=O5mpDktzN+s3N@mail.gmail.com>


Blair <bidihall at gmail.com> added the comment:

Hi Mark,

I thought that this had all been fixed, but it seems not.

Consider the following:

class xcomplex( complex ):
    def __new__(cls,*args,**kwargs):
        return complex.__new__(cls,*args,**kwargs)
    def __add__(self,x):
        return xcomplex( complex.__add__(self,x) )
    def __radd__(self,x):
        print "larg: ", type(x),"returning: ",
        return xcomplex( complex.__radd__(self,x) )

class xfloat(float):
    def __new__(cls,*args,**kwargs):
        return float.__new__(cls,*args,**kwargs)
    def __add__(self,x):
        return xfloat( float.__add__(self,x) )
    def __radd__(self,x):
        print "larg: ", type(x),"returning: ",
        return xfloat( float.__radd__(self,x) )

z = 1j
xz = xcomplex(1j)
f = 1.0
xf = xfloat(1.0)

print
print "-----------"
print "expect xcomplex:", type(z + xz)
print "expect xcomplex:", type(f + xz)
print "expect xfloat:", type(f + xf)
print "expect ???:", type(z + xf)

When this runs, the first three conversions are fine, the last is not: there
is no call to xfloat.__radd__. It seems that the builtin complex type simply
thinks it is dealing with a float. Here is the output

-----------
expect xcomplex: larg:  <type 'complex'> returning:  <class
'__main__.xcomplex'>
expect xcomplex: larg:  <type 'float'> returning:  <class
'__main__.xcomplex'>
expect xfloat: larg:  <type 'float'> returning:  <class '__main__.xfloat'>
expect ???: <type 'complex'>

The last line shows that no call to __radd__ occurred.

Is there anything that can be done now about this now, or is it just too
late?

Regards

Blair

At 01:13 a.m. 31/05/2010, you wrote:

Mark Dickinson <dickinsm at gmail.com> added the comment:

r78280 didn't remove the implicit coercion for rich comparisons;  that's now
been done in r81606.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________Python tracker <
report at bugs.python.org>

----------
Added file: http://bugs.python.org/file19820/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
-------------- next part --------------
Hi Mark,<br><br>
I thought that this had all been fixed, but it seems not.<br><br>
Consider the following:<br><br>
<font face="Courier, Courier">class xcomplex( complex ):<br>
?????? def __new__(cls,*args,**kwargs):<br>
?????????????? return complex.__new__(cls,*args,**kwargs)<br>
?????? def __add__(self,x):<br>
?????????????? return xcomplex( complex.__add__(self,x) )<br>
?????? def __radd__(self,x):<br>
?????????????? print &quot;larg: &quot;, type(x),&quot;returning: &quot;,<br>
?????????????? return xcomplex( complex.__radd__(self,x) )<br><br>
<br>
class xfloat(float):<br>
?????? def __new__(cls,*args,**kwargs):<br>
?????????????? return float.__new__(cls,*args,**kwargs)<br>
?????? def __add__(self,x):<br>
?????????????? return xfloat( float.__add__(self,x) )<br>
?????? def __radd__(self,x):<br>
?????????????? print &quot;larg: &quot;, type(x),&quot;returning: &quot;,<br>
?????????????? return xfloat( float.__radd__(self,x) )<br><br>
<br>
z = 1j<br>
xz = xcomplex(1j)<br>
f = 1.0<br>
xf = xfloat(1.0)<br><br>
<br>
print<br>
print &quot;-----------&quot;<br>
print &quot;expect xcomplex:&quot;, type(z + xz) <br>
print &quot;expect xcomplex:&quot;, type(f + xz) <br>
print &quot;expect xfloat:&quot;, type(f + xf)<br>
print &quot;expect ???:&quot;, type(z + xf)<br><br>
</font>When this runs, the first three conversions are fine, the last is not: there is no call to xfloat.__radd__. It seems that the builtin complex type simply thinks it is dealing with a float. Here is the output<br><br>

<font face="Courier, Courier">-----------<br>
expect xcomplex: larg:?? &lt;type &#39;complex&#39;&gt; returning:?? &lt;class &#39;__main__.xcomplex&#39;&gt;<br>
expect xcomplex: larg:?? &lt;type &#39;float&#39;&gt; returning:?? &lt;class &#39;__main__.xcomplex&#39;&gt;<br>
expect xfloat: larg:?? &lt;type &#39;float&#39;&gt; returning:?? &lt;class &#39;__main__.xfloat&#39;&gt;<br>
expect ???: &lt;type &#39;complex&#39;&gt;<br><br>
</font>The last line shows that no call to __radd__ occurred. <br><br>
Is there anything that can be done now about this now, or is it just too late?<br><br>
Regards<br><br>Blair<br><br>
At 01:13 a.m. 31/05/2010, you wrote:<br><br>
<blockquote type="cite" class="cite" cite="">Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt; added the comment:<br><br>
r78280 didn&#39;t remove the implicit coercion for rich comparisons;?? that&#39;s now been done in r81606.<br><br>
----------<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/issue5211">http://bugs.python.org/issue5211</a>&gt;<br>
_______________________________________Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</blockquote>

From report at bugs.python.org  Fri Nov 26 04:56:00 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 26 Nov 2010 03:56:00 +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: <1290743760.33.0.0558412929165.issue10299@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I don't think it's worth changing it. The table still provides a good overview, and having them at the end won't prevent people to find their doc.
Both the table and the page could be divided in sections though, if we find a way to group all the functions that makes enough sense (e.g. put together int/dict/list/set/etc, getattr/setattr/delattr, but then it's difficult to add more groups without maxing them too small).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Fri Nov 26 04:59:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 26 Nov 2010 03:59:35 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1290743975.71.0.853209286652.issue10273@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

If I implement what I suggested in #10535, it will be possible to deprecate them without too much trouble. I offer to do it after #10535.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10273>
_______________________________________

From report at bugs.python.org  Fri Nov 26 05:44:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 04:44:42 +0000
Subject: [issue8891] sort files before archiving for consistency
In-Reply-To: <1275599618.14.0.926604611145.issue8891@psf.upfronthosting.co.za>
Message-ID: <1290746682.11.0.042601540099.issue8891@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils2 -Distutils
stage:  -> unit test needed
type:  -> feature request
versions: +3rd party -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8891>
_______________________________________

From report at bugs.python.org  Fri Nov 26 05:46:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 04:46:01 +0000
Subject: [issue8730] Spurious test failure in distutils
In-Reply-To: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za>
Message-ID: <1290746761.18.0.106422923649.issue8730@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils2
nosy: +eric.araujo
versions: +3rd party, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8730>
_______________________________________

From report at bugs.python.org  Fri Nov 26 05:46:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 04:46:18 +0000
Subject: [issue8730] Spurious test failure in distutils
In-Reply-To: <1274012517.83.0.155461681494.issue8730@psf.upfronthosting.co.za>
Message-ID: <1290746778.77.0.357609311276.issue8730@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components:  -Distutils2
versions:  -3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8730>
_______________________________________

From report at bugs.python.org  Fri Nov 26 05:47:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 04:47:38 +0000
Subject: [issue2399] Patches for Tools/msi
In-Reply-To: <1205858738.04.0.681248681608.issue2399@psf.upfronthosting.co.za>
Message-ID: <1290746858.49.0.24690135366.issue2399@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Demos and Tools -Distutils, Windows
stage:  -> needs patch
type: behavior -> feature request
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2399>
_______________________________________

From report at bugs.python.org  Fri Nov 26 05:49:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 04:49:41 +0000
Subject: [issue10535] Enable warnings by default in unittest
In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>
Message-ID: <1290746981.61.0.747070920465.issue10535@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Library (Lib)
nosy: +eric.araujo
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10535>
_______________________________________

From report at bugs.python.org  Fri Nov 26 05:51:52 2010
From: report at bugs.python.org (Dan Stromberg)
Date: Fri, 26 Nov 2010 04:51:52 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1290747112.44.0.514111189261.issue6715@psf.upfronthosting.co.za>


Dan Stromberg <strombrg at gmail.com> added the comment:

I agree that ctypes is a bit more brittle - both ctypes and c extension modules can yield segfaults, but at least the c extension module is likely to give an error or warning when you rebuild it.

However, I'm getting the impression that:
1) In pypy, the C extension module layer isn't a complete emulation
2) In pypy, the C extension module is a bit disfavored compared to ctypes
3) In pypy, there's a performance expense for CPyExt compared to ctypes
3) (less important) In pypy, the C extension module layer is still too young to do much with at this time

I've been wondering if maybe there should be a way to check ctypes use against .h's at build time.  That way, the brittleness should be about the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Nov 26 05:52:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 04:52:59 +0000
Subject: [issue1059244] distutil bdist hardcodes the python location
Message-ID: <1290747179.59.0.675941232563.issue1059244@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If the distribution is pure Python, you can upload an sdist to PyPI.

bdist?s behavior is certainly not very useful, but we?re bound by compatibility.  Closing as wontfix.

----------
resolution:  -> wont fix
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1059244>
_______________________________________

From report at bugs.python.org  Fri Nov 26 05:54:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 04:54:26 +0000
Subject: [issue1059244] distutil bdist hardcodes the python location
Message-ID: <1290747266.69.0.425656771029.issue1059244@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Let me add that we welcome suggestions about making bdist better in distutils2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1059244>
_______________________________________

From report at bugs.python.org  Fri Nov 26 06:18:28 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Fri, 26 Nov 2010 05:18:28 +0000
Subject: [issue10535] Enable warnings by default in unittest
In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>
Message-ID: <1290748708.38.0.479789843134.issue10535@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Here's a working patch (without docs and tests).
I managed to filter the warnings by message without introducing a new type of warning. As it is, all the warnings related to deprecated unittest methods are printed only once per module, regardless of what methods are used and how many times.
I'm also thinking that it might be better to include the name of the deprecated method in the message and use three filters for fail* methods, assert* methods, and the assert*Regexp* methods that will be deprecated. This will show at worst 3 warnings per module, but the assert*Regexp* and the fail* methods are not so common, so it shouldn't be too nosy.
One "limitation" of the patch is that the per-module special-casing for unittest is not affect by the `warnings` argument, but it can be changed when -W is used and no `warnings` arg is passed.

Regrtest doesn't seem to use unittest, so it should be fixed separately (probably needs another issue).

----------
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19821/issue10535.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10535>
_______________________________________

From report at bugs.python.org  Fri Nov 26 06:28:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 05:28:49 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1290749329.98.0.364759764339.issue2504@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I have ported the patch to py3k, without tests errors but with test failures.  What is left to do:

1) Carefully assess bytes/str issues.  Decide to change the tests or the code.

2) Re-read over the new docs.

3) Exercise the updated msgfmt.py tool, which has no tests.

4) Add support in pygettext.py.

David, Mitar, nh2, David D., Olivier, Bernie, Wil, Wichert: Do you want to help with one of those tasks?

----------
resolution: accepted -> 
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19822/pgettext-3.2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Fri Nov 26 06:33:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 05:33:13 +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: <1290749593.6.0.314392608992.issue10510@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I am convinced.  Do you want to work on a patch?  Guidelines are found at http://www.python.org/dev/patches/

----------
stage:  -> needs patch
title: distutils.command.upload/register HTTP message headers: bad line termination -> distutils upload/register should use CRLF in HTTP requests

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Fri Nov 26 06:33:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 05:33:55 +0000
Subject: [issue10528] argparse uses %s in gettext calls
In-Reply-To: <1290687939.44.0.256494864194.issue10528@psf.upfronthosting.co.za>
Message-ID: <1290749635.44.0.245759774723.issue10528@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> eric.araujo
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10528>
_______________________________________

From report at bugs.python.org  Fri Nov 26 06:41:07 2010
From: report at bugs.python.org (Richard)
Date: Fri, 26 Nov 2010 05:41:07 +0000
Subject: [issue10537] IDLE crashes when you paste something.
In-Reply-To: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>
Message-ID: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>


New submission from Richard <vanchagreen at gmail.com>:

Whenever I paste anything into the IDLE shell, the program freezes, and then crashes.

I'm using Python 2.7.1rcl with a Version 10.6.4 Mac OSX

----------
components: IDLE
messages: 122441
nosy: 5ragar5
priority: normal
severity: normal
status: open
title: IDLE crashes when you paste something.
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10537>
_______________________________________

From report at bugs.python.org  Fri Nov 26 06:55:19 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 26 Nov 2010 05:55:19 +0000
Subject: [issue10122] Documentation typo fix and a side question
In-Reply-To: <20101125102735.GA1048@rubuntu>
Message-ID: <AANLkTikvACrV0enBztsYZFPpSutFa=HDf=bG72fJxb27@mail.gmail.com>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

The change is still not reflected. Why not? It's been more than a
month now. What is going on?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10122>
_______________________________________

From report at bugs.python.org  Fri Nov 26 08:32:58 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 26 Nov 2010 07:32:58 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1290756778.34.0.615118242968.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Careful: the ctypes module is much slower with pypy than with cpython.

In any case, a C extension module is preferred because the (platform-dependent) details of the liblzma library are defined in a .h header file, not as a ctypes description.  Future versions of the library are likely to be source-compatible, but may change some struct member for example; this would break a ctypes-based interface.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Nov 26 08:41:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 26 Nov 2010 07:41:07 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1290732668.35.0.605147211242.issue6715@psf.upfronthosting.co.za>
Message-ID: <4CEF6491.2010705@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> While I realize Python extension modules are pretty much the norm in
> CPython, it'd be pretty cool if xz support could be written overtop
> of ctypes.  ctypes seems to be emerging as the way of doing FFI
> across different python implementations.

There is a clear policy in CPython that ctypes must not be used
to implement library modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Nov 26 09:07:33 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 26 Nov 2010 08:07:33 +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: <1290758853.31.0.608837110631.issue10538@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The new "s*" code for PyArg_ParseTuple is used to fill a Py_buffer object from the arguments.  This object must be relased using PyBuffer_Release() after use.

However, if the object in the tuple does not support the new buffer interface, the old buffer interface is queried and the Py_buffer object is manually filled in.  For this case, the source object is _not_ increfed and buffer.obj remains set to 0.

This causes different semantics in the function for objects that are passed in:  If the Py_buffer interface is supported directly, then it is safe for the function to store this and release this at a later time.  If it isn't supported, then no extra reference to the object is got and the function cannot safely keep the Py_buffer object around.

The Fix is as follows:  Change line 1402 of getargs.c from:
PyBuffer_FillInfo(view, NULL, buf, count, 1, 0);
to
PyBuffer_FillInfo(view, arg, buf, count, 1, 0);

----------
messages: 122445
nosy: krisvale
priority: normal
severity: normal
status: open
title: PyArg_ParseTuple("s*") does not always incref object
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10538>
_______________________________________

From report at bugs.python.org  Fri Nov 26 09:07:59 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 26 Nov 2010 08:07:59 +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: <1290758879.89.0.4077163676.issue10538@psf.upfronthosting.co.za>


Changes by Kristj?n Valur J?nsson <kristjan at ccpgames.com>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10538>
_______________________________________

From report at bugs.python.org  Fri Nov 26 10:20:25 2010
From: report at bugs.python.org (Wichert Akkerman)
Date: Fri, 26 Nov 2010 09:20:25 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1290763225.11.0.369187609757.issue2504@psf.upfronthosting.co.za>


Wichert Akkerman <wichert at wiggy.net> added the comment:

I can help test changes for python 2.x. The python 3.x ecosystem is at least a year away from becoming interesting for me I'm afraid.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Fri Nov 26 12:34:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Nov 2010 11:34:42 +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: <1290771282.59.0.555547822988.issue10538@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/issue10538>
_______________________________________

From report at bugs.python.org  Fri Nov 26 12:37:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Nov 2010 11:37:21 +0000
Subject: [issue10122] Documentation typo fix and a side question
In-Reply-To: <1287238144.34.0.432770346734.issue10122@psf.upfronthosting.co.za>
Message-ID: <1290771441.59.0.872501835324.issue10122@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't waste my time by merging every little typo fix to the maintenance branches immediately; I rather merge them all at once every now and then.  You will certainly understand that nobody is harmed by a stray "d", even if it has a pointy tip.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10122>
_______________________________________

From report at bugs.python.org  Fri Nov 26 12:41:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Nov 2010 11:41:16 +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: <1290771676.92.0.88986279389.issue10299@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Dividing the table in sections makes sense to me; it provides the kind of grouping that is helpful sometimes, but cannot be kept when sorting alphabetically.  So when the table is grouped, the actual docs can remain alphabetized.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Fri Nov 26 12:50:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Nov 2010 11:50:53 +0000
Subject: [issue10526] Minor typo in What's New in Python 2.7
In-Reply-To: <1290681942.88.0.460201126168.issue10526@psf.upfronthosting.co.za>
Message-ID: <1290772253.71.0.985843459359.issue10526@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r86794.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10526>
_______________________________________

From report at bugs.python.org  Fri Nov 26 12:58:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Nov 2010 11:58:57 +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: <1290772737.01.0.501042888065.issue9312@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, you're right; you could have linked to the correct -c option by using this form:  :option:`unittest -c`

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Fri Nov 26 13:06:12 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Nov 2010 12:06:12 +0000
Subject: [issue10420] Document of Bdb.effective is wrong.
In-Reply-To: <1289775674.64.0.742644713798.issue10420@psf.upfronthosting.co.za>
Message-ID: <1290773172.34.0.144212048557.issue10420@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r86798.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10420>
_______________________________________

From report at bugs.python.org  Fri Nov 26 13:13:47 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Nov 2010 12:13:47 +0000
Subject: [issue10172] code block has no syntax coloring
In-Reply-To: <1287754685.88.0.964365557653.issue10172@psf.upfronthosting.co.za>
Message-ID: <1290773627.8.0.351577989978.issue10172@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is because the Python used to render doesn't recognize the new-style exception catching; this will be fine once the system is upgraded to 2.6.

----------
nosy: +georg.brandl
resolution:  -> later
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10172>
_______________________________________

From report at bugs.python.org  Fri Nov 26 14:12:35 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 26 Nov 2010 13:12:35 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1290777155.61.0.573607722281.issue5211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I think that's expected behaviour.  Note that int vs float behaves in the same way as float vs complex:

>>> class xint(int):
...     def __radd__(self, other):
...         print "__radd__"
...         return 42
... 
>>> 3 + xint(5)
__radd__
42
>>> 3.0 + xint(5)  # xint.__radd__ not called.
8.0

As with your example, the float.__add__ method is happy to deal with an int or an instance of any subclass of int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

From report at bugs.python.org  Fri Nov 26 14:17:41 2010
From: report at bugs.python.org (Davide Rizzo)
Date: Fri, 26 Nov 2010 13:17:41 +0000
Subject: [issue10535] Enable warnings by default in unittest
In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>
Message-ID: <1290777461.69.0.273900159673.issue10535@psf.upfronthosting.co.za>


Changes by Davide Rizzo <sorcio at gmail.com>:


----------
nosy: +davide.rizzo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10535>
_______________________________________

From report at bugs.python.org  Fri Nov 26 14:20:58 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 26 Nov 2010 13:20:58 +0000
Subject: [issue1059244] distutil bdist hardcodes the python location
Message-ID: <1290777658.17.0.138656418444.issue1059244@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

As I can't reopen this issue, I'd like to ask for another opinion before closing this ticket. I think it's closed prematurely. For the bare minimum there should be a link to corresponding issue in distutils2 project.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1059244>
_______________________________________

From report at bugs.python.org  Fri Nov 26 14:25:52 2010
From: report at bugs.python.org (Brian Jones)
Date: Fri, 26 Nov 2010 13:25:52 +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: <1290777952.13.0.426325934797.issue10510@psf.upfronthosting.co.za>


Brian Jones <bkjones at gmail.com> added the comment:

Sure. I'll create a patch in the next few days and submit it. Thanks for the link to the guidelines. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Fri Nov 26 15:09:04 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 26 Nov 2010 14:09:04 +0000
Subject: [issue1059244] distutil bdist hardcodes the python location
Message-ID: <1290780544.99.0.439231696516.issue1059244@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I am +1 with what Eric said. I'd suggest that you send a mail to teh distutils2 development mailing list to make some proposals.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1059244>
_______________________________________

From report at bugs.python.org  Fri Nov 26 15:12:04 2010
From: report at bugs.python.org (Brian Jones)
Date: Fri, 26 Nov 2010 14:12:04 +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: <1290780724.02.0.555193302514.issue10510@psf.upfronthosting.co.za>


Brian Jones <bkjones at gmail.com> added the comment:

So... have I missed a memo, or is it currently impossible to test the current svn version of distutils in the current svn version of Python?

The tests for (at least) register and upload are written using Python 2.x syntax and modules. How are new features and fixes for distutils being tested? Is it valid to use a 2.x version of Python to test the trunk version of distutils? 

Sorry if these questions have really obvious answers. First time patcher :?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Fri Nov 26 15:18:07 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 26 Nov 2010 14:18:07 +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: <1290781087.55.0.651137136442.issue10510@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

If you can make your server work with the current implementation, I'd rather not change this in distutils but in distutils2.

Distutils is frozen and we make only bug fixes. By bug fix I mean anything that is a bug. A non-strict implementation of the EOLs is not a bug, and I suggest that you write your patch against distutils2.

Eric, thanks for all the hard work in triaging the bugs ! Let's make sure we do the bare minimal maintenance in distutils, and suggest to people to contribute in distutils2. 

Brian, for distutils1, the register and upload command would be  considered buggy if they don't work for PyPI, which is not the case.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Fri Nov 26 15:18:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 26 Nov 2010 14:18:11 +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: <1290781091.89.0.61360410463.issue10538@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10538>
_______________________________________

From report at bugs.python.org  Fri Nov 26 15:24:37 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 26 Nov 2010 14:24:37 +0000
Subject: [issue6983] Add specific get_platform() for freebsd
In-Reply-To: <1253751823.43.0.939101436857.issue6983@psf.upfronthosting.co.za>
Message-ID: <1290781477.34.0.0615295203418.issue6983@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
components: +Distutils2, Library (Lib) -Distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6983>
_______________________________________

From report at bugs.python.org  Fri Nov 26 15:44:25 2010
From: report at bugs.python.org (Brian Jones)
Date: Fri, 26 Nov 2010 14:44:25 +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: <1290782665.55.0.376455532117.issue10510@psf.upfronthosting.co.za>


Brian Jones <bkjones at gmail.com> added the comment:

If it's not a bug in distutils1, I imagine it will not be a bug in distutils2, since that will also presumably work with PyPI, and PyPI will be the single solitary supported implementation of the service? 

I also don't see distutils2 in this list http://svn.python.org/projects/  which means either distutils2 isn't part of the standard library, or it doesn't follow the documented patch submission process, or perhaps both? Insight welcome here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Fri Nov 26 16:02:01 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 26 Nov 2010 15:02:01 +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: <1290783721.73.0.305107851484.issue10510@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> If it's not a bug in distutils1, I imagine it will not be a bug in distutils2

Yes that would be a feature request. we would be happy to add. e.g. make the commands works with server X ou server Y.


> I also don't see distutils2 in this list http://svn.python.org/projects/  which means either distutils2 isn't part of the standard library, or it doesn't follow the documented patch submission process, or perhaps both? Insight welcome here.

Distutils2 is developed at http://hg.python.org/distutils2 and will be included when ready in the stdlib (circa 3.3), as a distutils replacer. It's in fact the distutils trunk, with lots of changes (some are backward incompatible). It will be installable from 2.4 onward. 

It does not follow the same process. Which I have described in python-dev last week: http://mail.python.org/pipermail/python-dev/2010-November/105772.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10510>
_______________________________________

From report at bugs.python.org  Fri Nov 26 16:34:05 2010
From: report at bugs.python.org (Jamie Murray)
Date: Fri, 26 Nov 2010 15:34:05 +0000
Subject: [issue10539] Regular expression not checking 'range' element on 1st
	char in string.
In-Reply-To: <1290785645.11.0.221832433398.issue10539@psf.upfronthosting.co.za>
Message-ID: <1290785645.11.0.221832433398.issue10539@psf.upfronthosting.co.za>


New submission from Jamie Murray <txrxfx at gmail.com>:

The first char in a word is omitted from being checked against the 'range' element of the 1st part of this expression. 

The second char is properly checked to see if it's in range 

# Desired safe string to expect
goodString = "f42e6be1-29bf-4f3c-ba58-1ae1d9ca5f88"

# Test string to return False if it's not within reg ex range.
# but still returns a false positive even though the g at the start is outside of a-f range.
badString = "g42e6be1-29bf-4f3c-ba58-1ae1d9ca5f88"

# 2nd test string which does return a false result correctly.
otherBadString = "fg2e6be1-29bf-4f3c-ba58-1ae1d9ca5f88"

See attached file for example.

"Python 2.5.4 (r254:67916, Dec 23 2008, 15:19:34) [MSC v.1400 64 bit (AMD64)] on
win32"

----------
components: Regular Expressions
files: RegExPyBug.py
messages: 122461
nosy: TxRxFx
priority: normal
severity: normal
status: open
title: Regular expression not checking 'range' element on 1st char in string.
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file19823/RegExPyBug.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10539>
_______________________________________

From report at bugs.python.org  Fri Nov 26 17:00:35 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 26 Nov 2010 16:00:35 +0000
Subject: [issue10540] test_shutil fails on Windows after r86733
In-Reply-To: <1290787235.82.0.346184396433.issue10540@psf.upfronthosting.co.za>
Message-ID: <1290787235.82.0.346184396433.issue10540@psf.upfronthosting.co.za>


New submission from Brian Curtin <curtin at acm.org>:

My build slave shows a test failure at test_dont_copy_file_onto_link_to_itself. This happens because the implementation of _samefile in Lib/shutil.py (line 70) doesn't work for Windows hard links.

Patch on the way.

----------
assignee: brian.curtin
components: Library (Lib), Windows
messages: 122462
nosy: brian.curtin
priority: normal
severity: normal
stage: needs patch
status: open
title: test_shutil fails on Windows after r86733
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10540>
_______________________________________

From report at bugs.python.org  Fri Nov 26 17:02:14 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Fri, 26 Nov 2010 16:02:14 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>


New submission from Walter D?rwald <walter at livinglogic.de>:

Running regrtest.py with coverage option seems to be broken for the py3k branch at the moment. Run the following commands on the shell:

wget http://svn.python.org/snapshots/python3k.tar.bz2
tar xjf python3k.tar.bz2
cd python
./configure --enable-unicode=ucs4 --with-pydebug
make coverage
./python.exe Lib/test/regrtest.py -T -N test_urllib

This gives the following output:

[1/1] test_urllib
Not printing coverage data for 'Lib/test/regrtest.py': [Errno 2] No such file or directory: 'Lib/test/regrtest.py'
Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 1502, in <module>
    main()
  File "Lib/test/regrtest.py", line 698, in main
    r.write_results(show_missing=True, summary=True, coverdir=coverdir)
  File "/Users/walter/x/pybug/python/Lib/trace.py", line 331, in write_results
    with open(filename, 'rb') as fp:
IOError: [Errno 2] No such file or directory: 'Lib/test/regrtest.py'
[123146 refs]

I'm testing on Mac OS X 10.6.5.

Attached is the complete log of the shell session.

This bug might be related to issue 10329, as the failing line was introduced in r86303.

----------
assignee: haypo
components: Tests
files: build.log
messages: 122463
nosy: doerwalter, haypo
priority: normal
severity: normal
status: open
title: regrtest.py -T broken
Added file: http://bugs.python.org/file19824/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Fri Nov 26 17:16:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 26 Nov 2010 16:16:07 +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: <1290788167.05.0.282092739881.issue10542@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

As discussed in issue 10521 and the sprawling "len(chr(i)) = 2?" thread [1] on python-dev, many functions in python library behave differently on narrow and wide builds.  While there are unavoidable differences such as the length of strings with non-BMP characters, many functions can work around these differences.  For example, the ord() function already produces integers over 0xFFFF when given a surrogate pair as a string of length two on a narrow build.  Other functions such as str.isalpha(), are not yet aware of surrogates.  See also issue9200.

A consensus is developing that non-BMP characters support on narrow builds is here to stay and that naive functions should be fixed.  Unfortunately, working with surrogates in python code is tricky because unicode C-API does not provide much support and existing examples of surrogate processing look like this:

-        while (u != uend && w != wend) {
-            if (0xD800 <= u[0] && u[0] <= 0xDBFF
-                && 0xDC00 <= u[1] && u[1] <= 0xDFFF)
-            {
-                *w = (((u[0] & 0x3FF) << 10) | (u[1] & 0x3FF)) + 0x10000;
-                u += 2;
-            }
-            else {
-                *w = *u;
-                u++;
-            }
-            w++;
-        }

The attached patch introduces a Py_UNICODE_NEXT() macro that allows replacing the code above with two lines:

+        while (u != uend && w != wend)
+            *w++ = Py_UNICODE_NEXT(u, uend);

The patch also introduces a set of macros for manipulating the surrogates, but I have not started replacing more instances of verbose surrogate processing because I would like to first look for higher level abstractions such as Py_UNICODE_NEXT().  For example, there are many instances that can benefit from Py_UNICODE_PUT_NEXT(ptr, ch) macro that would put a UCS4 character ch into Py_UNICODE buffer pointed by ptr and advance ptr by 1 or 2 units as necessary.


[1] http://mail.python.org/pipermail/python-dev/2010-November/105908.html

----------
assignee: belopolsky
components: Extension Modules, Interpreter Core, Unicode
files: unicode-next.diff
keywords: patch
messages: 122464
nosy: Rhamphoryncus, amaury.forgeotdarc, belopolsky, eric.smith, ezio.melotti, lemburg, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Py_UNICODE_NEXT and other macros for surrogates
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19825/unicode-next.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Fri Nov 26 17:35:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 26 Nov 2010 16:35:14 +0000
Subject: [issue9200] str.isprintable() is always False for large code points
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1290789314.44.0.597997500566.issue9200@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

AFAICT, all ctype methods (isalpha, isdigit, etc.) have the same problem.  I posted a patch at issue10542 that introduces a Py_UNICODE_NEXT() macro that can help fixing all these methods.  I am adding #10542 as a dependency and if there are no objections, I will change the title to extend the scope of this issue to cover all ctype methods.

----------
assignee:  -> belopolsky
components: +Interpreter Core
dependencies: +Py_UNICODE_NEXT and other macros for surrogates
nosy: +belopolsky
stage:  -> patch review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Fri Nov 26 17:39:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 26 Nov 2010 16:39:21 +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: <1290789561.68.0.0806213306493.issue10542@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +haypo, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Fri Nov 26 17:53:45 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 26 Nov 2010 16:53:45 +0000
Subject: [issue10540] test_shutil fails on Windows after r86733
In-Reply-To: <1290787235.82.0.346184396433.issue10540@psf.upfronthosting.co.za>
Message-ID: <1290790425.48.0.501049440747.issue10540@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Here is a patch.

os.path.samefile and hard links don't work for Windows the same way they do for Mac/Linux. In the case where we are on Windows and a link comes into the _samefile function, check that it's a link and then use os.path.sameopenfile. If it's not a link but a regular file, or it's some other OS, do the os.path.samefile check.

----------
keywords: +patch
nosy: +tarek
Added file: http://bugs.python.org/file19826/issue10540.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10540>
_______________________________________

From report at bugs.python.org  Fri Nov 26 17:58:58 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 26 Nov 2010 16:58:58 +0000
Subject: [issue10543] Test discovery (unittest) does not work with jython
In-Reply-To: <1290790738.08.0.631602172773.issue10543@psf.upfronthosting.co.za>
Message-ID: <1290790738.08.0.631602172773.issue10543@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

This is because jython creates bytecode files with names like "tests/testwith$py.class". unittest test discovery splits the extension off __file__ to compare module.__file__ to the expected path.

----------
messages: 122467
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Test discovery (unittest) does not work with jython

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10543>
_______________________________________

From report at bugs.python.org  Fri Nov 26 17:59:49 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 26 Nov 2010 16:59:49 +0000
Subject: [issue10543] Test discovery (unittest) does not work with jython
In-Reply-To: <1290790738.08.0.631602172773.issue10543@psf.upfronthosting.co.za>
Message-ID: <1290790789.32.0.648315828422.issue10543@psf.upfronthosting.co.za>


Changes by Michael Foord <michael at voidspace.org.uk>:


----------
assignee:  -> michael.foord
components: +Library (Lib)
type:  -> behavior
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10543>
_______________________________________

From report at bugs.python.org  Fri Nov 26 18:23:37 2010
From: report at bugs.python.org (SilentGhost)
Date: Fri, 26 Nov 2010 17:23:37 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290792217.87.0.39953975472.issue9509@psf.upfronthosting.co.za>


Changes by SilentGhost <michael.mischurow+bpo at gmail.com>:


Removed file: http://bugs.python.org/file19815/test_argparse.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Fri Nov 26 18:25:57 2010
From: report at bugs.python.org (SilentGhost)
Date: Fri, 26 Nov 2010 17:25:57 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290792357.6.0.0456847216981.issue9509@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

On windows proposed changes to Lib/test/test_argparse.py cause it to enter an infinite loop in TempDirMixin.tearDown method.

As it seemed exclusively Windows issue, this new patch replaces while loop with the ignore_errors parameter for shutil.rmtree.

Now all test pass.

----------
Added file: http://bugs.python.org/file19827/test_argparse.py.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Fri Nov 26 18:42:44 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 26 Nov 2010 17:42:44 +0000
Subject: [issue10543] Test discovery (unittest) does not work with jython
In-Reply-To: <1290790738.08.0.631602172773.issue10543@psf.upfronthosting.co.za>
Message-ID: <1290793364.29.0.26896982923.issue10543@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Won't need fixing in 3.2. The __pycache__ changes mean that the module.__file__ no longer points to the compiled bytecode file.

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10543>
_______________________________________

From report at bugs.python.org  Fri Nov 26 19:35:50 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 26 Nov 2010 18:35:50 +0000
Subject: [issue10535] Enable warnings by default in unittest
In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>
Message-ID: <1290796550.1.0.365997218816.issue10535@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

"I'm also thinking that it might be better to include the name of the deprecated method in the message and use three filters for fail* methods, assert* methods, and the assert*Regexp* methods that will be deprecated."

That sounds good, well - it sounds *essential*.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10535>
_______________________________________

From report at bugs.python.org  Fri Nov 26 19:37:03 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 26 Nov 2010 18:37:03 +0000
Subject: [issue10539] Regular expression not checking 'range' element on 1st
	char in string.
In-Reply-To: <1290785645.11.0.221832433398.issue10539@psf.upfronthosting.co.za>
Message-ID: <1290796623.6.0.855979725611.issue10539@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm not sure I understand. The output I get is:

f42e6be1-29bf-4f3c-ba58-1ae1d9ca5f88
g42e6be1-29bf-4f3c-ba58-1ae1d9ca5f88
False

The first string matches. The second string matches because the leading "g" is being matched by "\w". The third string does not match because the "g" in the second position is not matched by "[0-9][a-f]".

For the second string you're matching "\w" followed by 7 "[0-9][a-f]", just as the regex allows.

Am I missing something?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10539>
_______________________________________

From report at bugs.python.org  Fri Nov 26 19:41:24 2010
From: report at bugs.python.org (Blair)
Date: Fri, 26 Nov 2010 18:41:24 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <AANLkTimPpmyn7MhBK6r95dPNku8d3CXcbSvjH1BGV88x@mail.gmail.com>


Blair <bidihall at gmail.com> added the comment:

I see your point Mark, however it does not seem to be the right way to do
this.

Are you aware that Python has formally specified this behaviour somewhere? I
could not find an explicit reference in the documentation.

The problem that has been fixed is covered in the documentation:

(3.4.8. Emulating numeric types: Note
If the right operand???s type is a subclass of the left operand???s type and
that subclass provides the
reflected method for the operation, this method will be called before the
left operand???s non-reflected method.
This behavior allows subclasses to override their ancestors??? operations.)

This rule is needed so that mixed-type arithmetic operations do not revert
to the ancestor's type. However, one would expect that different numeric
types (int float complex)  would all behave in a similar way. For example,

xi = xint(3)
3 + xi  # is an xint(6)
3.0 + xi # is float(6)

This is the same problem as the one that has been fixed from a practical
point of view. Such behaviour is not going to be useful (IMO).

It seems to me that xint.__radd__ would need to be called if the left
operand is a subclass of any of the number types (in this case,
isinstance(left_op,numbers.Complex) == True).

Am I missing something?

Mark Dickinson <dickinsm at gmail.com> added the comment:

I think that's expected behaviour.  Note that int vs float behaves in the
same way as float vs complex:

...     def __radd__(self, other):
...         print "__radd__"
...         return 42
...
>>> 3 + xint(5)
__radd__
42
>>> 3.0 + xint(5)  # xint.__radd__ not called.
8.0

As with your example, the float.__add__ method is happy to deal with an int
or an instance of any subclass of int.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

----------
Added file: http://bugs.python.org/file19828/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
-------------- next part --------------
I see your point Mark, however it does not seem to be the right way to do this. <br><br>Are you aware that Python has formally specified this behaviour somewhere? I could not find an explicit reference in the documentation.<br>
<br>The problem that has been fixed is covered in the documentation:<br><br>(3.4.8. Emulating numeric types: Note<br>If the right operand???s type is a subclass of the left operand???s type and that subclass provides the<br>reflected method for the operation, this method will be called before the left operand???s non-reflected method.<br>
This behavior allows subclasses to override their ancestors??? operations.)<br><br>This rule is needed so that mixed-type arithmetic operations do not revert to the ancestor&#39;s type. However, one would expect that different numeric types (int float complex)?? would all behave in a similar way. For example,<br>
<br>xi = xint(3)<br>3 + xi?? # is an xint(6)<br>3.0 + xi # is float(6)<br><br>This is the same problem as the one that has been fixed from a practical point of view. Such behaviour is not going to be useful (IMO). <br><br>
It seems to me that xint.__radd__ would need to be called if the left operand is a subclass of any of the number types (in this case, isinstance(left_op,numbers.Complex) == True). <br><br>Am I missing something? <br><br>
<blockquote type="cite" class="cite" cite="">Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt; added the comment:<br><br>
I think that&#39;s expected behaviour.?? Note that int vs float behaves in the same way as float vs complex:<br><br>
&gt;&gt;&gt; class xint(int):<br>
...???????? def __radd__(self, other):<br>
...???????????????? print &quot;__radd__&quot;<br>
...???????????????? return 42<br>
... <br>
&gt;&gt;&gt; 3 + xint(5)<br>
__radd__<br>
42<br>
&gt;&gt;&gt; 3.0 + xint(5)?? # xint.__radd__ not called.<br>
8.0<br><br>
As with your example, the float.__add__ method is happy to deal with an int or an instance of any subclass of int.<br><br>
----------<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/issue5211">http://bugs.python.org/issue5211</a>&gt;<br>
_______________________________________</blockquote>

From report at bugs.python.org  Fri Nov 26 19:51:45 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 26 Nov 2010 18:51:45 +0000
Subject: [issue10539] Regular expression not checking 'range' element on 1st
	char in string.
In-Reply-To: <1290785645.11.0.221832433398.issue10539@psf.upfronthosting.co.za>
Message-ID: <1290797505.92.0.203689035136.issue10539@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't think so; closing as invalid.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10539>
_______________________________________

From report at bugs.python.org  Fri Nov 26 20:05:40 2010
From: report at bugs.python.org (Jamie Murray)
Date: Fri, 26 Nov 2010 19:05:40 +0000
Subject: [issue10539] Regular expression not checking 'range' element on 1st
	char in string.
In-Reply-To: <1290797505.92.0.203689035136.issue10539@psf.upfronthosting.co.za>
Message-ID: <AANLkTimysQ8Eb5Mcj=t0Ny7Q__qT5ybF7Gozq4rsDioh@mail.gmail.com>


Jamie Murray <txrxfx at gmail.com> added the comment:

Apologies, sincere and most humble apolgies doh!
On 26 Nov 2010 18:51, "Georg Brandl" <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
> I don't think so; closing as invalid.
>
> ----------
> nosy: +georg.brandl
> resolution: -> invalid
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10539>
> _______________________________________

----------
Added file: http://bugs.python.org/file19829/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10539>
_______________________________________
-------------- next part --------------
<p>Apologies, sincere and most humble apolgies doh!</p>
<div class="gmail_quote">On 26 Nov 2010 18:51, &quot;Georg Brandl&quot; &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br type="attribution">&gt; <br>&gt; Georg Brandl &lt;<a href="mailto:georg at python.org">georg at python.org</a>&gt; added the comment:<br>
&gt; <br>&gt; I don&#39;t think so; closing as invalid.<br>&gt; <br>&gt; ----------<br>&gt; nosy: +georg.brandl<br>&gt; resolution:  -&gt; invalid<br>&gt; status: open -&gt; closed<br>&gt; <br>&gt; _______________________________________<br>
&gt; Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>&gt; &lt;<a href="http://bugs.python.org/issue10539">http://bugs.python.org/issue10539</a>&gt;<br>&gt; _______________________________________<br>
</div>

From report at bugs.python.org  Fri Nov 26 20:21:19 2010
From: report at bugs.python.org (Inyeol Lee)
Date: Fri, 26 Nov 2010 19:21:19 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>


New submission from Inyeol Lee <inyeol.lee at gmail.com>:

Simple coroutine with for loop works:

>>> def pack_a():
        while True:
            L = []
            for i in range(2):
                L.append((yield))
            print(L)

>>> pa = pack_a()
>>> next(pa)
>>> pa.send(1)
>>> pa.send(2)
[1, 2]
>>>

If using list comprehension (generator expression), it fails:

>>> def pack_b():
        while True:
            L = [(yield) for i in range(2)]
            print(L)

>>> pb = pack_b()
<endless loop here>


I understand what's going on here - generator expression is converted to nested function and there's no way to either stop the execution inside nested function (since it's not started yet!) or send() a value to its yield expression. Still I think this behavior is a bug and needs fixed.

- best fix would make it behave the same as for loop.
- if it's not fixable, yield expression inside genexp should not be allowed.

----------
components: Interpreter Core
messages: 122475
nosy: Inyeol.Lee
priority: normal
severity: normal
status: open
title: yield expression inside generator expression does nothing
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Fri Nov 26 21:31:56 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 26 Nov 2010 20:31:56 +0000
Subject: [issue10532] A bug related to matching the empty string
In-Reply-To: <1290703155.74.0.717125241032.issue10532@psf.upfronthosting.co.za>
Message-ID: <1290803516.22.0.238075728198.issue10532@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Closing this issue since it appears to not be a bug.

----------
nosy: +ned.deily
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10532>
_______________________________________

From report at bugs.python.org  Fri Nov 26 21:50:32 2010
From: report at bugs.python.org (rurpy the second)
Date: Fri, 26 Nov 2010 20:50:32 +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: <1290804632.88.0.494003444216.issue10545@psf.upfronthosting.co.za>


New submission from rurpy the second <rurpy at yahoo.com>:

The Python HOWTOs->Idioms and Anti-Idioms has a section
"Using Backslash to Continue Statements".

It says that line continuation is "dangerous" and gives two reasons.

1. Hard to see a space after the backslash.

This is not "dangerous" as it cause an impossible-to-miss syntax 
error (as pointed out in the following sentence.)

2. It can cause other "subtle" errors. 

It gives a code example purporting to demonstrate this but without
saying what the input data to the code is or what the resulting
problem is.  I spent a while trying to figure it out unsuccessfully.

In  
http://www.mail-archive.com/python-list at python.org/msg249344.html
a number of c.l.p regulars did not figure it out either.

I also note related bug http://bugs.python.org/issue7391 that points
out that avoinding backslashed continuations with parens is not 
always possible.

So I suggest...

1. If the the given example actually illustrates a real problem,
document clearly what it is.  This is a reference manual, not a
quiz book.

2. If not, then remove that argument.  Now the only reason for
not using backslashes is that a hard-to-see space after the
backslash will cause a syntax error.  That is neither dangerous
or a strong reason not to do it.  An unstated reason is that 
PEP-8 recommends against it but its recommendation is not absolute
and is based only on aethtetics.  With no real arguments against
using it other than style, it should not be documented as an anti-idiom, recommendations against it should remain only in
PEP-8 with other such style guidelines, and this section should 
be removed from the Anti-Idioms chapter.

----------
assignee: docs at python
components: Documentation
messages: 122477
nosy: docs at python, rurpy2
priority: normal
severity: normal
status: open
title: remove or rewrite "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  Fri Nov 26 22:01:55 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 26 Nov 2010 21:01:55 +0000
Subject: [issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you
	paste something.
In-Reply-To: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>
Message-ID: <1290805315.36.0.390402723259.issue10537@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This appears to be another variant of the IDLE, OS X 10.6, 64-bit, Apple-supplied Tk 8.5 problems.  As a workaround, you can re-install 2.7rc1 using the 32-bit-only installer; IDLE there does not exhibit these problems.

----------
assignee:  -> ned.deily
components: +Macintosh
nosy: +ned.deily, ronaldoussoren
priority: normal -> critical
stage:  -> needs patch
title: IDLE crashes when you paste something. -> OS X IDLE 2.7rc1 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 Nov 26 22:08:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 26 Nov 2010 21:08:32 +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: <1290805712.04.0.751752211923.issue10546@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Python3 doc tells that UTF-16-LE and UTF-16-BE only support BMP characters. What? I think that it is wrong.

It was maybe wrong with Python2 and narrow build (unichr() only supports BMP characters), but it is no more true in Python3.

----------
assignee: docs at python
components: Documentation
files: utf_16_bmp.patch
keywords: patch
messages: 122479
nosy: docs at python, haypo
priority: normal
severity: normal
status: open
title: UTF-16-LE and UTF-16-BE support non-BMP characters
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19830/utf_16_bmp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10546>
_______________________________________

From report at bugs.python.org  Fri Nov 26 23:36:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Nov 2010 22:36:05 +0000
Subject: [issue1178] IDLE - add "paste code" functionality
In-Reply-To: <1190153010.77.0.038299898053.issue1178@psf.upfronthosting.co.za>
Message-ID: <1290810965.86.0.291051889502.issue1178@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I would really like something like this -- for 3.2b1 next week.
I am constantly running posted interactive code and the lack of this is a major nuisance. There seems to be a glitch in how the editor deals with '>>> ' when trying to delete it.

However, as well as removing '>>> ' and '... ' from code lines,
I would like it to add '# ' to output lines. I do not see that in the patch.

Since I have XP also (and access to Win7) I would consider this working on those two sufficient reason to commit. As near as I can tell, the patch cannot possibly break other systems as long as the feature is not used. Once in the beta, it could get wider testing.

----------
nosy: +terry.reedy -nobody
priority: low -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1178>
_______________________________________

From report at bugs.python.org  Fri Nov 26 23:45:15 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Nov 2010 22:45:15 +0000
Subject: [issue1178] IDLE - add "paste code" functionality
In-Reply-To: <1190153010.77.0.038299898053.issue1178@psf.upfronthosting.co.za>
Message-ID: <1290811515.33.0.317629042463.issue1178@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

An alternative approach would be to leave pasting alone but add a 
'Convert interactive code' option to the format menu, with keycode alt-v (not currently used as far as I can see).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1178>
_______________________________________

From report at bugs.python.org  Fri Nov 26 23:48:30 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Nov 2010 22:48:30 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1290811710.23.0.188434887249.issue5150@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution: fixed -> 
stage: committed/rejected -> commit review
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Sat Nov 27 00:13:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 23:13:59 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1290813239.47.0.343471582417.issue2504@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

New features don?t go into stable branches.

The patch is also reviewable at http://codereview.appspot.com/3340041

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
_______________________________________

From report at bugs.python.org  Sat Nov 27 00:37:25 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Nov 2010 23:37:25 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290814645.9.0.0262811772107.issue10521@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

As a practical matter, I think that for at least the next decade, people are at least as likely to want to fill with a composed, multi-BMP-codepoint 'char' (grapheme) as with a non-BMP char. So to me, failure with the latter is no worse than failure with the former.

The underlying problem is that centering k chars within n spaces with fill i is based on one-char per code encodings *and* fixed pitch fonts with one-char per space. That model is not universally applicable, so I do not consider it a bug that functions based on that model are also not universally applicable. Perhaps docs should be clearer about the limitations of many of the string methods in the new context.

A full general solution to the general problem of centering requires a shift to physical units (points or mm) and detailed font information, including kerning. This is beyond the scope of a string method.

So I consider this a feature request for a partial generalization of unclear utility and unclear definition.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Sat Nov 27 00:42:06 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 26 Nov 2010 23:42:06 +0000
Subject: [issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you
	paste something.
In-Reply-To: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>
Message-ID: <1290814926.25.0.959981275234.issue10537@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Is this a duplicate of other issues (close?)?
Is this an Apple problem beyond our control (close?)?

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10537>
_______________________________________

From report at bugs.python.org  Sat Nov 27 00:47:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 23:47:18 +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: <1290815238.26.0.221435583227.issue9312@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great, thanks!  New markup committed as r86823, long lines rewrapped in r86824 (along with a few minor touch-ups).

I think we?re good now, I?ll backport shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9312>
_______________________________________

From report at bugs.python.org  Sat Nov 27 00:56:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 26 Nov 2010 23:56:04 +0000
Subject: [issue1059244] distutil bdist hardcodes the python location
Message-ID: <1290815764.83.0.0854760797315.issue1059244@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Distutils2 bugs are tracked here (bugs.python.org), feel free to open a feature request for the Distutils2 component.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1059244>
_______________________________________

From report at bugs.python.org  Sat Nov 27 01:08:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 00:08:31 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290814645.9.0.0262811772107.issue10521@psf.upfronthosting.co.za>
Message-ID: <AANLkTimjNAVQ_DDWbmGu023nqCUSEfyoO37upSduas12@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 26, 2010 at 6:37 PM, Terry J. Reedy <report at bugs.python.org> wrote:
>
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
>
> As a practical matter, I think that for at least the next decade, people are at least as likely to
> want to fill with a composed, multi-BMP-codepoint 'char' (grapheme) as with a non-BMP char.
> So to me, failure with the latter is no worse than failure with the former.
>

I disagree. '\N{AEGEAN WORD SEPARATOR DOT}'  ('?') looks like a
reasonably shaped fill character, while say 'Z\N{COMBINING ACUTE
ACCENT}\N{COMBINING GRAVE ACCENT}' ('??') does not.  Yet this is not
the point of this bug report.  The point is that Python user should
not care (much) about how many bytes per character Python uses under
the hood or what is the numeric value of the character that she can
enter in her program.

> The underlying problem is that centering k chars within n spaces with fill i is based
> on one-char per code encodings *and* fixed pitch fonts with one-char per space.

No. ' Section Title '.center(40, '*') will look good regardless of
font width and even more so when combined with <center> tag or its
equivalent in a given application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Sat Nov 27 01:25:12 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 27 Nov 2010 00:25:12 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290817512.52.0.208964580297.issue10521@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think these macros would be a reasonable approach. I think str.center, etc. should support non-BMP chars, because to not do so can raise an exception. Supporting composed graphemes seems like another problem altogether. And while we could fix that, it's clearly a larger step.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Sat Nov 27 01:27:05 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 27 Nov 2010 00:27:05 +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: <1290817625.25.0.105793802375.issue10542@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

In addition to the proposed Py_UNICODE_NEXT and Py_UNICODE_PUT_NEXT,  str.__format__ would also need a function that tells it how many Py_UNICODEs are needed to store a given Py_UCS4.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 01:31:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 00:31:37 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290817625.25.0.105793802375.issue10542@psf.upfronthosting.co.za>
Message-ID: <AANLkTinfuv-UvuiML=PBCc0390gWpq_-rPb=d3n1qwDi@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 26, 2010 at 7:27 PM, Eric Smith <report at bugs.python.org> wrote:
..
>
> In addition to the proposed Py_UNICODE_NEXT and Py_UNICODE_PUT_NEXT, >?str.__format__ would also need a function that tells it how many Py_UNICODEs
> are needed to store a given Py_UCS4.

Yes, this functionality is currently hidden in

unicode_aswidechar(PyUnicodeObject *unicode,
                   wchar_t *w,
                   Py_ssize_t size):

/* Helper function for PyUnicode_AsWideChar() and
PyUnicode_AsWideCharString():
   convert a Unicode object to a wide character string.

   - If w is NULL: return the number of wide characters (including the
nul
     character) required to convert the unicode object. Ignore size argument.
.. */

and I believe is reimplemented in a few other places.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 01:31:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Nov 2010 00:31:44 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290817904.88.0.305865078977.issue9264@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Divided command-line options logically into sub-sections and improved
> their explanations

Using the program/cmdoption combo may be a good idea here.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sat Nov 27 01:45:16 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 27 Nov 2010 00:45:16 +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: <1290818716.17.0.349711155502.issue10542@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'd need access to this without having to build a PyUnicodeObject, for efficiency. But it sounds like it does have the basic functionality I need.

For my use I'd really need it to take the result of Py_UNICODE_NEXT. Something like:
Py_ssize_t
Py_UNICODE_NUM_NEEDED(Py_UCS4 c)
and it would always return 1 or 2. Always 1 for a wide build, and for a narrow build 1 if c is in the BMP else 2. Choose a better name, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 02:02:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Nov 2010 01:02:34 +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: <1290819754.86.0.675283811319.issue10299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Possible groups:

Types constructors: bool, bytearray, bytes, complex, dict, float, frozenset, int, list, memoryview, object, range, set, slice, str, tuple

Mathematical functions: abs, bin, divmod, hex, oct, pow, round

Working with sequences: all, any, enumerate, filter, iter, len, map, max, min, reversed, sorted, sum, zip

Working with strings: chr, format, ord

I/O: input, open, print

Introspection/metaprogramming: ascii, delattr, dir, getattr, globals, hasattr, help, id, isinstance, issubclass, locals, repr, setattr, type, vars

Advanced functions: classmethod, compile, eval, exec, hash, next, property, staticmethod, super, __import__

The last two are debatable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10299>
_______________________________________

From report at bugs.python.org  Sat Nov 27 02:14:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 01:14:16 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290818716.17.0.349711155502.issue10542@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=UoYFp4jCBCR9MZ8K16sRH=CwUyt7HncPspSe_@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 26, 2010 at 7:45 PM, Eric Smith <report at bugs.python.org> wrote:
..
> For my use I'd really need it to take the result of Py_UNICODE_NEXT. Something like:
> Py_ssize_t
> Py_UNICODE_NUM_NEEDED(Py_UCS4 c)
> and it would always return 1 or 2. Always 1 for a wide build, and for a narrow
> build 1 if c is in the BMP else 2. Choose a better name, of course.

Can you describe your use case in more detail?  Would
Py_UNICODE_PUT_NEXT() combined with
Py_UNICODE_CODEPOINT_COUNT(Py_UNICODE *begin, Py_UNICODE *end) solve it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 02:30:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Nov 2010 01:30:28 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1290821428.26.0.265688241854.issue10541@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Sat Nov 27 02:41:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 27 Nov 2010 01:41: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: <1290822064.34.0.077074392707.issue10542@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I don't like macro having a result and using multiple instructions using the evil magic trick (the ","). It's harder to maintain the code and harder to debug than a classical function.

Don't you think that modern compilers are able to inline the code? (If not, we may add the right C attribute/keyword)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 02:41:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Nov 2010 01:41:22 +0000
Subject: [issue10507] Check well-formedness of reST markup within "make
	patchcheck"
In-Reply-To: <1290443371.49.0.836951290391.issue10507@psf.upfronthosting.co.za>
Message-ID: <1290822082.1.0.513598788601.issue10507@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Have a look at Doc/tools/rstlint.py

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10507>
_______________________________________

From report at bugs.python.org  Sat Nov 27 02:56:00 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 27 Nov 2010 01:56:00 +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: <1290822960.84.0.557643719497.issue10542@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The code will basically be:

  Py_UCS4 fill;

  parse_format_string(fmt, ..., &fill, ...);

  /* lots more code */

  if (fill_needed) {
    /* compute how many characters to reserve */
    space_needed = Py_UNICODE_NUM_NEEDED(fill) *
                      number_of_characters_to_fill;
  }

It would be most convenient (and require the fewest changes) if the computation could just use fill, instead of remembering the pointers to the beginning and end of fill.

Py_UNICODE_CODEPOINT_COUNT could be implemented with a primitive that does what I want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 02:57:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 01:57:16 +0000
Subject: [issue9200] str.isprintable() is always False for large code points
In-Reply-To: <1278597003.49.0.847714220976.issue9200@psf.upfronthosting.co.za>
Message-ID: <1290823036.21.0.939516373206.issue9200@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch fixes isprintable and other ctype-like methods.  I left isspace() out for now because I could not find a test character outside of BMP to test with, but I think we should fix that for completeness as well.

At this point the goal is mostly to showcase Py_UNICODE_NEXT(), not completeness.  See issue10542.

I also noticed that upper/lower/swapcase methods have the same issue:

>>> '\N{MATHEMATICAL BOLD CAPITAL A}'.lower() == '\N{MATHEMATICAL BOLD CAPITAL A}'
True

This will be a subject of a separate issue.

----------
Added file: http://bugs.python.org/file19831/issue9200.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9200>
_______________________________________

From report at bugs.python.org  Sat Nov 27 03:05:08 2010
From: report at bugs.python.org (Blair)
Date: Sat, 27 Nov 2010 02:05:08 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <AANLkTimugQcJg5RJAWESjRfDMZTUv6G=TGYHzsQzuvbu@mail.gmail.com>


Blair <bidihall at gmail.com> added the comment:

I'd like to add a few more observations to the mix.

I have run the following in both 2.6.6 and in 2.7

class xfloat(float):
    def __new__(cls,x):
        return float.__new__(cls,x)

    def __radd__(self,lhs):
        print "__radd__ got: %s" % type(lhs)
        if isinstance(lhs,(int,float)):
            return xfloat( float(self) + lhs )
        else:
            return NotImplemented

xf = xfloat(9.0)

cases = dict(int=1,float=1.0,complex=1.0+1j)
for k,v in cases.items():
    y = v + xf
    print "%s + xfloat" % k
    print type(y)
    print y

In 2.7 this gives:

__radd__ got: <type 'int'>
int + xfloat
<class '__main__.xfloat'>
10.0
__radd__ got: <type 'float'>
float + xfloat
<class '__main__.xfloat'>
10.0
complex + xfloat
<type 'complex'>
(10+1j)

In 2.6.6 I get:

__radd__ got: <type 'int'>
int + xfloat
<class '__main__.xfloat'>
10.0
__radd__ got: <type 'float'>
float + xfloat
<class '__main__.xfloat'>
10.0
__radd__ got: <type 'complex'>
complex + xfloat
<type 'complex'>
(10+1j)

They are the same except for the last case.

My feeling is that the behaviour of 2.6.6 (for subclassing float) is
correct.

The behaviour of 2.6.6 is needed to enable you to implement the commutative
property of addition (ie, you expect to get the same outcome from x+y or
y+x), which I would say is a pretty fundamental requirement.

I have also tried the following

class xint(int):
    def __new__(cls,x):
        return int.__new__(cls,x)

    def __radd__(self,lhs):
        print "__radd__ got: %s" % type(lhs)
        if isinstance(lhs,(int,)):
            return xint( float(self) + lhs )
        else:
            return NotImplemented

print
print "-------------------"
xf = xint(9)

cases = dict(int=1,float=1.0,complex=1.0+1j)
for k,v in cases.items():
    y = v + xf
    print "%s + xint" % k
    print type(y)
    print y

In 2.6.6 I get

__radd__ got: <type 'int'>
int + xint
<class '__main__.xint'>
10
float + xint
<type 'float'>
10.0
__radd__ got: <type 'complex'>
complex + xint
<type 'complex'>
(10+1j)

and in 2.7

-------------------
__radd__ got: <type 'int'>
int + xint
<class '__main__.xint'>
10
float + xint
<type 'float'>
10.0
complex + xint
<type 'complex'>
(10+1j)

In my opinion, 2.6.6 was faulty in the float + xint case, for the same
reasons as above, and 2.7 is faulty in both float + xint and complex + xint.

----------
Added file: http://bugs.python.org/file19832/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
-------------- next part --------------
I&#39;d like to add a few more observations to the mix.<br><br>I have run the following in both 2.6.6 and in 2.7<br><br>class xfloat(float):<br>?????? def __new__(cls,x):<br>?????????????? return float.__new__(cls,x)<br><br>?????? def __radd__(self,lhs):<br>
?????????????? print &quot;__radd__ got: %s&quot; % type(lhs)<br>?????????????? if isinstance(lhs,(int,float)):<br>?????????????????????? return xfloat( float(self) + lhs )<br>?????????????? else:<br>?????????????????????? return NotImplemented<br><br><br>xf = xfloat(9.0)<br>
<br>cases = dict(int=1,float=1.0,complex=1.0+1j)<br>for k,v in cases.items():<br>?????? y = v + xf<br>?????? print &quot;%s + xfloat&quot; % k<br>?????? print type(y)<br>?????? print y<br><br>In 2.7 this gives:<br><br>__radd__ got: &lt;type &#39;int&#39;&gt;<br>
int + xfloat<br>&lt;class &#39;__main__.xfloat&#39;&gt;<br>10.0<br>__radd__ got: &lt;type &#39;float&#39;&gt;<br>float + xfloat<br>&lt;class &#39;__main__.xfloat&#39;&gt;<br>10.0<br>complex + xfloat<br>&lt;type &#39;complex&#39;&gt;<br>
(10+1j)<br><br>In 2.6.6 I get:<br><br>__radd__ got: &lt;type &#39;int&#39;&gt;<br>int + xfloat<br>&lt;class &#39;__main__.xfloat&#39;&gt;<br>10.0<br>__radd__ got: &lt;type &#39;float&#39;&gt;<br>float + xfloat<br>&lt;class &#39;__main__.xfloat&#39;&gt;<br>
10.0<br>__radd__ got: &lt;type &#39;complex&#39;&gt;<br>complex + xfloat<br>&lt;type &#39;complex&#39;&gt;<br>(10+1j)<br><br>They are the same except for the last case.<br><br>My feeling is that the behaviour of 2.6.6 (for subclassing float) is correct.<br>
<br>The behaviour of 2.6.6 is needed to enable you to implement the commutative property of addition (ie, you expect to get the same outcome from x+y or y+x), which I would say is a pretty fundamental requirement.<br><br>
I have also tried the following<br><br>class xint(int):<br>?????? def __new__(cls,x):<br>?????????????? return int.__new__(cls,x)?????????????? <br><br>?????? def __radd__(self,lhs):<br>?????????????? print &quot;__radd__ got: %s&quot; % type(lhs)<br>
?????????????? if isinstance(lhs,(int,)):<br>?????????????????????? return xint( float(self) + lhs )<br>?????????????? else:<br>?????????????????????? return NotImplemented<br><br>print<br>print &quot;-------------------&quot;<br>xf = xint(9)<br><br>cases = dict(int=1,float=1.0,complex=1.0+1j)<br>
for k,v in cases.items():<br>?????? y = v + xf<br>?????? print &quot;%s + xint&quot; % k<br>?????? print type(y)<br>?????? print y<br>?????? <br>In 2.6.6 I get<br><br>__radd__ got: &lt;type &#39;int&#39;&gt;<br>int + xint<br>&lt;class &#39;__main__.xint&#39;&gt;<br>
10<br>float + xint<br>&lt;type &#39;float&#39;&gt;<br>10.0<br>__radd__ got: &lt;type &#39;complex&#39;&gt;<br>complex + xint<br>&lt;type &#39;complex&#39;&gt;<br>(10+1j)<br><br>and in 2.7<br><br>-------------------<br>__radd__ got: &lt;type &#39;int&#39;&gt;<br>
int + xint<br>&lt;class &#39;__main__.xint&#39;&gt;<br>10<br>float + xint<br>&lt;type &#39;float&#39;&gt;<br>10.0<br>complex + xint<br>&lt;type &#39;complex&#39;&gt;<br>(10+1j)<br><br>In my opinion, 2.6.6 was faulty in the float + xint case, for the same reasons as above, and 2.7 is faulty in both float + xint and complex + xint.<br>
<br>

From report at bugs.python.org  Sat Nov 27 03:20:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 02:20:45 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290822064.34.0.077074392707.issue10542@psf.upfronthosting.co.za>
Message-ID: <AANLkTinuDRo6iEM9V0KjZ8Hg4sMR1u-2+G3kzuoZkbK7@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 26, 2010 at 8:41 PM, STINNER Victor <report at bugs.python.org> wrote:
..
> I don't like macro having a result and using multiple instructions using the evil
> magic trick (the ","). It's harder to maintain the code and harder to debug than
> a classical function.
>

You are preaching to the choir.  In fact, my first version
(issue10521-unicode-next.diff attached to  issue10521) used a
function.   I would not worry about implementation at this point,
though.  Let's find the best abstraction first.

> Don't you think that modern compilers are able to inline the code?
> (If not, we may add the right C attribute/keyword)

Not in C.  In C++, I could use a reference to the pointer incremented
by the macro, but in C, I have to use an address.  Once you take an
address of a variable, the compiler will refuse to put it in a
register.  So no, I don't think we can write an ANSI C function that
will be as efficient as the macro.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 03:22:47 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 27 Nov 2010 02:22: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: <1290824567.37.0.944451066017.issue10542@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The compiler's decision to inline something should not be related to its ability to put variables in a register.

But I definitely agree that we should get the abstraction right first and worry about the implementation later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 03:52:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 02:52:56 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290824567.37.0.944451066017.issue10542@psf.upfronthosting.co.za>
Message-ID: <AANLkTikW01z=Z+oOx9yp5D79YS_Uq18ZZ6R7pRXVWnHw@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 26, 2010 at 9:22 PM, Eric Smith <report at bugs.python.org> wrote:
..
> But I definitely agree that we should get the abstraction right first and worry about
> the implementation later.

I am fairly happy with Py_UNICODE_NEXT() abstraction.  It's semantics
should be natural for users familiar with python iterators and the
fact that it expands to simply *ptr++ on wide builds makes it easy to
explain its usage.   I am note very happy about the end argument for
the following reasons:

1. Builtin "next()" takes the default value as a second argument.
Extension writers may expect the same from Py_UNICODE_NEXT().  The
name "end" should be self-explainatory though, especially to those
with an exposure to STL.

2. If  Py_UNICODE_NEXT() stays as a macro, an innocent looking
Py_UNICODE_NEXT(p, p + size) will have a hard to detect bug.  Can be
fixed by making Py_UNICODE_NEXT() a function.

I wonder whether it is best to prefix the new macros with an
underscore.  On one hand, we want to make this available to extension
writers, on the other hand, once more people start dealing with
non-BMP issues, a better abstraction may be found and we man not want
to maintain  Py_UNICODE_NEXT()  indefinitely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 04:16:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 03:16:27 +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: <1290827787.52.0.523345966011.issue10542@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Raymond,

I wonder if you would like to comment on the iterator analogy and/or on adding public names to C API.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 06:51:01 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 27 Nov 2010 05:51:01 +0000
Subject: [issue8600] test_gdb failures
In-Reply-To: <1272852025.2.0.622667060005.issue8600@psf.upfronthosting.co.za>
Message-ID: <1290837061.42.0.866999741828.issue8600@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8600>
_______________________________________

From report at bugs.python.org  Sat Nov 27 07:36:19 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 27 Nov 2010 06:36:19 +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: <1290839779.67.0.132815815209.issue10542@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Mark, can you opine on this?

----------
assignee: belopolsky -> lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 08:38:17 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sat, 27 Nov 2010 07:38:17 +0000
Subject: [issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you
	paste something.
In-Reply-To: <1290814926.25.0.959981275234.issue10537@psf.upfronthosting.co.za>
Message-ID: <D711818F-8529-4158-A982-6A12DD4E4B3E@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 27 Nov, 2010, at 0:42, Terry J. Reedy wrote:

> 
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
> 
> Is this a duplicate of other issues (close?)?

I don't know yet.

> Is this an Apple problem beyond our control (close?)?

This might be fixable. There is a patch that improves AquaTk 8.5 support which I need to integrate/test.

Ronald

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10537>
_______________________________________

From report at bugs.python.org  Sat Nov 27 08:43:30 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 27 Nov 2010 07:43:30 +0000
Subject: [issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you
	paste something.
In-Reply-To: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>
Message-ID: <1290843810.73.0.319431637745.issue10537@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Ronald, which patch are you thinking of?  Issue6075?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10537>
_______________________________________

From report at bugs.python.org  Sat Nov 27 09:14:43 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 08:14:43 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290845683.88.0.90432647598.issue10516@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
nosy: +eli.bendersky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Nov 27 09:16:14 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Nov 2010 08:16:14 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290845774.23.0.450802749835.issue10521@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I agree that s.center(char, n).encode('utf-8') should be the same on both the builds -- even if their len() will be different -- for the following reasons:

1) the string will eventually be encoded, and if they the result is the same on both builds, it will look the same too;
2) trying to keep the same len() will generate different results and it won't work in case of odd width like 'foo'.center(surrogate_pair, 5) because you can't put half surrogate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Sat Nov 27 09:33:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 08:33:13 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1290846793.34.0.310208852303.issue10541@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Apparently something in the test changes the cwd.

Both of the following invocations work:

$ ./python.exe `pwd`/Lib/test/regrtest.py -T -N test_urllib
$ ./python.exe -m test.regrtest -T -N test_urllib

I would suggest changing the coverage target in the Makefile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Sat Nov 27 09:37:26 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 08:37:26 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290847046.56.0.561311287912.issue9264@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric, good idea - I'll do it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sat Nov 27 09:52:48 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 08:52:48 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290847968.46.0.913525833929.issue9264@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

There's something weird going on with cmdoption... I've applied for subscription to the docs mailing list, but while I'm awaiting moderator approval, here's the brain-dump. Suppose this option description:

.. program:: trace

.. cmdoption:: -c, --count

   Blah blah blah

And now this reference:

This is a test long :option:`--count` and then short :option:`-c`, test.

Only the -c gets linked to ..cmdoption, not --count.
If I list --count before -c in ..cmdoption, then it's the other way around. What makes it kinda work (link both the long and short names) is:

.. cmdoption:: -c
               --count

   Blah blah blah

But this isn't standard (although it doesn't look too bad). Actually, the original listing (the short name first, then the long one) is customary in the library docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sat Nov 27 10:34:41 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 27 Nov 2010 09:34:41 +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: <1290850481.88.0.248246658172.issue10242@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Applied in r86828.

The output could still be made nicer, perhaps something along the lines of:

expected 6, got 4: 'wand of fireballs'
expected 2, got 7: 'ring of invisibility'
  . . .

----------
priority: high -> normal
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10242>
_______________________________________

From report at bugs.python.org  Sat Nov 27 10:41:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 27 Nov 2010 09:41: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: <1290850908.12.0.53177706876.issue10544@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Hmm, what an interesting and unexpected side-effect of the efforts to hide the loop induction variable.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Sat Nov 27 11:09:03 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 10:09:03 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290852543.2.0.914201704126.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Objects/listobject.c has a static function named list_clear used internally. Is it possible to just expose this function as a clear() method? 

One problem is that it has this strange comment in the end:

    /* Never fails; the return value can be ignored.
       Note that there is no guarantee that the list is actually empty
       at this point, because XDECREF may have populated it again! */

However, looking at the code I'm not sure the list can be cleared any more than the function does, and it actually deallocates the ob_item field of the list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Nov 27 11:13:40 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 27 Nov 2010 10:13:40 +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: <1290852820.32.0.480066952572.issue10242@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Attaching possible code for nicer output.

----------
assignee: rhettinger -> michael.foord
resolution: fixed -> 
Added file: http://bugs.python.org/file19833/nice_output.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10242>
_______________________________________

From report at bugs.python.org  Sat Nov 27 11:20:26 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sat, 27 Nov 2010 10:20:26 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290853226.41.0.136666577598.issue10516@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Hi, I'm also looking at listobject.c also... if we want list.clear() to behave exactly like del list[], we may be able to just call list_ass_slice on the list. Similarly for list.copy which should behave like a=l[:]

----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Nov 27 11:37:45 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 10:37:45 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290853226.41.0.136666577598.issue10516@psf.upfronthosting.co.za>
Message-ID: <AANLkTimiD08yP4iN-GAsoJ8k6H1t6=UM6RHHnkHHO0e6@mail.gmail.com>


Eli Bendersky <eliben at gmail.com> added the comment:

>
> Hi, I'm also looking at listobject.c also... if we want list.clear() to
> behave exactly like del list[], we may be able to just call list_ass_slice
> on the list. Similarly for list.copy which should behave like a=l[:]
>

Note that when executed to do 'del lst[:]' (i.e. with argument v set to 0
and ilow/ihigh to the maximal range of the list), list_ass_slice will just
call list_clear anyway, which is a cue that this indeed is the right way to
do it, despite the strange comment I mentioned in my message above.

----------
Added file: http://bugs.python.org/file19834/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________
-------------- next part --------------
<div dir="ltr"><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Hi, I&#39;m also looking at listobject.c also... if we want list.clear() to behave exactly like del list[], we may be able to just call list_ass_slice on the list. Similarly for list.copy which should behave like a=l[:]<br>

</blockquote></div><br>Note that when executed to do &#39;del lst[:]&#39; (i.e. with argument v set to 0 and ilow/ihigh to the maximal range of the list), list_ass_slice will just call list_clear anyway, which is a cue that this indeed is the right way to do it, despite the strange comment I mentioned in my message above.<br>

<br></div>

From report at bugs.python.org  Sat Nov 27 11:58:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 27 Nov 2010 10:58:34 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290855514.84.0.186940913551.issue10516@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, list_clear should be called, but no, it cannot be used directly because a method needs a PyObject* return value.  So a wrapper method is needed that looks like listappend() does for list.append(). list_copy() will just look like list_slice() with the index fiddling removed.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Nov 27 12:11:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 27 Nov 2010 11:11:56 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290839779.67.0.132815815209.issue10542@psf.upfronthosting.co.za>
Message-ID: <4CF0E77A.9050808@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:
> 
> Mark, can you opine on this?

Yes, I'll have a look later today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 12:56:59 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Nov 2010 11:56:59 +0000
Subject: [issue10383] test_os leaks under Windows
In-Reply-To: <1289421086.3.0.902677944517.issue10383@psf.upfronthosting.co.za>
Message-ID: <1290859019.9.0.47315442208.issue10383@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Fixed original leaks in r86804, r86806 and r86804.

Fixed additional leaks in r86829.

----------
components: +Extension Modules -Library (Lib), Windows
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10383>
_______________________________________

From report at bugs.python.org  Sat Nov 27 13:16:35 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sat, 27 Nov 2010 12:16:35 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290860195.3.0.476661818973.issue10516@psf.upfronthosting.co.za>


Xuanji Li <xuanji 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.

eli: are you writing a patch for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Nov 27 13:38:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Nov 2010 12:38:02 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290861482.51.0.171259102889.issue9264@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I noticed too that the second form given in a cmdoption directive cannot be linked to from an option construct.  The workaround looks like this: :option:`--long <-l>`.  This uses a generic Sphinx (or reST) property: When using :role:`text <thing>`, ?thing? will be given as argument to the role but ?text? will be displayed.  It?s very useful for references for example, if you don?t want title case in the middle of your sentence of if you need to rephrase the title: ?Have a look at the :ref:`detailed explanation <config-explanation>`?.

Even if it can be worked around, can you report this Sphinx bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sat Nov 27 14:16:08 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 13:16:08 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290863768.56.0.609206649176.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Georg,

Thanks. Of course it should be wrapped like the others :-)

Xuanji,

Yes, I will try to get in something preliminary today.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Nov 27 14:20:20 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 13:20:20 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290864020.64.0.559887385035.issue9264@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

?ric,

I sent an inquiry about this problem to the docs at python.org list. In the meantime, I will implement it with the workaround you suggest (I checked it works in this case too).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sat Nov 27 14:29:20 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 13:29:20 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290864560.44.0.354643131613.issue10516@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching a patch for list.clear():

1. Implements a new function in Objects/listobject.c named listclear() (to be consistent with the other "method functions")
2. listclear() is registered in list_methods and just calls list_clear(), returning None
3. A documentation string is modeled after dict.clear(), but shaped a bit differently to follow the conventions of other list method docs.

If this look fine to the more experienced devs, things left to do are:

1. Add tests
2. Implement the .copy() method in a similar manner + tests for it

Some random observations:

1. The naming of functions/methods could be made more consistent. See, for example, list_reversed vs. listreverse.
2. The documentation style of list and dict methods is different for no apparent reason:

help({}.pop) gives:

pop(...)
    D.pop(k[,d]) -> v, remove specified key and return the corresponding value.
    If key is not found, d is returned if given, otherwise KeyError is raised

While help([].pop) gives:

pop(...)
    L.pop([index]) -> item -- remove and return item at index (default last).
    Raises IndexError if list is empty or index is out of range.

Note the '--' which separates the signature from description in the list version.

----------
keywords: +patch
Added 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 Nov 27 14:30:12 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 13:30:12 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290864612.19.0.94717914143.issue10516@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


Removed file: http://bugs.python.org/file19834/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Nov 27 14:47:51 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Nov 2010 13:47:51 +0000
Subject: [issue10547] FreeBSD: wrong value for LDSHARED in sysconfig
In-Reply-To: <1290865671.36.0.14618274941.issue10547@psf.upfronthosting.co.za>
Message-ID: <1290865671.36.0.14618274941.issue10547@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

On FreeBSD, the config variable LDSHARED contains the literal '${LDFLAGS}',
causing this failure in test_distutils:


'test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) ... gcc: ': No such file or directory
ERROR


The patch fixes the issue and all tests pass.


Benjamin, are you ok with the change for 2.7? I'm not sure why autoreconf
generated a bit of extra noise; I used version 2.65. Also, OpenBSD and
NetBSD should be affected as well.

----------
components: Build
files: freebsd_ldshared.patch
keywords: needs review, patch
messages: 122525
nosy: benjamin.peterson, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: FreeBSD: wrong value for LDSHARED in sysconfig
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19836/freebsd_ldshared.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10547>
_______________________________________

From report at bugs.python.org  Sat Nov 27 14:48:31 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Nov 2010 13:48:31 +0000
Subject: [issue10547] FreeBSD: wrong value for LDSHARED in sysconfig
In-Reply-To: <1290865671.36.0.14618274941.issue10547@psf.upfronthosting.co.za>
Message-ID: <1290865711.05.0.100727786727.issue10547@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
keywords: +buildbot -needs review, patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10547>
_______________________________________

From report at bugs.python.org  Sat Nov 27 15:25:56 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 14:25:56 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290867956.08.0.0682931390603.issue9264@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching an updated patch for Doc/library/trace.rst in 3.2

Changed the formatting of command-line options per ?ric's suggestion of using program/cmdoption/option combos (great idea ?ric - it looks much better).

----------
Added file: http://bugs.python.org/file19837/issue9264.py32.2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sat Nov 27 15:46:44 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 27 Nov 2010 14:46:44 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290869204.69.0.430285372206.issue9509@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Tried to comment in Rietveld but it didn't work for some reason. Anyway, I think the argparse.py patch isn't good - changing the type error message to "'invalid %s value: %r details: "%s"'" will change the behavior of a bunch of programs, and it's not clearly for the better. Instead, you should raise an ArgumentTypeError instead of a ValueError, and give it whatever message you want there. That is, let's keep this patch local to the FileType, and not touch the rest of argparse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sat Nov 27 15:52:33 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 27 Nov 2010 14:52:33 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290869553.53.0.821954146009.issue9509@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

Steven, I'm not sure why you're insisting on ArgumentTypeError, when it should be ArgumentError. The file name is not coerced into a different file type, but rather the error occurs when trying to use parameter passed.

In any way, my patch is still available. Do you not like something about it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sat Nov 27 16:07:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Nov 2010 15:07:39 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290870459.98.0.677793700466.issue9264@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for your work on this!

``dir/package/module.cover`` ? :file:`{dir}/{package}/{module}.cover`

'``>>>>>>``' looks wrong.

``os.pathsep``: You can use :data:`os.pathsep` to get a link, I think.

+.. method:: CoverageResults.update(other)
FTR, there is a new way for doing such things: You can nest method directives in a class directive block.  See gettext.rst for an example.  Your patch needn?t change that now, not all docs have been updated, so it?s best to do as you did and follow the style of the rest of the file.  I propose to change it after your patch is committed.

+..
Stray dots at the end of the file.

The doc uses one or two spaces inconsistently.  I don?t know if it?s worth changing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sat Nov 27 16:16:38 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 27 Nov 2010 15:16:38 +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: <1290870998.37.0.268172055445.issue10548@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Reported by Konrad Delong.

class MyTest(unittest.TestCase):
    def setUp(self):
        raise Exception
    @unittest.expectedFailure
    def testSomething(self):
        assert False, "test method failed"




This code will report error, not expected failure.

----------
assignee: michael.foord
components: Library (Lib)
messages: 122530
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Error in setUp not reported as expectedFailure (unittest)
type: behavior
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10548>
_______________________________________

From report at bugs.python.org  Sat Nov 27 16:17:33 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 15:17:33 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290871053.19.0.896032033724.issue9264@psf.upfronthosting.co.za>


Eli Bendersky <eliben at gmail.com> added the comment:

Attaching an updated patch following ?ric's suggestions:

* ``dir/package/module.cover`` -- FIXED

* '``>>>>>>``' looks wrong -- FIXED to just ``>>>>>>``

* ``os.pathsep`` -- FIXED

* method:: CoverageResults.update(other) -- OK, let's leave it for a separate issue.

* Stray dots at the end of the file -- FIXED 

* The doc uses one or two spaces inconsistently.  -- not 100% what you mean here, but I found inconsistent separation between paragraphs (sometimes 1 blank line, sometimes 2), and fixed it. If you meant something else, I can fix that too :)

----------
Added file: http://bugs.python.org/file19838/issue9264.py32.3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sat Nov 27 16:21:22 2010
From: report at bugs.python.org (Eli Bendersky)
Date: Sat, 27 Nov 2010 15:21:22 +0000
Subject: [issue10516] Add list.clear() and list.copy()
In-Reply-To: <1290555468.47.0.0329661397161.issue10516@psf.upfronthosting.co.za>
Message-ID: <1290871282.46.0.0942068202034.issue10516@psf.upfronthosting.co.za>


Changes by Eli Bendersky <eliben at gmail.com>:


----------
Removed message: http://bugs.python.org/msg122522

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10516>
_______________________________________

From report at bugs.python.org  Sat Nov 27 17:01:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Nov 2010 16:01:07 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290873667.52.0.0514580944988.issue9264@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Duh, I forgot some words: The file uses one or two dots *after full stops* inconsistently.  I don?t think you have to change that now, we can make it consistent later (or not, as it does not affect the output), as we do with line wrapping.  Just keep it in mind for future patches :)

Terry: I got no warnings when building the HTML and the output looks good.  +1 on commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sat Nov 27 17:09:43 2010
From: report at bugs.python.org (Joe Metcalfe)
Date: Sat, 27 Nov 2010 16:09:43 +0000
Subject: [issue10531] write tilted text in turtle
In-Reply-To: <1290702974.67.0.695196946667.issue10531@psf.upfronthosting.co.za>
Message-ID: <1290874183.51.0.0922128163789.issue10531@psf.upfronthosting.co.za>


Joe Metcalfe <j.g.metcalfe at gmail.com> added the comment:

Turtle is built on top of Tk, which is currently at version 8.5 - this has no ability to rotate text. When Tk version 8.6 arrives it should be able to write rotated text (see http://mail.python.org/pipermail/tkinter-discuss/2010-November/002490.html) and turtle.py could be updated to take advantage of it.

----------
nosy: +Joe.Metcalfe

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10531>
_______________________________________

From report at bugs.python.org  Sat Nov 27 17:10:19 2010
From: report at bugs.python.org (Joe Metcalfe)
Date: Sat, 27 Nov 2010 16:10:19 +0000
Subject: [issue10531] write tilted text in turtle
In-Reply-To: <1290702974.67.0.695196946667.issue10531@psf.upfronthosting.co.za>
Message-ID: <1290874219.55.0.0568665390172.issue10531@psf.upfronthosting.co.za>


Changes by Joe Metcalfe <j.g.metcalfe at gmail.com>:


----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10531>
_______________________________________

From report at bugs.python.org  Sat Nov 27 17:19:19 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sat, 27 Nov 2010 16:19:19 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1290874759.78.0.773975660842.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Some references to keep around:

http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/
http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/Python26-07-dtrace.diff
http://src.opensolaris.org/source/xref/jds/spec-files/trunk/patches/Python-07-dtrace.diff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Sat Nov 27 17:37:52 2010
From: report at bugs.python.org (Milko Krachounov)
Date: Sat, 27 Nov 2010 16:37:52 +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: <1290875872.01.0.0960712603698.issue10549@psf.upfronthosting.co.za>


New submission from Milko Krachounov <python at milko.3mhz.net>:

If I make a class B, and add staticmethod(A) as an attribute when B is another class, help(B) breaks. The issue appears with Python 2.6.6, trunk, 3.1.3c1, and py3k SVN.

Python 2.7 (trunk:86836, Nov 27 2010, 18:23:07) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object):
...     pass
... 
>>> class B(object):
...     attr = staticmethod(A)
... 
>>> help(B)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/milko/?????/Python/trunk/Lib/site.py", line 453, in __call__
    return pydoc.help(*args, **kwds)
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1720, in __call__
    self.help(request)
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1767, in help
    else: doc(request, 'Help on %s:')
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1508, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1503, in render_doc
    return title % desc + '\n\n' + text.document(object, name)
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 327, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1216, in docclass
    lambda t: t[1] == 'static method')
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 1162, in spill
    name, mod, object))
  File "/home/milko/?????/Python/trunk/Lib/pydoc.py", line 327, in document
    if inspect.isclass(object): return self.docclass(*args)
TypeError: docclass() takes at most 4 arguments (5 given)

Python 3.2a4+ (py3k:86836, Nov 27 2010, 18:35:01) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A:
...     pass
... 
>>> class B:
...     attr = staticmethod(A)
... 
>>> help(B)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/milko/?????/Python/py3k/Lib/site.py", line 447, in __call__
    return pydoc.help(*args, **kwds)
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1713, in __call__
    self.help(request)
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1760, in help
    else: doc(request, 'Help on %s:')
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1504, in doc
    pager(render_doc(thing, title, forceload))
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1499, in render_doc
    return title % desc + '\n\n' + text.document(object, name)
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 319, in document
    if inspect.isclass(object): return self.docclass(*args)
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1214, in docclass
    lambda t: t[1] == 'static method')
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 1159, in spill
    name, mod, object))
  File "/home/milko/?????/Python/py3k/Lib/pydoc.py", line 319, in document
    if inspect.isclass(object): return self.docclass(*args)
TypeError: docclass() takes at most 4 positional arguments (5 given)

----------
components: Library (Lib)
messages: 122535
nosy: milko.krachounov
priority: normal
severity: normal
status: open
title: help(cls1) breaks when cls1 has staticmethod(cls2) attribute
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10549>
_______________________________________

From report at bugs.python.org  Sat Nov 27 19:11:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 18:11:22 +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: <1290881482.81.0.00469538215457.issue10549@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Confirmed in py3k.

----------
assignee:  -> belopolsky
nosy: +belopolsky
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10549>
_______________________________________

From report at bugs.python.org  Sat Nov 27 19:24:46 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 27 Nov 2010 18:24:46 +0000
Subject: [issue10499] Modular interpolation in configparser
In-Reply-To: <1290395793.65.0.355106669717.issue10499@psf.upfronthosting.co.za>
Message-ID: <1290882286.26.0.750440500545.issue10499@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Patch reposted here for review: http://codereview.appspot.com/3309043/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10499>
_______________________________________

From report at bugs.python.org  Sat Nov 27 19:27:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 18:27:49 +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: <1290882469.79.0.575804897333.issue10549@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The fix is simple:


--- Lib/pydoc.py	(revision 86824)
+++ Lib/pydoc.py	(working copy)
@@ -1110,7 +1110,7 @@
         result = result + self.section('FILE', file)
         return result
 
-    def docclass(self, object, name=None, mod=None):
+    def docclass(self, object, name=None, mod=None, *ignored):
         """Produce text documentation for a given class object."""
         realname = object.__name__
         name = name or realname

I think this is the right thing to do because HTMLDoc.docclass() has the following signature.


    def docclass(self, object, name=None, mod=None, funcs={}, classes={},
                 *ignored):

----------
stage: needs patch -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10549>
_______________________________________

From report at bugs.python.org  Sat Nov 27 19:29:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Nov 2010 18:29:15 +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: <1290882555.54.0.233230896564.issue10549@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, ncoghlan, ron_adam
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10549>
_______________________________________

From report at bugs.python.org  Sat Nov 27 19:40:27 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Nov 2010 18:40:27 +0000
Subject: [issue10550] Windows: leak in test_concurrent_futures
In-Reply-To: <1290883227.71.0.820732153232.issue10550@psf.upfronthosting.co.za>
Message-ID: <1290883227.71.0.820732153232.issue10550@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

C:\Users\stefan\svn\py3k_64>PCbuild\amd64\python_d.exe Lib\test\regrtest.py -R : test_concurrent_futures
[1/1] test_concurrent_futures
beginning 9 repetitions
123456789
.........
test_concurrent_futures leaked [6912, 6912, 6912, 6912] references, sum=27648
1 test failed:
    test_concurrent_futures
[195615 refs]

----------
components: Extension Modules
messages: 122539
nosy: skrah
priority: normal
severity: normal
status: open
title: Windows: leak in test_concurrent_futures
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10550>
_______________________________________

From report at bugs.python.org  Sat Nov 27 19:44:20 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Sat, 27 Nov 2010 18:44:20 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290883460.95.0.195753388516.issue10520@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

Roumen's patch fixes a regression where readline extension would fail to build on Mac OS X 10.6.5.

----------
nosy: +lukasz.langa
resolution: fixed -> 
stage:  -> commit review
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Sat Nov 27 19:47:40 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Nov 2010 18:47:40 +0000
Subject: [issue10550] Windows: leak in test_concurrent_futures
In-Reply-To: <1290883227.71.0.820732153232.issue10550@psf.upfronthosting.co.za>
Message-ID: <1290883660.14.0.318597735503.issue10550@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

posixmodule_listdir.patch fixes a leak in test_macpath. test_concurrent_futures still leaks.

----------
keywords: +patch
Added file: http://bugs.python.org/file19839/posixmodule_listdir.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10550>
_______________________________________

From report at bugs.python.org  Sat Nov 27 20:15:26 2010
From: report at bugs.python.org (Kovid Goyal)
Date: Sat, 27 Nov 2010 19:15:26 +0000
Subject: [issue10551] mimetypes reading from registry in windows completely
	broken
In-Reply-To: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>
Message-ID: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>


New submission from Kovid Goyal <kovid at kovidgoyal.net>:

Hi,

I am the primary developer of calibre (http:/calibre-ebook.com) and yesterday I released an upgrade of calibre based on python 2.7. Here is a small sampling of all the diverse errors that my users experienced, related to reading mimetypes from the registry:

1. Permission denied if running from non privileged account
Traceback (most recent call last):
File "site.py", line 103, in main
File "site.py", line 84, in run_entry_point
File "site-packages\calibre\__init__.py", line 31, in <module>
File "mimetypes.py", line 344, in add_type
File "mimetypes.py", line 355, in init
File "mimetypes.py", line 261, in read_windows_registry
WindowsError: [Error 5] Acceso denegado (Access not allowed)

The fix for this is to trap WindowsError and ignore it in mimetypes.py

2. Mishandling of encoding of registry entries

Traceback (most recent call last):      
  File "site.py", line 103, in main     
  File "site.py", line 84, in run_entry_point
  File "site-packages\calibre\__init__.py", line 31, in <module>                                                
  File "mimetypes.py", line 344, in add_type                                                                
  File "mimetypes.py", line 355, in init                                                                    
  File "mimetypes.py", line 260, in read_windows_registry                                                   
  File "mimetypes.py", line 250, in enum_types                                                              
UnicodeDecodeError: 'utf8' codec can't decode byte 0xe0 in position 0: invalid continuation byte

The fix for this is to change

except UnicodeEncodeError

to

except ValueError

3. python -c "import mimetypes; print mimetypes.guess_type('img.jpg')"
('image/pjpeg', None)

Where the output should have been

(image/jpeg', None)

The fix for this is to load the registry entries before the default entris defined in mimetypes.py


Of course, IMHO, the best possible fix is to simply remove the reading of mimetypes from the registry. But that is up to whoever maintains this module. 

Duplicate (less comprehensive) tickets ont his isuue in your traceker already are: 9291, 10490, 104314

If the maintainer of this module is unable to fix these issues, let me know and I will submit a patch, either removing _winreg or fixing the issues individually.

----------
components: Library (Lib)
messages: 122542
nosy: kovid
priority: normal
severity: normal
status: open
title: mimetypes reading from registry in windows completely broken
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10551>
_______________________________________

From report at bugs.python.org  Sat Nov 27 20:28:56 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Nov 2010 19:28:56 +0000
Subject: [issue10550] Windows: leak in test_concurrent_futures
In-Reply-To: <1290883227.71.0.820732153232.issue10550@psf.upfronthosting.co.za>
Message-ID: <1290886136.58.0.274044290789.issue10550@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10550>
_______________________________________

From report at bugs.python.org  Sat Nov 27 20:34:20 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 27 Nov 2010 19:34:20 +0000
Subject: [issue10551] mimetypes reading from registry in windows completely
	broken
In-Reply-To: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>
Message-ID: <1290886460.68.0.39075714844.issue10551@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The first issue you note appears to be a duplicate of Issue10162, a fix for which should be available in the 2.7.1 maintenance release.

The second issue appears to be a duplicate of Issue9291.  Since that issue is still open, I suggest any further discussion be pursued there.  You may want to add yourself to the nosy list of that issue.

----------
components: +Windows
nosy: +brian.curtin, ned.deily
resolution:  -> duplicate
status: open -> closed
superseder:  -> mimetypes initialization fails on Windows because of non-Latin characters in registry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10551>
_______________________________________

From report at bugs.python.org  Sat Nov 27 20:42:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 19:42:24 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1290886944.27.0.167524499732.issue10541@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

`make coverage` is fine, you just have to use the "-m test.regrtest" form when running the tests.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Sat Nov 27 20:45:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 19:45:55 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1290887155.62.0.20809755753.issue10541@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would like to investigate this some more.  In theory, regrtest should restore cwd before coverage results are written.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:03:31 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 27 Nov 2010 20:03:31 +0000
Subject: [issue10520] Build with --enable-shared fails
In-Reply-To: <1290607556.28.0.945451412885.issue10520@psf.upfronthosting.co.za>
Message-ID: <1290888211.34.0.448323737965.issue10520@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r86837

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10520>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:04:07 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 27 Nov 2010 20:04:07 +0000
Subject: [issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you
	paste something.
In-Reply-To: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>
Message-ID: <1290888247.13.0.387150524347.issue10537@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Regardless of the root cause, I really hate to see 2.7.1 go out with this unresolved.  As it stands, IDLE was broken in the 2.7 64-bit OS X installer for 2.7 and, as it stands, is still broken.  And whether it is an Apple Tk problem or not (which remains to be determined), there are workarounds that could be applied - like having a 32-bit-only IDLE built with Aqua Tk 8.4 as the 32-bit installers do.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10537>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:26:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Nov 2010 20:26:05 +0000
Subject: [issue10521] str methods don't accept non-BMP fillchar on a narrow
	Unicode build
In-Reply-To: <1290612325.35.0.372651063965.issue10521@psf.upfronthosting.co.za>
Message-ID: <1290889565.89.0.0268995306085.issue10521@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

After reading the additional messages here and on a similar issue Alexander opened after this, I seem the point of wanting to make the difference between the two types of builds as transparent as sensibly possible. From that viewpoint, rejection of composed chars is not as bad because both types of builds act the same.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:29:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 20:29:13 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za>
Message-ID: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

$ ../../python.exe gencodec.py MAPPINGS/VENDORS/MISC/ build/
converting APL-ISO-IR-68.TXT to build/apl_iso_ir_68.py and build/apl_iso_ir_68.mapping
converting ATARIST.TXT to build/atarist.py and build/atarist.mapping
converting CP1006.TXT to build/cp1006.py and build/cp1006.mapping
converting CP424.TXT to build/cp424.py and build/cp424.mapping
Traceback (most recent call last):
  File "gencodec.py", line 421, in <module>
    convertdir(*sys.argv[1:])
  File "gencodec.py", line 391, in convertdir
    pymap(mappathname, map, dirprefix + codefile,name,comments)
  File "gencodec.py", line 355, in pymap
    code = codegen(name,map,encodingname,comments)
  File "gencodec.py", line 268, in codegen
    precisions=(4, 2))
  File "gencodec.py", line 152, in python_mapdef_code
    mappings = sorted(map.items())
TypeError: unorderable types: NoneType() < int()

It does appear to have been updated for 3.x:

$ python2.7 gencodec.py MAPPINGS/VENDORS/MISC/ build/
Traceback (most recent call last):
  File "gencodec.py", line 35, in <module>
    UNI_UNDEFINED = chr(0xFFFE)
ValueError: chr() arg not in range(256)

----------
components: Demos and Tools
messages: 122549
nosy: belopolsky, lemburg
priority: normal
severity: normal
status: open
title: Tools/unicode/gencodec.py error
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:31:17 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 20:31:17 +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: <1290889877.95.0.832290322531.issue7962@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +Tools/unicode/gencodec.py error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7962>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:34:34 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 27 Nov 2010 20:34:34 +0000
Subject: [issue9763] Crashes upon run after syntax error encountered in OSX
	10.5.8
In-Reply-To: <1283542973.95.0.133487128669.issue9763@psf.upfronthosting.co.za>
Message-ID: <1290890074.95.0.140697249372.issue9763@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Adding the nosy list from Issue6628 where this problem was originally reported.  What's interesting about this is that IDLE 2.x does not exhibit this behavior, AFAICT, when using the same Apple Tk 8.4.  As there are other odd behaviors with IDLE 3.x on OS X, I want to investigate this further.

----------
nosy: +brian89, ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9763>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:34:46 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 27 Nov 2010 20:34:46 +0000
Subject: [issue6628] IDLE freezes after encountering a syntax error
In-Reply-To: <1249254946.68.0.209899290876.issue6628@psf.upfronthosting.co.za>
Message-ID: <1290890086.26.0.874128239975.issue6628@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This issue was reported again in Issue9763; at the time, I overlooked your original report.  As there is a more recent discussion of it over there, I am going to close this as a duplicate and add you to the nosy list there.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> Crashes upon run after syntax error encountered in OSX 10.5.8

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6628>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:38:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 27 Nov 2010 20:38:50 +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: <1290890330.29.0.632144561424.issue10553@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

This patch adds an "optimize" parameter to compile(), as discussed in <http://mail.python.org/pipermail/python-ideas/2010-November/008784.html>.

I also needed to introduce two new C APIs.  Better naming suggestions are welcome.

----------
components: Library (Lib)
files: compile-optimize.diff
keywords: patch
messages: 122552
nosy: georg.brandl, krisvale
priority: normal
severity: normal
status: open
title: Add optimize argument to builtin compile() and byte-compilation modules
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19840/compile-optimize.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10553>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:47:16 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 27 Nov 2010 20:47:16 +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: <1290890836.58.0.988880918244.issue10107@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Considering the discussion on the idle-dev list back in October about this issue, I think this low-risk, high-benefit fix should be going into all three upcoming releases.

----------
nosy: +benjamin.peterson, georg.brandl
priority: high -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:47:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Nov 2010 20:47:40 +0000
Subject: [issue10554] Context managerment support for subprocess.Popen
In-Reply-To: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>
Message-ID: <1290890860.31.0.741074832583.issue10554@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

I propose that __enter__ and __exit__ be added to subprocess.Popen.  __enter__ returns self, __exit__ closes open file descriptors.

__exit__ could also do the same checks that __del__ does (and which I don?t entirely understand.

See also os.popen (os._wrap_close).

----------
components: Library (Lib)
keywords: easy
messages: 122554
nosy: eric.araujo
priority: normal
severity: normal
stage: needs patch
status: open
title: Context managerment support for subprocess.Popen
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10554>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:53:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 20:53:32 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1290891212.76.0.567908754514.issue10478@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch raising RuntimeError on reentrant calls to a buffered object. I haven't touched _pyio; I wonder how to do it without making it even slower.

----------
keywords: +patch
Added file: http://bugs.python.org/file19841/reentrantio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10478>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:54:02 2010
From: report at bugs.python.org (James Lamanna)
Date: Sat, 27 Nov 2010 20:54:02 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1290891242.1.0.899994310007.issue1731717@psf.upfronthosting.co.za>


James Lamanna <jlamanna at gmail.com> added the comment:

stubbing out subprocess._cleanup does not work around the problem from this example on 2.6.5:

import subprocess, signal
subprocess._cleanup = lambda: None

signal.signal(signal.SIGCLD, signal.SIG_IGN)
subprocess.Popen(['echo','foo']).wait()

james at hyla:~$ python tt.py
foo
Traceback (most recent call last):
  File "tt.py", line 5, in <module>
    subprocess.Popen(['echo','foo']).wait()
  File "/usr/lib/python2.6/subprocess.py", line 1170, in wait
    pid, sts = _eintr_retry_call(os.waitpid, self.pid, 0)
  File "/usr/lib/python2.6/subprocess.py", line 465, in _eintr_retry_call
    return func(*args)
OSError: [Errno 10] No child processes

This bug still prevents subprocess from being used inside of a daemon where SIGCLD is being caught to reap zombie processes.

----------
nosy: +jlamanna

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_______________________________________

From report at bugs.python.org  Sat Nov 27 21:57:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 20:57:01 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1290891421.26.0.360828116016.issue10478@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10478>
_______________________________________

From report at bugs.python.org  Sat Nov 27 22:01:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 27 Nov 2010 21:01:24 +0000
Subject: [issue3548] subprocess.pipe function
In-Reply-To: <1218561839.36.0.810217326739.issue3548@psf.upfronthosting.co.za>
Message-ID: <1290891684.87.0.683143785291.issue3548@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

pipe.patch looks interesting to me.  I would replace **kwargs with a keyword-only argument named stderr, since that?s the only key used.  This requires more tests and docs.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3548>
_______________________________________

From report at bugs.python.org  Sat Nov 27 22:04:56 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 27 Nov 2010 21:04:56 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290891896.82.0.390342578857.issue9264@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

?ric, please feel free to commit (and even grab Assigned To:) when you feel patch is ready. You can do final review better than me.

----------
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sat Nov 27 22:15:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 21:15:11 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za>
Message-ID: <1290892511.32.0.507848449298.issue10552@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch addresses the issue by using -1 instead of None for missing codes.  Comparison of generated encoding files to those in Lib/encodings shows only whitespace changes except one which appears to be a change on the unicode.org side:


diff -b build/koi8_u.py ../../Lib/encodings/koi8_u.py
1c1
< """ Python Character Mapping Codec koi8_u generated from 'MAPPINGS/VENDORS/MISC/KOI8-U.TXT' with gencodec.py.
---
> """ Python Character Mapping Codec koi8_u generated from 'python-mappings/KOI8-U.TXT' with gencodec.py.
221c221
<     '\u0491'    #  0xAD -> CYRILLIC SMALL LETTER GHE WITH UPTURN
---
>     '\u0491'   #  0xAD -> CYRILLIC SMALL LETTER UKRAINIAN GHE WITH UPTURN
237c237
<     '\u0490'    #  0xBD -> CYRILLIC CAPITAL LETTER GHE WITH UPTURN
---
>     '\u0490'   #  0xBD -> CYRILLIC CAPITAL LETTER UKRAINIAN GHE WITH UPTURN
308d307
<

----------
keywords: +patch
nosy: +loewis
Added file: http://bugs.python.org/file19842/issue10552.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Sat Nov 27 22:34:43 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sat, 27 Nov 2010 21:34:43 +0000
Subject: [issue9509] argparse FileType raises ugly exception for missing file
In-Reply-To: <1280927287.23.0.0771144110186.issue9509@psf.upfronthosting.co.za>
Message-ID: <1290893683.16.0.358881958181.issue9509@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Sorry, I was looking at the akira patch with the same date, where I was mainly worried about the modification of the "except (TypeError, ValueError):" block. Your patch doesn't do that, and looks fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9509>
_______________________________________

From report at bugs.python.org  Sat Nov 27 22:42:03 2010
From: report at bugs.python.org (Anurag Chourasia)
Date: Sat, 27 Nov 2010 21:42:03 +0000
Subject: [issue10555] Fatal Python error: Interpreter not initialized (version
	mismatch?)
In-Reply-To: <1290894123.11.0.895090468889.issue10555@psf.upfronthosting.co.za>
Message-ID: <1290894123.11.0.895090468889.issue10555@psf.upfronthosting.co.za>


New submission from Anurag Chourasia <anurag.chourasia at gmail.com>:

Python extensions build on AIX 5.3 with GCC 4.2 fails.

The configure command was as follows

./configure --enable-shared --disable-ipv6 --with-gcc=gcc CPPFLAGS="-I /opt/freeware/include -I /opt/freeware/include/readline -I /opt/freeware/include/ncurses" LDFLAGS="-L. -L/usr/local/lib"

The error during the make step was as follows

running build
running build_ext
ldd: /lib/libreadline.a: File is an archive.
building dbm using ndbm
INFO: Can't locate Tcl/Tk libs and/or headers
building '_struct' extension
creating build
creating build/temp.aix-5.3-2.7
creating build/temp.aix-5.3-2.7/u01
creating build/temp.aix-5.3-2.7/u01/home
creating build/temp.aix-5.3-2.7/u01/home/apli
creating build/temp.aix-5.3-2.7/u01/home/apli/wm
creating build/temp.aix-5.3-2.7/u01/home/apli/wm/GDD
creating build/temp.aix-5.3-2.7/u01/home/apli/wm/GDD/Python-2.7
creating build/temp.aix-5.3-2.7/u01/home/apli/wm/GDD/Python-2.7/Modules
gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/opt/freeware/include -I/opt/freeware/include/readline -I/opt/freeware/include/ncurses -I/usr/local/include -I/u01/home/apli/wm/GDD/Python-2.7/Include -I/u01/home/apli/wm/GDD/Python-2.7 -c /u01/home/apli/wm/GDD/Python-2.7/Modules/_struct.c -o build/temp.aix-5.3-2.7/u01/home/apli/wm/GDD/Python-2.7/Modules/_struct.o
creating build/lib.aix-5.3-2.7
./Modules/ld_so_aix gcc -pthread -bI:Modules/python.exp -L. -L/usr/local/lib build/temp.aix-5.3-2.7/u01/home/apli/wm/GDD/Python-2.7/Modules/_struct.o -L. -L/usr/local/lib -lpython2.7 -o build/lib.aix-5.3-2.7/_struct.so
Fatal Python error: Interpreter not initialized (version mismatch?)
make: 1254-059 The signal code from the last command is 6.


The file build/lib.aix-5.3-2.7/_struct.so is present after this error. 

The error seems to be in importing the module that was just built. Here is the error message from the python executable that was built.

root [zibal]% pwd
/u01/home/apli/wm/GDD/Python-2.7
root [zibal]% which python
./python
root [zibal]% python
Python 2.7 (r27:82500, Nov 27 2010, 18:33:21)
[GCC 4.2.4] on aix5
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
Fatal Python error: Interpreter not initialized (version mismatch?)
IOT/Abort trap(coredump)

This is also an error in Version 2.6.6

I don't have any other conflicting python library that might cause this.

----------
components: Build
messages: 122561
nosy: Anurag.Chourasia
priority: normal
severity: normal
status: open
title: Fatal Python error: Interpreter not initialized (version mismatch?)
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10555>
_______________________________________

From report at bugs.python.org  Sat Nov 27 22:43:49 2010
From: report at bugs.python.org (Anurag Chourasia)
Date: Sat, 27 Nov 2010 21:43:49 +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: <1290894229.86.0.752102882791.issue10555@psf.upfronthosting.co.za>


Changes by Anurag Chourasia <anurag.chourasia at gmail.com>:


----------
title: Fatal Python error: Interpreter not initialized (version mismatch?) -> AIX 5.3 - GCC - Python 2.7 Shared Library Support - Fatal Python error: Interpreter not initialized (version mismatch?)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10555>
_______________________________________

From report at bugs.python.org  Sat Nov 27 22:47:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 21:47:20 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290894440.04.0.431914849682.issue10518@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It might be not "obvious", but it's consistent with the check for other 
> attributes.

I don't know what attributes you're talking about, and there doesn't seem to be a lot of consistency there.
Besides, being consistently obscure and hard to find is not the good type of consistency :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:00:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 22:00:41 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290895241.75.0.00482135858583.issue10518@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r86842.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:01:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 22:01:31 +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: <1290895291.89.0.468387043973.issue10555@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +barry, skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10555>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:03:20 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 27 Nov 2010 22:03: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: <1290895400.38.0.59035357378.issue10542@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I like the idea and thanks for putting work into this.

Some comments:
 
 * when using macro variables, always put the variables in parens in the expansion; this avoids precedence issues, weird syntax errors, etc. - even if it may not be necessary
 
 * a function would be cleaner, but since this code is very performance sensitive, I'd opt for the macro version, unless someone can prove that a function would be just as fast in benchmarks
 
 * the macros should be documented in the unicodeobject.h header file and clearly mention that ptr and end should be side-effect free and that ptr must an lvalue
 
 * please use the faster bitmask operators for joining surrogates, i.e. ucs4 = ((((high & 0x03FF) << 10) | (low & 0x03FF)) + 0x00010000);

 * the Py_UNICODE_JOIN_SURROGATES() macro should use Py_UCS4 as prefix since it returns Py_UCS4 values, i.e. Py_UCS4_JOIN_SURROGATES()

 * same for the Py_UNICODE_NEXT() macro, i.e. Py_UCS4_NEXT()
 
 * in order to make the macro easier to understand, please rename it to Py_UCS4_READ_CODE_POINT(); that's a little more typing, but still a lot less than without the macro :-)

 * this version should be slightly faster and is also easier to read:
 
#define Py_UCS4_READ_CODE_POINT(ptr, end) \
    ((Py_UNICODE_ISHIGHSURROGATE((ptr)[0]) && \
      (ptr) < (end) && \
      Py_UNICODE_ISLOWSURROGATE((ptr)[1])) ? \
      Py_UNICODE_JOIN_SURROGATES((ptr)++, (ptr)++) : \
      (Py_UCS4)*(ptr)++)

   I haven't tested it, but you get the idea.
   
BTW: You only focus on UCS2 builds. Please also make sure that these changes work on UCS4 builds, e.g. Py_UCS2_READ_CODE_POINT() will also work on UCS4 builds and join code points there.

Note that UCS4 builds currently don't join surrogates, so a high and low surrogates appear as two code points, which they are, but given the experience with UCS2 builds, may not be what the user expects. So for the purpose of consistency we should be careful with auto-joining surrogates in UCS2.

It does make sence for ord() and the various string methods, but should be done with care in other cases.

In any case, we should clearly document where these macros are used and warn about the implications of using them in the wrong places.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:09:49 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 27 Nov 2010 22:09:49 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <1290892511.32.0.507848449298.issue10552@psf.upfronthosting.co.za>
Message-ID: <4CF181AA.3010702@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:
> 
> Attached patch addresses the issue by using -1 instead of None for missing codes.  Comparison of generated encoding files to those in Lib/encodings shows only whitespace changes except one which appears to be a change on the unicode.org side:

Please use a global constant instead of the literal -1, e.g. MISSING_CODE.
Thanks.

> diff -b build/koi8_u.py ../../Lib/encodings/koi8_u.py
> 1c1
> < """ Python Character Mapping Codec koi8_u generated from 'MAPPINGS/VENDORS/MISC/KOI8-U.TXT' with gencodec.py.
> ---
>> """ Python Character Mapping Codec koi8_u generated from 'python-mappings/KOI8-U.TXT' with gencodec.py.
> 221c221
> <     '\u0491'    #  0xAD -> CYRILLIC SMALL LETTER GHE WITH UPTURN
> ---
>>     '\u0491'   #  0xAD -> CYRILLIC SMALL LETTER UKRAINIAN GHE WITH UPTURN
> 237c237
> <     '\u0490'    #  0xBD -> CYRILLIC CAPITAL LETTER GHE WITH UPTURN
> ---
>>     '\u0490'   #  0xBD -> CYRILLIC CAPITAL LETTER UKRAINIAN GHE WITH UPTURN
> 308d307
> <

That's just a comment and doesn't change the semantics of the codec.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:10:16 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Nov 2010 22:10:16 +0000
Subject: [issue10550] Windows: leak in test_concurrent_futures
In-Reply-To: <1290883227.71.0.820732153232.issue10550@psf.upfronthosting.co.za>
Message-ID: <1290895816.64.0.987726650704.issue10550@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Committed posixmodule_listdir.patch in r86843. Unfortunately this
is unrelated to the test_concurrent_futures leak.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10550>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:14:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 22:14:08 +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: <AANLkTimDQLg2fbaQ9_1-SHPsrdNcb=hxWxBQKOp8=jPp@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:
.. [I'll respond to skipped when I update the patch]

> In any case, we should clearly document where these macros are used and
> warn about the implications of using them in the wrong places.

It may be best to start with _Py_UCS2_READ_CODE_POINT() (BTW, I like
the name because it naturally lead to Py_UCS2_WRITE_CODE_POINT()
counterpart.)  The leading underscore will probably not stop early
adopters from using it and we may get some user feedback if they ask
to make these macros public.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:16:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Nov 2010 22:16:02 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za>
Message-ID: <1290896162.66.0.289609292641.issue10552@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/issue10552>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:19:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 22:19:41 +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: <AANLkTinOHNDpk5qAUqDL16p_cxMAcFM0FvEL45ZHYEA0@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:
..
> ?* same for the Py_UNICODE_NEXT() macro, i.e. Py_UCS4_NEXT()
>
> ?* in order to make the macro easier to understand, please rename it to
>  Py_UCS4_READ_CODE_POINT(); that's a little more typing, but still
>  a lot less than without the macro :-)

I am not sure Py_UCS4_ prefix is right here.  (I agree on *SURROGATE*
methods.)  The point of Py_UNICODE_NEXT(ptr, end) is that the pointers
ptr and end are Py_UNICODE* and the macro expands to *p++ on wide
builds.  Maybe Py_UNICODE_NEXT_USC4?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:20:40 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Nov 2010 22:20:40 +0000
Subject: [issue7663] UCS4 build incorrectly translates cases for non-BMP code
	points
In-Reply-To: <1263101250.07.0.175926881279.issue7663@psf.upfronthosting.co.za>
Message-ID: <1290896440.52.0.366015871269.issue7663@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

This is not yet fixed but will be addressed in #10521 and #10542.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7663>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:23:42 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 27 Nov 2010 22:23:42 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290896622.54.0.00173291005258.issue10518@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

I thought PEP 3003 was quite unambiguous:

>This PEP proposes a temporary moratorium (suspension) of **all changes** to the Python language syntax, semantics, and built-ins for a period of at least two years from the release of Python 3.1. In particular, the moratorium would include Python 3.2 (to be released 18-24 months after 3.1) but allow Python 3.3 (assuming it is not released prematurely) to once again include language changes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:24:39 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 27 Nov 2010 22:24:39 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <AANLkTinOHNDpk5qAUqDL16p_cxMAcFM0FvEL45ZHYEA0@mail.gmail.com>
Message-ID: <4CF18525.1050103@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 5:03 PM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
> ..
>>  * same for the Py_UNICODE_NEXT() macro, i.e. Py_UCS4_NEXT()
>>
>>  * in order to make the macro easier to understand, please rename it to
>>  Py_UCS4_READ_CODE_POINT(); that's a little more typing, but still
>>  a lot less than without the macro :-)
> 
> I am not sure Py_UCS4_ prefix is right here.  (I agree on *SURROGATE*
> methods.)  The point of Py_UNICODE_NEXT(ptr, end) is that the pointers
> ptr and end are Py_UNICODE* and the macro expands to *p++ on wide
> builds.  Maybe Py_UNICODE_NEXT_USC4?

The idea is that the first part refers to what the macro returns (Py_UCS4)
and the "read" part of the name refers to moving a pointer across
an array (any array of integers).

Note that the macro can also work on Py_UCS4 arrays (even in
UCS2 builds), so it's universal in that respect.

Perhaps we should allow ord() to work on surrogates in
UCS4 builds as well. That would reduce the number of
surprises.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:26:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 22:26:49 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290896622.54.0.00173291005258.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290896805.3549.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 27 novembre 2010 ? 22:23 +0000, SilentGhost a ?crit :
> SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:
> 
> I thought PEP 3003 was quite unambiguous:

The stated goal of the moratorium is to make it easier for alternate
implementations to catch up with the current language specification.
Bringing back callable() doesn't go against this goal since they already
have implemented it for 2.x.
(not to mention that the implementation should be very simple)

I wouldn't claim this is a authoritative interpretation but, if Guido
doesn't oppose, I would take it for valid :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:29:08 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 27 Nov 2010 22:29:08 +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: <1290896948.65.0.642470839626.issue10542@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

> The idea is that the first part refers to what the macro
> returns (Py_UCS4) and the "read" part of the name refers 
> to moving a pointer across an array (any array of integers).

I thought the first part generally meant the type of the first parameter. Although I can go either way, especially if we add an underscore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:30:57 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 27 Nov 2010 22:30:57 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290897057.83.0.543895249706.issue10518@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

I thought that moratorium meant Guido dis/approval is not applicable to the 3.2

Another listed change was help ease adoption of py3k. How's that helping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:31:41 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Nov 2010 22:31:41 +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: <1290897101.55.0.352380116819.issue10555@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Anurag, could you check out #941346 and see if there is anything that
might help? I think this is AIX specific.

----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10555>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:32:01 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 27 Nov 2010 22:32:01 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290897057.83.0.543895249706.issue10518@psf.upfronthosting.co.za>
Message-ID: <AANLkTinGbC0xCHFJsWWXk8_P4oUnivHHW=0fcXK9VK7u@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/11/27 SilentGhost <report at bugs.python.org>:
>
> SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:
>
> I thought that moratorium meant Guido dis/approval is not applicable to the 3.2
>
> Another listed change was help ease adoption of py3k. How's that helping?

By causing one less discontinuity.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:33:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 22:33:12 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290897057.83.0.543895249706.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290897188.3549.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I thought that moratorium meant Guido dis/approval is not applicable to the 3.2

Guido can decide of everything: PEPs, etc. That's what "BDFL" means.
So he can also decide of exceptions to the rules he decided on.
(rules can have exception in any reasonable human society)

> Another listed change was help ease adoption of py3k. How's that helping?

How's it not helping?

I'm not sure what your general point or concern is. Do you have a real
problem with callable() coming back or is it just a formal argument?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:41:19 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Nov 2010 22:41:19 +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: <1290897679.59.0.329536250931.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

> * the Py_UNICODE_JOIN_SURROGATES() macro should use Py_UCS4 as prefix since it returns Py_UCS4 values, i.e. Py_UCS4_JOIN_SURROGATES()
> * same for the Py_UNICODE_NEXT() macro, i.e. Py_UCS4_NEXT()

I'm not so familiar with the prefix conventions, but wouldn't that lead users to think that this macro is for wide builds and that they have to use Py_UCS2_* macros for narrow builds? If these macros are supposed to abstract the build type maybe they should have a "neutral" prefix. (But if the conventions we use say otherwise I guess the best we can do is to document it properly).
 
> * in order to make the macro easier to understand, please rename it to Py_UCS4_READ_CODE_POINT(); that's a little more typing, but still a lot less than without the macro :-)

The term code point is not entirely correct here. High and low surrogates are code points too. The right term should be 'scalar value' (but that might be confusing). The 'READ' bit sounds fine though, maybe 'READ_NEXT'?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:41:39 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 27 Nov 2010 22:41:39 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290897699.75.0.721655336513.issue10518@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

yes, my problem is that callable was removed and a way was shown how to do this check. The way which is consistent with the check for any other type (ABC). Now out of the blue, w/o any justification this way is going to be ignored, because "ah, sure. I can't be bothered typing extra three characters" and the old function is reintroduced. 

I don't like that we're heading into Perl's direction. that's all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:42:01 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 27 Nov 2010 22:42:01 +0000
Subject: [issue10547] FreeBSD: wrong value for LDSHARED in sysconfig
In-Reply-To: <1290865671.36.0.14618274941.issue10547@psf.upfronthosting.co.za>
Message-ID: <1290897721.88.0.823695391272.issue10547@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Upgrading to critical, since I just verified that C extensions in
general don't build on FreeBSD due to this issue.

Sorry for bringing this up on the release day, it's a coincidence that
I discovered it today...

----------
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10547>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:44:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 22:44:20 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290897699.75.0.721655336513.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290897855.23986.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> yes, my problem is that callable was removed and a way was shown how
> to do this check. The way which is consistent with the check for any
> other type (ABC).

ABCs are still the exception in Python, and duck typing is still the
rule.

> I don't like that we're heading into Perl's direction. that's all.

Well, please deal with it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:46:38 2010
From: report at bugs.python.org (SilentGhost)
Date: Sat, 27 Nov 2010 22:46:38 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290603925.1.0.525314033475.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290897998.91.0.650708525744.issue10518@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

> ABCs are still the exception in Python, and duck typing is still the
rule.

Then why do we callable again?

Don't worry, I'll deal with it. It's not like this whole discussion mattered.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Sat Nov 27 23:54:33 2010
From: report at bugs.python.org (Kovid Goyal)
Date: Sat, 27 Nov 2010 22:54:33 +0000
Subject: [issue10551] mimetypes reading from registry in windows completely
	broken
In-Reply-To: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>
Message-ID: <1290898473.02.0.650254927913.issue10551@psf.upfronthosting.co.za>


Kovid Goyal <kovid at kovidgoyal.net> added the comment:

And what about the third issue?

Allow me to elaborate:

mimetypes are a relatively standard set of mappings from well known file extensions to MIME descriptors. 

Reading mimetype mappings from the registry, a location that is writable to by random programs the user may have installed on his machine, let alone malware, is a BAD idea.

It leads to situations like asking for the mimetype of file.jpg and getting iage/pjpeg back. Or asking for the mimetype of file.png and getting image/x-png back.

If you still consider it good to read mimetypes from the registry, at the very least, they should be read before the standard mimetype mappings defined in mimetypes.py are applied. That way at least for that set of mappings, users of python can be assured of sane query results. 

As it stands now, mimetypes.py is useless and to workaround the problem I essentially had to define the mimetype mappings for all the mimetypes my program knows about by hand.

----------
resolution: duplicate -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10551>
_______________________________________

From report at bugs.python.org  Sun Nov 28 00:00:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 23:00:41 +0000
Subject: [issue10518] Bring back callable()
In-Reply-To: <1290897998.91.0.650708525744.issue10518@psf.upfronthosting.co.za>
Message-ID: <1290898837.23986.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > ABCs are still the exception in Python, and duck typing is still the
> rule.
> 
> Then why do we callable again?

Because the way __call__ is looked up means hasattr(x, "__call__") is
not the right answer. Otherwise there would be no point in bringing it
back at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10518>
_______________________________________

From report at bugs.python.org  Sun Nov 28 00:02:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 23:02:26 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za>
Message-ID: <1290898946.43.0.43457494444.issue10552@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch uses MISSING_CODE as Mark suggested.  There are still errors apparently because parsecodes() may return either an int or a tuple.  I think only mac encodings are affected, so I would like to commit the current patch before tackling this issue. 

$ ../../python.exe  gencodec.py MAPPINGS/VENDORS/APPLE/ build/ mac_
converting ARABIC.TXT to build/mac_arabic.py and build/mac_arabic.mapping
converting CELTIC.TXT to build/mac_celtic.py and build/mac_celtic.mapping
converting CENTEURO.TXT to build/mac_centeuro.py and build/mac_centeuro.mapping
converting CHINSIMP.TXT to build/mac_chinsimp.py and build/mac_chinsimp.mapping
Traceback (most recent call last):
  File "gencodec.py", line 424, in <module>
    convertdir(*sys.argv[1:])
  File "gencodec.py", line 394, in convertdir
    pymap(mappathname, map, dirprefix + codefile,name,comments)
  File "gencodec.py", line 358, in pymap
    code = codegen(name,map,encodingname,comments)
  File "gencodec.py", line 271, in codegen
    precisions=(4, 2))
  File "gencodec.py", line 155, in python_mapdef_code
    mappings = sorted(map.items())
TypeError: unorderable types: tuple() < int()

----------
stage:  -> commit review
Added file: http://bugs.python.org/file19843/issue10552a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Sun Nov 28 00:03:05 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 23:03:05 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za>
Message-ID: <1290898985.1.0.234546732386.issue10552@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Please ignore Makefile changes in the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Sun Nov 28 00:12:45 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 27 Nov 2010 23:12:45 +0000
Subject: [issue10551] mimetypes reading from registry in windows completely
	broken
In-Reply-To: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>
Message-ID: <1290899565.21.0.695268567105.issue10551@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

(Sorry, I skipped over the third: this is one reason why one should not include multiple problems in one tracker issue.)

As to your third point, a quick search of "mimetypes" in the bugtracker shows that looking in the Windows registry for mimetypes was a new feature in 2.7 and the upcoming 3.2 added by Issue4969.

Adding the Windows maintainers and the Nosy List from that issue.

----------
nosy: +gagenellina, loewis, ocean-city, pitrou, tercero12, tim.golden
superseder: mimetypes initialization fails on Windows because of non-Latin characters in registry -> 
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10551>
_______________________________________

From report at bugs.python.org  Sun Nov 28 00:20:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 27 Nov 2010 23:20:06 +0000
Subject: [issue10542] Py_UNICODE_NEXT and other macros for surrogates
In-Reply-To: <1290897679.59.0.329536250931.issue10542@psf.upfronthosting.co.za>
Message-ID: <AANLkTiktw31aoopWqHH=j0rG6Ad5nAUbMCtwkU5KK+yb@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Nov 27, 2010 at 5:41 PM, Ezio Melotti <report at bugs.python.org> wrote:
>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
>> * the Py_UNICODE_JOIN_SURROGATES() macro should use Py_UCS4 as prefix since it returns Py_UCS4 values, i.e. Py_UCS4_JOIN_SURROGATES()
>> * same for the Py_UNICODE_NEXT() macro, i.e. Py_UCS4_NEXT()
>
> I'm not so familiar with the prefix conventions, but wouldn't that lead users to think that this macro is for wide builds and that they have to use Py_UCS2_* macros for narrow builds? If these macros are supposed to abstract the build type maybe they should have a "neutral" prefix. (But if the conventions we use say otherwise I guess the best we can do is to document it properly).

When I was using the name, I did not think about argument type.
Py_UNICODE_ is just the namespace prefix used by all macros in
unicodeobject.h. Case in point: Py_UNICODE_ISALPHA() and family that
take Py_UCS4.  (I know, there is a historical reason at work here, but
why fight it?)

Functions use PyUnicode_ prefix and build specific functions use
PyUnicodeUCSx_ prefix.   As far as I can tell, there are no macros
with Py_UCS4_ prefix.  The choices I like in the order of preference
are

1. Py_UNICODE_NEXT
2. Py_UNICODE_NEXT_UCS4
3. Py_UNICODE_READ_NEXT_UCS4

I can live with anything else, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sun Nov 28 00:20:22 2010
From: report at bugs.python.org (Kovid Goyal)
Date: Sat, 27 Nov 2010 23:20:22 +0000
Subject: [issue10551] mimetypes read from the registry should not overwrite
	standard mime mappings
In-Reply-To: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>
Message-ID: <1290900022.6.0.116085803622.issue10551@psf.upfronthosting.co.za>


Kovid Goyal <kovid at kovidgoyal.net> added the comment:

I apologize for the multiple issue in the ticket. To my mind they were all basically one issue, stemming from the decision to read mimetypes from the registry.

Since there are other tickets for the first two issues, I'll change the summary for this issue to reflect only the third.

----------
title: mimetypes reading from registry in windows completely broken -> mimetypes read from the registry should not overwrite standard mime mappings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10551>
_______________________________________

From report at bugs.python.org  Sun Nov 28 00:21:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 23:21:08 +0000
Subject: [issue10556] test_zipimport_support mucks up with modules
In-Reply-To: <1290900068.1.0.744896012432.issue10556@psf.upfronthosting.co.za>
Message-ID: <1290900068.1.0.744896012432.issue10556@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This test failure is due to test_zipimport_support loading and unloading modules, which leads to them being reloaded. Then the ssl.CertificateError which is checked for by assertRaises isn't the same as the one raised by the module under test (I have printed the type names and ids below):

$ ./python -E -bb -m test.regrtest test_http_cookies test_zipimport_support test_httplib
[1/3] test_http_cookies
[2/3] test_zipimport_support
[3/3] test_httplib
<class 'ssl.CertificateError'> 49243264
<class 'ssl.CertificateError'> 51134640
test test_httplib failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_httplib.py", line 481, in test_local_bad_hostname
    h.request('GET', '/')
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 950, in request
    self._send_request(method, url, body, headers)
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 988, in _send_request
    self.endheaders(body)
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 946, in endheaders
    self._send_output(message_body)
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 791, in _send_output
    self.send(msg)
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 737, in send
    self.connect()
  File "/home/antoine/py3k/__svn__/Lib/http/client.py", line 1096, in connect
    ssl.match_hostname(self.sock.getpeercert(), self.host)
  File "/home/antoine/py3k/__svn__/Lib/ssl.py", line 142, in match_hostname
    % (hostname, dnsnames[0]))
ssl.CertificateError: hostname 'localhost' doesn't match 'fakehostname'


(witnessed in http://www.python.org/dev/buildbot/all/builders/AMD64%20Snow%20Leopard%203.x/builds/527/steps/test/logs/stdio )

----------
components: Tests
messages: 122590
nosy: brett.cannon, ncoghlan, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_zipimport_support mucks up with modules
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10556>
_______________________________________

From report at bugs.python.org  Sun Nov 28 00:31:48 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sat, 27 Nov 2010 23:31:48 +0000
Subject: [issue7663] narrow build incorrectly translates cases for non-BMP
	code points
In-Reply-To: <1263101250.07.0.175926881279.issue7663@psf.upfronthosting.co.za>
Message-ID: <1290900708.18.0.602962059366.issue7663@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


----------
title: UCS4 build incorrectly translates cases for non-BMP code points -> narrow build incorrectly translates cases for non-BMP code points

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7663>
_______________________________________

From report at bugs.python.org  Sun Nov 28 00:38:51 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 27 Nov 2010 23:38:51 +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: <1290901131.19.0.735396835024.issue10542@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I suggest Py_UNICODE_ADVANCE() to avoid false suggestion that the iterator protocol is being used.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sun Nov 28 00:49:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 27 Nov 2010 23:49: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: <1290901744.23986.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I suggest Py_UNICODE_ADVANCE() to avoid false suggestion that the
> iterator protocol is being used.

You can't use the iterator protocol on a non-PyObject, and Py_UNICODE_*
(as opposed to PyUnicode_*) suggests the macro operates on a raw array
of code points.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sun Nov 28 00:54:44 2010
From: report at bugs.python.org (Vil)
Date: Sat, 27 Nov 2010 23:54:44 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290513811.05.0.811757418895.issue10500@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Y74=XQVPxq5aZy5tjW4J+QDWxbDnVXkSJyhhM@mail.gmail.com>


Vil <vilignoble at gmail.com> added the comment:

http://www.python.org/ftp/python/3.1.2/python-3.1.2.msi

it was this link on download page for msi windows x86 installer

On Tue, Nov 23, 2010 at 6:03 AM, Martin v. L??wis <report at bugs.python.org>wrote:

>
> Martin v. L??wis <martin at v.loewis.de> added the comment:
>
> What file specifically did you download?
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10500>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19844/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________
-------------- next part --------------
<a href="http://www.python.org/ftp/python/3.1.2/python-3.1.2.msi">http://www.python.org/ftp/python/3.1.2/python-3.1.2.msi</a><br><br>it was this link on download page for msi windows x86 installer<br><br><div class="gmail_quote">
On Tue, Nov 23, 2010 at 6:03 AM, Martin v. L??wis <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Martin v. L??wis &lt;<a href="mailto:martin at v.loewis.de">martin at v.loewis.de</a>&gt; added the comment:<br>
<br>
What file specifically did you download?<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/issue10500" target="_blank">http://bugs.python.org/issue10500</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Sun Nov 28 01:46:51 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Nov 2010 00:46:51 +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: <1290905211.52.0.313719022267.issue10542@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

AFAIU the macro returns lone surrogates as they are, this means that:
  1) if the string contains only surrogate pairs, Py_UNICODE_NEXT will iterate on scalar values[0];
  2) if the string contains only lone surrogates, it will iterate on codepoints[1];
  3) if it contains both it will be half and half (i.e. scalar values if the surrogates are in pair, or falling back on codepoints if they aren't);
(for strings without surrogates, iterating on scalar values or codepoints is the same).

Is this semantic correct for all (or at least most of) the places where the macro will be used?
Would a stricter version (that rejects lone surrogates and iterates on scalar values only) be useful in addition or in alternative to Py_UNICODE_NEXT?

[0]: http://unicode.org/glossary/#unicode_scalar_value
[1]: http://unicode.org/glossary/#code_point

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sun Nov 28 02:39:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 01:39: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: <1290908373.84.0.554977255446.issue10542@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a patch that defines Py_UNICODE_PUT_NEXT() macro (tentative name) and uses it to fix str.upper method.  The implementation of surrogate-aware str.upper shows that NEXT/PUT_NEXT abstractions may lead to somewhat inefficient code for "by codepoint" processing.  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. (Please, don't argue over names - let's figure out the proper semantics first.)

----------
Added file: http://bugs.python.org/file19845/issue10542-put-next.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10542>
_______________________________________

From report at bugs.python.org  Sun Nov 28 02:40:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 01:40:45 +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: <1290908445.32.0.217393958093.issue9299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch still applies without errors.  Georg, since you reviewed the patch and approved it for 3.2, I?m marking as pending and assigning to you.  Tell me if I shouldn?t have.

----------
assignee:  -> georg.brandl
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9299>
_______________________________________

From report at bugs.python.org  Sun Nov 28 02:42:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 01:42:59 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290908579.17.0.913770287006.issue2001@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

First, thanks for your work on this.  I have some feature requests for pydoc too and I?m hoping to work with you in the future :)

I found it more efficient (and fair) to make a new diff instead of listing all nitpicks and have you do the changes.  issue_2001_g.diff applies cleanly in py3k.  I fixed style issues, removed some docstrings in private classes that were in my eyes unhelpful (the purpose of the class being clear from its name of from a bit of knowledge about http.server), and added the possibility to quit the server with EOF or Ctrl-C.

There were a number of trailing spaces in your files.  Suggestions: better editor settings, use of hg diff with the color extension, make patchcheck (using Python?s makefile).

I have removed the overly long entry from NEWS, I suggest it is used as commit message instead.  Here it is, corrected:

?Improve Pydoc interactive browsing (#2001).  Patch by Ron Adam.

* A ``-b`` option to start an enhanced browsing session.
* Allow ``-b`` and ``-p`` options to be used together.
* Specifying port 0 will pick an arbitrary unused socket port.
* A new ``browse()`` function to start the new server and browser.
* Show Python version information in the header.
* A *Get* field which takes the same input as the ``help()`` function.
* A *Search* field which replaces the Tkinter search box.
* Lnks to *Module Index*, *Topics*, and *Keywords*.
* Improved source file viewing.
* An ``HTMLDoc.filelink()`` method.
* The ``-g`` option and the ``gui()`` and ``serve()`` functions are
deprecated.?

issue_2001_f+1.diff shows only the changes I made on top of yours (+ some changes from the py3k branch).  Please ask any question you may have about them.


Now, those style issues were only the easy parts.  Remaining issues (I mean they?re issues to me, you or Nick may disagree):

1) _start_server has a bit of documentation in its docstring, but it?s a private function.  Also, two lines are commented so that ?make doctest? does not run them, but that is non-obvious and breaks the flow of the text.  I recommend doing a combination of those things, at your call: Move those docs to a public function docstring and/or reST doc; move those docs to a comment; don?t use the doctest as test but add a unit test; remove most of the docstring.

2) Functions in methods in classes in functions don?t look great to me.  I understand pydoc tries not to import things before it knows it needs them, and it?s also a way of keeping things private, but I think flat is better (more readable) than nested.

3) bltinlink is defined six times.  Global (private) function please? :)

4) The HTML has two html elements, two doctypes, an invalid clear attribute on a div element.

5) Last but not least, the deprecations.  A few developers had a chat with Raymond Hettinger on IRC yesterday about the cost of deprecations and removals.  His defended that their harm (forcing people to change their code) was bigger than their usefulness (catering to esthetic tastes of core developers).  How about we arrange the docs and docstrings in order to make the new ways prominent and deprecate the old ones, without any actual code deprecation?

----------
Added file: http://bugs.python.org/file19846/issue_2001_f+1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Sun Nov 28 02:43:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 01:43:23 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290908603.77.0.208859839738.issue2001@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Added file: http://bugs.python.org/file19847/issue_2001_g.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Sun Nov 28 02:52:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 01:52:22 +0000
Subject: [issue6878] changed return type from tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1290909142.24.0.427189158165.issue6878@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

tkinter/__init__.py and tix.py are not consistent throughout with their indentation, your commit did not add hard to read code, so it?s okay.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________

From report at bugs.python.org  Sun Nov 28 02:59:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 01:59:47 +0000
Subject: [issue940286] pydoc.Helper.help() ignores input/output init parameters
Message-ID: <1290909587.56.0.203575599307.issue940286@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue940286>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:11:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 02:11:20 +0000
Subject: [issue940286] pydoc.Helper.help() ignores input/output init parameters
Message-ID: <1290910280.33.0.541716463373.issue940286@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patchset 3 on codereview looks good.  I?d like another review, so I?m adding the latest developers who touched pydoc.

----------
nosy: +belopolsky, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue940286>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:14:43 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 28 Nov 2010 02:14:43 +0000
Subject: [issue9281] Race condition with mkdir/makedirs in distutils2
In-Reply-To: <1279342839.57.0.133468665449.issue9281@psf.upfronthosting.co.za>
Message-ID: <1290910483.38.0.585533780525.issue9281@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

Maybe issue #9299 could be fixed first. Next you could backport new os.makedirs() in distutils2/_backport/os.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9281>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:17:46 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Nov 2010 02:17:46 +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: <1290910666.41.0.0972437221145.issue9299@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Patch is missing version-added directive and News entry. I will try to add these and re-upload for final check.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9299>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:18:30 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 28 Nov 2010 02:18:30 +0000
Subject: [issue10262] Add --disable-abi-flags option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1290910710.42.0.120291313481.issue10262@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I want to eliminate ABI flags in file names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:20:30 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 28 Nov 2010 02:20:30 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290910830.0.0.498748423766.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Regarding question 1 (_start_server docstring):

I have no problem with docstrings on private functions in general. It just means they're for the benefit of developers of the module itself rather than users of the module. However, in this case, I would move the "example use" out of the docstring and into a comment following the docstring.

Regarding questions 2 & 5 (code structure and deprecations):

This whole patch would have been a *lot* easier if the server and GUI implementations in pydoc had been properly private from the start. A look at the docs makes it fairly obvious that these are meant to be implementation details of the command line invocation, but the way they were written meant they were exposed as a public standard library API. As a result, we have to jump through a lot of hoops to replace them with the new back end.

Since we don't want to maintain the old GUI client or the associated web server backend, the deprecations are needed so we can delete them entirely in 3.3. The situations Raymond is talking about are cases where we come up with a "better" API, but an old API is popular and not really all that flawed within its original scope (e.g. getopt vs optparse vs argparse). In such cases, deprecation gains us little and causes a lot of hassle. However, in a case like this, where people shouldn't have been using the old API anyway and there's a mountain of code we want to get rid of, deprecating the associated API is the right thing to do.

The nested code structure is a reaction to the concern that caused all the additional difficulty - by squirreling all the implementation details away inside a small number of functions that are named with leading underscores, we eliminate the temptation to rely on the current location of these classes. For 3.3, I'd like to pursue Ron's idea of pulling the text server out and placing it in http.server for general use, with pydoc then retrieving it from there.

Regarding questions 3 & 4 (repetition of bltinlink and HTML dodginess):

Those two sound like issues that should be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:24:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 02:24:03 +0000
Subject: =?utf-8?b?W2lzc3VlODg4N10g4oCccHlkb2Mgc3Ry4oCdIHdvcmtzIGJ1dCBub3Qg4oCc?=
	=?utf-8?q?pydoc_str=2Etranslate=E2=80=9D?=
In-Reply-To: <1275565374.87.0.956319261544.issue8887@psf.upfronthosting.co.za>
Message-ID: <1290911043.6.0.611890067531.issue8887@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8887>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:34:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 02:34:19 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1290911659.59.0.433181805447.issue3243@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
resolution: accepted -> 
stage: patch review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:37:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 02:37:48 +0000
Subject: [issue8710] test_xpickle: compat tests: workaround for missing
	test_support
In-Reply-To: <1273834557.81.0.420477221669.issue8710@psf.upfronthosting.co.za>
Message-ID: <1290911868.16.0.0724460547493.issue8710@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think this is a distro bug.  Debian for example does not ship tests but has test.__init__, regrtest and test_support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8710>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:39:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 02:39:25 +0000
Subject: [issue4256] optparse/argparse: provide a simple way to get a
	programmatically useful list of options
In-Reply-To: <1225729854.98.0.852900527881.issue4256@psf.upfronthosting.co.za>
Message-ID: <1290911965.85.0.0795422510713.issue4256@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello Filip.  Could you give us a status update on this patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4256>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:39:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 02:39:34 +0000
Subject: [issue9281] Race condition with mkdir/makedirs in distutils2
In-Reply-To: <1279342839.57.0.133468665449.issue9281@psf.upfronthosting.co.za>
Message-ID: <1290911974.14.0.472082938745.issue9281@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

We could backport the new version of the function in our compat module (I?d rather not backport the whole os module), if you think it?s worth it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9281>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:43:05 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 28 Nov 2010 02:43:05 +0000
Subject: [issue9281] Race condition with mkdir/makedirs in distutils2
In-Reply-To: <1279342839.57.0.133468665449.issue9281@psf.upfronthosting.co.za>
Message-ID: <1290912185.22.0.332919146539.issue9281@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I suggest to backport only makedirs() function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9281>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:51:47 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Nov 2010 02:51:47 +0000
Subject: [issue10268] Add --enable-loadable-sqlite-extensions option to
	`configure`
In-Reply-To: <1288544831.28.0.692302384707.issue10268@psf.upfronthosting.co.za>
Message-ID: <1290912707.63.0.612872325075.issue10268@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r86844

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10268>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:56:32 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 28 Nov 2010 02:56:32 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1290912992.7.0.0820522076434.issue3243@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee: jhylton -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Nov 28 03:57:03 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 28 Nov 2010 02:57:03 +0000
Subject: [issue10268] Add --enable-loadable-sqlite-extensions option to
	`configure`
In-Reply-To: <1288544831.28.0.692302384707.issue10268@psf.upfronthosting.co.za>
Message-ID: <1290913023.74.0.272343437385.issue10268@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

About --enable-loadable-sqlite-extensions=no, this behavior also occurs with --with-system-expat=no and --with-system-ffi=no options. Please file a new issue, add me to nosy list and I will attach a patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10268>
_______________________________________

From report at bugs.python.org  Sun Nov 28 04:04:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 03:04:45 +0000
Subject: [issue9621] Graphviz output for 2to3 fixer patterns
In-Reply-To: <1281973199.06.0.194769344976.issue9621@psf.upfronthosting.co.za>
Message-ID: <1290913485.68.0.205946942844.issue9621@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hey Matt, can you give us a status update?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9621>
_______________________________________

From report at bugs.python.org  Sun Nov 28 04:19:14 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 28 Nov 2010 03:19:14 +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: <1290914354.47.0.867667006097.issue10553@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

This looks fairly complete.
I spotted the word "optimze" in there :)
As for the C api, I always cringe when I add an "Ex" function myself, because it feels like I'm spending my last bullet.  What to do if I need yet another parameter later?  ExEx?
For that reason, I have started to use an options structure with a "size" argument at the start more often.  Ugly windows style.
But since these functions haven't changed much for a long time, there is perhaps no need to fret.

I didn't see an "optimize" option to PyZipFile, the original usecase this all sprung out of.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10553>
_______________________________________

From report at bugs.python.org  Sun Nov 28 04:22:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 03:22:26 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>>> float('?')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: ?

>>> float('42?')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError

With the attached patch, float-error.diff


>>> float('?')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for float(): ?
>>> float('42?')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for float(): 42?

Note that the proposed patch also has an effect of disallowing non-ascii digits in float() constructor.

Before the patch:

>>> float('????.??')
1234.56

After the patch:

>>> float('????.??')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: ????.??

I am not sure, whether support for non-ascii digits in float() constructor is worth maintaining.  (Anyone knows whether Arabic numbers are written right to left or left to right?  What is the proper decimal point character?)

Also, I don't think users expect UnicodeEncodeError from float() or int().

Before the patch:

>>> float('\uffff')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'decimal' codec can't encode character '\uffff' in position 0: invalid decimal Unicode string


After the patch:

>>> float('\uffff')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: could not convert string to float: ?

----------
components: Interpreter Core
files: float-error.diff
keywords: patch
messages: 122612
nosy: belopolsky, ezio.melotti, haypo, mark.dickinson
priority: normal
severity: normal
stage: unit test needed
status: open
title: Malformed error message from float()
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19848/float-error.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 04:24:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Nov 2010 03:24:57 +0000
Subject: [issue10558] non-standard processing of several configure options
	ignores "=no"
In-Reply-To: <1290914697.11.0.0589009147808.issue10558@psf.upfronthosting.co.za>
Message-ID: <1290914697.11.0.0589009147808.issue10558@psf.upfronthosting.co.za>


New submission from Ned Deily <nad at acm.org>:

[From Issue10268]

The configure to Makefile option processing for a few options is non-standard.  For example, --enable-loadable-sqlite-extensions=no is treated the same as --enable-loadable-sqlite-extensions or --enable-loadable-sqlite-extensions=yes, contrary to standard Autoconf behavior. Reportedly, this behavior also occurs with --with-system-expat=no and --with-system-ffi=no options.

----------
components: Build
messages: 122613
nosy: Arfrever, ned.deily
priority: normal
severity: normal
stage: needs patch
status: open
title: non-standard processing of several configure options ignores "=no"
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10558>
_______________________________________

From report at bugs.python.org  Sun Nov 28 04:33:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 03:33:36 +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: <1290915216.96.0.30173917123.issue9573@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> ncoghlan
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9573>
_______________________________________

From report at bugs.python.org  Sun Nov 28 04:40:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 03:40:42 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1290915642.74.0.464820166083.issue9584@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Latest patch looks good.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Sun Nov 28 04:42:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 03:42:00 +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: <1290915720.54.0.885405433365.issue9709@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t think we can remove a method.  Can you make a patch with your other suggestion?  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9709>
_______________________________________

From report at bugs.python.org  Sun Nov 28 04:44:05 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Nov 2010 03:44:05 +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: <1290915845.83.0.125019332577.issue9299@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I applied mkdir.diff, 08-07, patch to my current working copy, added version-added and News entry (with credit to Ray Allen) and added Ray Allen to ACKS. Uploaded as mkdirs.tr.diff

I suspect a complete test should include a linux system, but I copied os.py and test_os.py to my WinXP 3.2a3 installation and in IDLE ran
>>> from test.test_os import test_main as f; f()

The mkdir tests passed, but for what is is worth, 3 others did not:
(I have no interpretation or comment on these ;-)
======================================================================
ERROR: test_CTRL_BREAK_EVENT (test.test_os.Win32KillTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Programs\Python32\lib\test\test_os.py", line 1137, in test_CTRL_BREAK_EVENT
    self._kill_with_event(signal.CTRL_BREAK_EVENT, "CTRL_BREAK_EVENT")
  File "C:\Programs\Python32\lib\test\test_os.py", line 1111, in _kill_with_event
    time.sleep(0.5)
WindowsError: [Error 6] The handle is invalid

======================================================================
ERROR: test_link (test.test_os.LinkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Programs\Python32\lib\test\test_os.py", line 906, in test_link
    self._test_link(self.file1, self.file2)
  File "C:\Programs\Python32\lib\test\test_os.py", line 901, in _test_link
    os.link(file1, file2)
AttributeError: 'module' object has no attribute 'link'

======================================================================
ERROR: test_link_bytes (test.test_os.LinkTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Programs\Python32\lib\test\test_os.py", line 910, in test_link_bytes
    bytes(self.file2, sys.getfilesystemencoding()))
  File "C:\Programs\Python32\lib\test\test_os.py", line 901, in _test_link
    os.link(file1, file2)
AttributeError: 'module' object has no attribute 'link'

----------
Added file: http://bugs.python.org/file19849/mkdirs.tr.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9299>
_______________________________________

From report at bugs.python.org  Sun Nov 28 04:59:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 03:59:05 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1290916745.11.0.0906615117931.issue10318@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Attached patch fixes shebangs to use python3 in py3k.

There are a lot of examples that use a bare ?python?; changing all of those would cause merging pains.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Sun Nov 28 04:59:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 03:59:20 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1290916760.87.0.562858581894.issue10318@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19850/env-python3.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:02:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:02:02 +0000
Subject: [issue7982] extend captured_output to simulate different
	stdout.encoding
In-Reply-To: <1266844157.92.0.671833558035.issue7982@psf.upfronthosting.co.za>
Message-ID: <1290916922.13.0.356820230165.issue7982@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
keywords: +easy
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7982>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:02:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:02:10 +0000
Subject: [issue7982] extend captured_output to simulate different
	stdout.encoding
In-Reply-To: <1266844157.92.0.671833558035.issue7982@psf.upfronthosting.co.za>
Message-ID: <1290916930.99.0.91113621907.issue7982@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/issue7982>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:03:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 04:03:52 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1290916760.91.0.589250442193.issue10318@psf.upfronthosting.co.za>
Message-ID: <AANLkTimXM_TvnaF9H5zG0VKoa-_kNJapL+GVEGDs4nOr@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

-    #!/usr/bin/env python
+    #!/usr/bin/env python3
     # -*- coding: UTF-8 -*-

Not strictly related to this issue, but do we want to recommend
redundant encoding cookie in the docs?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:05:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:05:16 +0000
Subject: [issue10318] "make altinstall" installs many files with incorrect
	shebangs
In-Reply-To: <1288926610.35.0.932494150274.issue10318@psf.upfronthosting.co.za>
Message-ID: <1290917116.43.0.39968310496.issue10318@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Good call.  +1 on removing them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10318>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:08:56 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 28 Nov 2010 04:08:56 +0000
Subject: [issue10558] non-standard processing of several configure options
	ignores "=no"
In-Reply-To: <1290914697.11.0.0589009147808.issue10558@psf.upfronthosting.co.za>
Message-ID: <1290917336.97.0.834082440679.issue10558@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

I'm attaching the patch for py3k branch. A part of this patch could be applied also in 2.7 and 3.1 branches.

----------
keywords: +patch
Added file: http://bugs.python.org/file19851/python-3.2-issue10558.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10558>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:12:09 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 28 Nov 2010 04:12:09 +0000
Subject: [issue10558] non-standard processing of several configure options
	ignores "=no"
In-Reply-To: <1290914697.11.0.0589009147808.issue10558@psf.upfronthosting.co.za>
Message-ID: <1290917529.98.0.552672558115.issue10558@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
stage: needs patch -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10558>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:12:11 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 28 Nov 2010 04:12:11 +0000
Subject: [issue10558] non-standard processing of several configure options
	ignores "=no"
In-Reply-To: <1290914697.11.0.0589009147808.issue10558@psf.upfronthosting.co.za>
Message-ID: <1290917531.85.0.00550230777428.issue10558@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

2.7 branch: --with-system-expat and --with-system-ffi
3.1 branch: --with-system-ffi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10558>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:12:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:12:33 +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: <1290917553.78.0.420864364818.issue9299@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

All tests pass on my Debian.

(I suggest removing the unnecessary backslash before committing.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9299>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:18:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:18:53 +0000
Subject: [issue6454] Add "example" keyword argument to optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1290917933.79.0.513104677497.issue6454@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This may be interesting for argparse too.

----------
nosy: +bethard, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:23:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:23:36 +0000
Subject: [issue1513299] Clean up usage of map() in the stdlib
Message-ID: <1290918216.7.0.14961797839.issue1513299@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/issue1513299>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:24:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:24:22 +0000
Subject: [issue1043706] External storage protocol for large email messages
Message-ID: <1290918262.22.0.47403629658.issue1043706@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/issue1043706>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:27:28 2010
From: report at bugs.python.org (Anurag Chourasia)
Date: Sun, 28 Nov 2010 04:27:28 +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: <1290918448.75.0.0303281749969.issue10555@psf.upfronthosting.co.za>


Anurag Chourasia <anurag.chourasia at gmail.com> added the comment:

Hi Stefen,

I looked at http://bugs.python.org/issue941346 and I believe it might help my case, but, the changes made against that issue  are not clear to me.

It appears that for Python 2.7, the changes were made in the following 5 files

1. configure.in
2. Lib/distutils/command/build_ext.py
3. Makefile.pre.in
4. Modules/ld_so_aix.in
5. Modules/ld_so_aix

The changes done in the file 5 are not clear to me....the source code that I downloaded from python.org still does not contain those changes. I am not sure if the changes were accepted to be in the release version but if someone could send me the changes then I am willing to try those out on my AIX Machine in question and share the results.

Please guide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10555>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:29:34 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Nov 2010 04:29:34 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290918574.81.0.516337521387.issue10557@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I think float() should support non-ascii digits but I agree that it would be better to avoid UnicodeErrors and convert them to ValueErrors so that

>>> float('????.??')
1234.56

and

>>> float('?')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: invalid literal for float(): ?

I.e. float should do the C equivalent of:
try:
  s = arg.encode('decimal')
except UnicodeEncodeError:
  raise ValueError('Invalid liter for float(): {}'.format(arg))

Note that int() and Decimal() supports non-ascii chars too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:34:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:34:41 +0000
Subject: [issue9028] test_support.run_unittest cmdline options and arguments
In-Reply-To: <1276866224.2.0.777930943128.issue9028@psf.upfronthosting.co.za>
Message-ID: <1290918881.84.0.561120165555.issue9028@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Closing again, following Michael?s comment.

Re: run_unittest, it?s a very small function mostly obsolete now, I don?t think there are compat rules.  Just don?t use it.

----------
nosy: +eric.araujo
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9028>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:45:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:45:40 +0000
Subject: [issue9234] argparse: aliases for positional arguments (subparsers)
In-Reply-To: <1278965347.63.0.908625805717.issue9234@psf.upfronthosting.co.za>
Message-ID: <1290919540.76.0.33698255594.issue9234@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

It seems to me that this alias functionality should be integrated into the subparsers code, not another action.  Guidelines for patches are at http://www.python.org/dev/patches/  Thanks in advance.

(Complementary idea for another bug report: Automatically recognize unambiguous shortened commands, see for example ?hg d? which expands to ?hg diff?.)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9234>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:49:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:49:09 +0000
Subject: [issue8841] GetoptError strings should be localized
In-Reply-To: <1275007450.32.0.944656023036.issue8841@psf.upfronthosting.co.za>
Message-ID: <1290919749.94.0.250019956007.issue8841@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do you want to provide a patch?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8841>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:49:22 2010
From: report at bugs.python.org (Anurag Chourasia)
Date: Sun, 28 Nov 2010 04:49:22 +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: <1290919762.2.0.434959268829.issue10555@psf.upfronthosting.co.za>


Anurag Chourasia <anurag.chourasia at gmail.com> added the comment:

Just received a message from Benjamin Peterson informing the release of 2.7.1. I will now download that tar ball and it should have sebastian's changes as well. I will update the results of my build process shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10555>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:50:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:50:12 +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: <1290919812.17.0.293800039339.issue8040@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8040>
_______________________________________

From report at bugs.python.org  Sun Nov 28 05:51:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 04:51:50 +0000
Subject: [issue5877] Add a function for updating URL query parameters
In-Reply-To: <1241011935.05.0.388851858626.issue5877@psf.upfronthosting.co.za>
Message-ID: <1290919910.9.0.944191827978.issue5877@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/issue5877>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:01:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:01:44 +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: <1290920504.82.0.560931113049.issue5863@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Do you want to work on patch?

----------
components: +Extension Modules -IO, Library (Lib)
nosy: +eric.araujo
stage: unit test needed -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:08:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:08:03 +0000
Subject: [issue8214] Add exception logging function to syslog module
In-Reply-To: <1269382333.64.0.598164519082.issue8214@psf.upfronthosting.co.za>
Message-ID: <1290920883.08.0.432567694488.issue8214@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/issue8214>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:11:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:11:16 +0000
Subject: [issue7796] No way to find out if an object is an instance of a
	namedtuple
In-Reply-To: <1264608669.85.0.379125118171.issue7796@psf.upfronthosting.co.za>
Message-ID: <1290921076.23.0.133108311121.issue7796@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +Enhance Object/structseq.c to match namedtuple and tuple	api

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7796>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:18:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:18:40 +0000
Subject: [issue964437] idle help is modal
Message-ID: <1290921520.57.0.51481522333.issue964437@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Making the help window non-modal sounds like a great change to me.

----------
nosy: +eric.araujo
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue964437>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:22:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:22:54 +0000
Subject: [issue4613] Can't figure out where SyntaxError: can not delete
	variable 'x' referenced in nested scope us coming from in
	python shows no traceback
In-Reply-To: <1228851366.47.0.778416460497.issue4613@psf.upfronthosting.co.za>
Message-ID: <1290921774.17.0.219573664875.issue4613@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4613>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:26:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:26:26 +0000
Subject: [issue4343] New function in Tkinter.py: setup_master
In-Reply-To: <1227011959.0.0.968897886388.issue4343@psf.upfronthosting.co.za>
Message-ID: <1290921986.17.0.865355278788.issue4343@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> gpolo
keywords: +needs review
stage:  -> commit review
type:  -> feature request
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4343>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:31:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:31:53 +0000
Subject: [issue5043] get_msvcr() returns None rather than []
In-Reply-To: <1232819450.01.0.0863165056727.issue5043@psf.upfronthosting.co.za>
Message-ID: <1290922313.41.0.624049309702.issue5043@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you explain what the bug is?  Thanks in advance.

----------
assignee:  -> eric.araujo
components: +Distutils, Distutils2 -Build
nosy: +eric.araujo
versions: +3rd party, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5043>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:32:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:32:35 +0000
Subject: [issue5209] nntplib needs updating to RFC 3977
In-Reply-To: <1234294968.88.0.213485994333.issue5209@psf.upfronthosting.co.za>
Message-ID: <1290922355.98.0.906209740185.issue5209@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +jelie, pitrou
versions: +Python 3.2 -Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5209>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:36:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:36:52 +0000
Subject: [issue4214] no extension debug info with msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <1290922612.83.0.816344210955.issue4214@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What are pdb files, by the way?

----------
components: +Distutils2
nosy: +eric.araujo
versions: +3rd party, Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4214>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:37:16 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Nov 2010 05:37:16 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290922636.03.0.0915414949505.issue10557@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

FWIW the UnicodeError comes from PyUnicode_EncodeDecimal (unicodeobject.c:6212) and the "ValueError: could not convert string to float" with the buggy ? comes from PyOS_string_to_double (pystrtod.c:316).  Maybe PyOS_string_to_double should be fixed to display the string correctly, but I don't know what will be affected from that (and if it will make things worse or better).  The UnicodeError can be fixed in PyFloat_FromString (floatobject.c:174).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:40:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:40:30 +0000
Subject: [issue6887] executables in lib use /usr/bin/env python, not python3
In-Reply-To: <1252695876.75.0.468012953798.issue6887@psf.upfronthosting.co.za>
Message-ID: <1290922830.2.0.152927208159.issue6887@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> "make altinstall" installs many files with incorrect shebangs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6887>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:43:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:43:47 +0000
Subject: [issue9264] trace.py documentation is incomplete
In-Reply-To: <1279167085.71.0.92983376648.issue9264@psf.upfronthosting.co.za>
Message-ID: <1290923027.29.0.157680551713.issue9264@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: terry.reedy -> eric.araujo
status: open -> pending
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9264>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:48:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:48:20 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

>From the docs@ mailing list:

?Tutorial 2.1.1: name 'sys' is not defined

When the student tells python to evaluate sys.argv[0] as described, she gets the following error: name 'sys' is not defined?

Imports have not been introduced yet, so I propose this simple change:

-left in ``sys.argv`` for  the command or module to handle.
+left in ``sys.argv`` for  the command or module to handle.  You need to
+execute ``import sys`` before you can reference ``sys.argv``.

I?m not committing directly because I?d like feedback: Is the wording okay for the beginning of the tutorial?

----------
assignee: eric.araujo
components: Documentation
keywords: needs review, patch
messages: 122635
nosy: eric.araujo
priority: normal
severity: normal
stage: patch review
status: open
title: NameError in tutorial/interpreter
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Sun Nov 28 06:48:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 28 Nov 2010 05:48:29 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1290923309.73.0.775649898684.issue10559@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Sun Nov 28 07:03:44 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Nov 2010 06:03:44 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1290924224.86.0.439777561799.issue10559@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

What about "In order to use ``sys.argv`` you have to import the :mod:`sys` module doing ``import sys``.".
"reference" sounds weird to me, and imho saying "import the module" is ok even if imports have not been introduced yet. If the user doesn't understand what "importing a module" means he can just execute the command as is.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Sun Nov 28 07:11:37 2010
From: report at bugs.python.org (Ron Adam)
Date: Sun, 28 Nov 2010 06:11:37 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1290924697.08.0.762502084647.issue2001@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

Thanks for the review and style edits ?ric.  I think it's a much better patch with the changes and suggestions from you, Nick, and  Alexander.

I'll check my white space settings.  Thanks for noticing it.

As Nick points out, parts of the patch was written with the idea of having the text server as a separate module.  So I made the example in it runnable as a doctest, as if it was going to be a public module.  As Nick also suggests, the server example could be changed to a comment, and it could be condensed quite a bit by removing the command line doctest formatting/tutorial style and replacing it with a nice single example as it would be seen in a file.

Originally I was  hopping to get a complete rewrite into python 3.0. Then it was suggested I try for 2.6.  While doing that, I went way overboard with making it have plug in html formatters and converters. (Some people suggested they wanted that). In the end, I found that these parts in this patch, (and some additional stuff), can be used without the complete rewrite.  And these parts really help make pydoc much more usable.  Not the document generating parts.  Maybe we can move some of those parts to a pydoc_lib.py file at some point, and have an API for creating document generators rather than try to have pydoc do everything it self.

As you noticed, I used an html style that is similar to what was in the other parts of pydoc.  And yes, it's not pretty.  As Nick points out, "those things should be fixed", and I agree.  But I feel it should be a separate patch.  That will make it easier to review and keep the html code changes separate from any functional changes.  Hopefully, we can update the html so it makes good use of the style sheet at that time as well.  ie... a lot of the html code will probably be changed in the near future, so don't be too nit-picky about it right now.

Other things that I hope to add later, are to have more references in the topics and keywords be links.  That one is fairly easy. The function to do that is already in pydoc.  Add line numbers and color output to the file view page.  And eventually look into detecting and using reST to enhance both the html and text output in docstrings, topics, and keywords.

As for the imports that arn't at the top of the module, I followed the usage that was in pydoc.  It seemed to me that there was probably a conscious reason for why it done that way.

I can't find anything I disagree with. 

   Ron

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Sun Nov 28 07:37:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Nov 2010 06:37:26 +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: <1290926246.08.0.458673865522.issue9299@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

\ at end of os.py addition

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9299>
_______________________________________

From report at bugs.python.org  Sun Nov 28 08:53:57 2010
From: report at bugs.python.org (Luke Kenneth Casson Leighton)
Date: Sun, 28 Nov 2010 07:53:57 +0000
Subject: [issue5043] get_msvcr() returns None rather than []
In-Reply-To: <1232819450.01.0.0863165056727.issue5043@psf.upfronthosting.co.za>
Message-ID: <1290930837.78.0.802470939072.issue5043@psf.upfronthosting.co.za>


Luke Kenneth Casson Leighton <lkcl at lkcl.net> added the comment:

i'm really sorry, eric, but the decision to ban me from interacting with python developers for 18 months+ has left me with zero working knowledge of many of these complex issues which i was heavily and actively involved in at the time, and could have answered immediately.

the opportunity to interact with me and to move the mingw32 port forward was "at the time", not 18+ months later.

i've since *removed* the highly complex development environment which was tricky as hell to set up (mingw32 cross compiler, mingw32 native compiler, python, native python, wine, MSYS under wine, python-win32 under wine) because it was declared that the work being carried out was worthless.

i'll have to leave it to roumen to answer this one.

l.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5043>
_______________________________________

From report at bugs.python.org  Sun Nov 28 09:54:23 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 28 Nov 2010 08:54:23 +0000
Subject: [issue10496] "import site failed" when Python can't find home
	directory
In-Reply-To: <1290398281.89.0.568058332092.issue10496@psf.upfronthosting.co.za>
Message-ID: <1290934463.94.0.630816251333.issue10496@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

I tried running bug.c using the svn head of python and got this:

Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: Unable to get the locale encoding
LookupError: no codec search functions registered: can't find encoding
Aborted

----------
nosy: +xuanji

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10496>
_______________________________________

From report at bugs.python.org  Sun Nov 28 09:56:13 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Sun, 28 Nov 2010 08:56:13 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290934573.54.0.0479091810757.issue10500@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

I checked both the 3.1.2 and 3.1.3 x86 msi installers on windows xp machine using Avast and it didn't find anything.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 10:10:39 2010
From: report at bugs.python.org (Steven Bethard)
Date: Sun, 28 Nov 2010 09:10:39 +0000
Subject: [issue6454] Add "example" keyword argument to optparse constructor
In-Reply-To: <1247183660.32.0.307989578437.issue6454@psf.upfronthosting.co.za>
Message-ID: <1290935439.72.0.663380595418.issue6454@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

With argparse, you can specify formatter_class= RawDescriptionHelpFormatter and then format things however you want in the description.

http://docs.python.org/dev/library/argparse.html#formatter-class

So I think there's no need for this in argparse.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6454>
_______________________________________

From report at bugs.python.org  Sun Nov 28 10:25:22 2010
From: report at bugs.python.org (=?utf-8?q?Julien_=C3=89LIE?=)
Date: Sun, 28 Nov 2010 09:25:22 +0000
Subject: [issue5209] nntplib needs updating to RFC 3977
In-Reply-To: <1234294968.88.0.213485994333.issue5209@psf.upfronthosting.co.za>
Message-ID: <1290936322.09.0.39531917492.issue5209@psf.upfronthosting.co.za>


Julien ?LIE <julien at trigofacile.com> added the comment:

> +        Whether posting is allowed depends on whether it
> +        is included in results of CAPABILITIES; see
> +        RFC 3977 section 5.1.2.
> +        Deprecated:
>          If the response code is 200, posting is allowed;
>          if it 201, posting is not allowed."""

200 and 201 do not have a deprecated meaning in RFC 3977.

200 = posting may be available during the session (possibly after commands like STARTTLS or AUTHINFO have been successfully sent)
201 = posting will never be allowed in the session, whatever the user does.

I agree that the only way to know whether posting is allowed at a given time during the session is to send CAPABILITIES and to look for POST.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5209>
_______________________________________

From report at bugs.python.org  Sun Nov 28 11:02:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 28 Nov 2010 10:02:19 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290938539.24.0.064586769023.issue10500@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

At the very least we'd need to know what virus scanner, and what version of it, the OP used.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 11:02:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 28 Nov 2010 10:02:22 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290938542.13.0.681952888775.issue10500@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file19844/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 11:14:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 28 Nov 2010 10:14:07 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1290939247.77.0.216563032406.issue10544@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

While the behavior is confusing, I don't think yield inside comprehensions should be disallowed.  Rather, the fact that comprehensions have their own scope should be stated clearer.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Sun Nov 28 11:37:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 28 Nov 2010 10:37:58 +0000
Subject: [issue10507] Check well-formedness of reST markup within "make
	patchcheck"
In-Reply-To: <1290443371.49.0.836951290391.issue10507@psf.upfronthosting.co.za>
Message-ID: <1290940678.09.0.965974567517.issue10507@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

rst2html doesn't help, since it doesn't recognize Sphinx' and Python's own markup extensions.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10507>
_______________________________________

From report at bugs.python.org  Sun Nov 28 11:39:10 2010
From: report at bugs.python.org (Xuanji Li)
Date: Sun, 28 Nov 2010 10:39:10 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1290940750.28.0.204462685398.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Hi, attached is a ported version of the patch that applies against py3k.

----------
nosy: +xuanji
Added file: http://bugs.python.org/file19852/issue_3243_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Nov 28 11:40:21 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 28 Nov 2010 10:40:21 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290940821.13.0.527502971647.issue10500@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Checked python-3.1.2.msi with f-prot, no viruses. Checked download
with firefox (which claims to do a short virus scan), no results.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 11:49:11 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 28 Nov 2010 10:49:11 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290941351.93.0.428856960939.issue10557@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/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 11:59:13 2010
From: report at bugs.python.org (Ray.Allen)
Date: Sun, 28 Nov 2010 10:59:13 +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: <1290941953.22.0.477735921838.issue9299@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Thanks for Terry's addition to the patch! 

On my python3.2a3 on windows(also copied os.py and test_os.py to the installation), I only get the tow "os.link" errors. And this is because the python3.2a3 hasn't the "os.link" function, and the test.LinkTests in test_os.py is added later after python3.2a3, at r86733.

I don't know Why is there a WindowsError in time.sleep(), but I cannot reproduce this Error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9299>
_______________________________________

From report at bugs.python.org  Sun Nov 28 12:07:10 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 28 Nov 2010 11:07:10 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290942430.32.0.894642338643.issue10500@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

No problems when I downloaded and installed on Windows XP.
I scanned using the Symantec EndPoint protection and no threats found.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 12:17:58 2010
From: report at bugs.python.org (Carlo Bramini)
Date: Sun, 28 Nov 2010 11:17:58 +0000
Subject: [issue10560] Fixes for Windows sources
In-Reply-To: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>
Message-ID: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>


New submission from Carlo Bramini <carlo.bramix at libero.it>:

Hello,
I was able to compile latest python sources with MSVC5, by importing and fixing a bit the project workspaces of MSVC6.
During this action I received some messages, so I gave a look to the sources and I would like to suggest the following fixes:

1) in posixmodule.c, I had a warning of constant out of range for secs_between_epochs.
The problem has been solved by applying "i64" suffix as suggested in MSDN for doing correct declaration of 64 bits constants.
While doing this fix, I took this chance for adding support for all currently supported platforms: MSVC, GCC and Watcom.

2) in posixmodule.c, I fixed a bit check_gfax() function:
- Function declaration has been fixed with 'void' in its parameter section (fixes a warning).
- I removed the variable 'checked' and I placed instead the handle to kernel32 module.
- I removed the L-value assignment: all other source codes in Python are already corrected in that manner, this is the last one that needs to be fixed.

3) in posixmodule.c, there is a bug in function Py_GetFileAttributesExW(): it tests for 'gfaxa' but later it uses 'gfaxw'.

4) in dl_nt.c, I fixed function prototypes with "void" (solves a warning).

5) in dl_nt.c, in function _LoadActCtxPointers(), I do not see a good reason for using widechar version of GetModuleHandle, since it just need to retrieve the instance of kernel32.

6) in dynload_win.c, I fixed _Py_ActivateActCtx prototype declaration (solves a warning).

7) in dynload_win.c, I suggest to rename local strcasecmp() to something less dangerous to prototype conflicts.

8) in dynload_win.c, in function _PyImport_GetDynLoadFunc() the first 'cookie' variable is not used, so its declaration has been removed.

I hope you will find this useful.

Sincerely,

Carlo Bramini.

----------
components: Windows
files: python.txt
messages: 122651
nosy: Carlo_Bramini
priority: normal
severity: normal
status: open
title: Fixes for Windows sources
Added file: http://bugs.python.org/file19853/python.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10560>
_______________________________________

From report at bugs.python.org  Sun Nov 28 12:38:56 2010
From: report at bugs.python.org (Xavier de Gaye)
Date: Sun, 28 Nov 2010 11:38:56 +0000
Subject: [issue10561] The pdb command 'clear bpnumber' may delete more than
	one breakpoint
In-Reply-To: <1290944336.84.0.679625072616.issue10561@psf.upfronthosting.co.za>
Message-ID: <1290944336.84.0.679625072616.issue10561@psf.upfronthosting.co.za>


New submission from Xavier de Gaye <xdegaye at gmail.com>:

Description:
------------
1. When deleting a single breakpoint, all the breakpoints located on
   the line of this breakpoint are also deleted. See the test case
   below.

2. The pdb 'clear' command documentation does not mention that all the
   breakpoints on a line can be deleted with the command:

        clear filename:lineno

See the proposed bdb patch and documentation patch below.


Test case:
----------
#####   File foobar.py   #####
def main():
    pass

if __name__ == '__main__':
    main()
#####   Test case   #####
xavier$ /usr/local/bin/python2.7
Python 2.7 (r27:82500, Jul 13 2010, 21:30:27)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pdb, foobar
>>> pdb.run('foobar.main()')
> <string>(1)<module>()
(Pdb) break foobar.main
Breakpoint 1 at /home/xavier/tmp/foobar.py:1
(Pdb) break foobar.main
Breakpoint 2 at /home/xavier/tmp/foobar.py:1
(Pdb) break
Num Type         Disp Enb   Where
1   breakpoint   keep yes   at /home/xavier/tmp/foobar.py:1
2   breakpoint   keep yes   at /home/xavier/tmp/foobar.py:1
(Pdb) clear 1
Deleted breakpoint 1
(Pdb) break
(Pdb)
#########################


Patch:
------
Index: Doc/library/pdb.rst
===================================================================
--- Doc/library/pdb.rst	(revision 86836)
+++ Doc/library/pdb.rst	(working copy)
@@ -239,7 +239,8 @@
    Temporary breakpoint, which is removed automatically when it is first hit.  The
    arguments are the same as break.
 
-cl(ear) [*bpnumber* [*bpnumber ...*]]
+cl(ear) [*filename:lineno* | *bpnumber* [*bpnumber ...*]]
+   With a *filename:lineno* argument, clear all the breakpoints at this line.
    With a space separated list of breakpoint numbers, clear those breakpoints.
    Without argument, clear all breaks (but first ask confirmation).
 
Index: Lib/bdb.py
===================================================================
--- Lib/bdb.py	(revision 86836)
+++ Lib/bdb.py	(working copy)
@@ -250,6 +250,12 @@
             list.append(lineno)
         bp = Breakpoint(filename, lineno, temporary, cond, funcname)
 
+    def prune_breaks(self, filename, lineno):
+        if (filename, lineno) not in Breakpoint.bplist:
+            self.breaks[filename].remove(lineno)
+        if not self.breaks[filename]:
+            del self.breaks[filename]
+
     def clear_break(self, filename, lineno):
         filename = self.canonic(filename)
         if not filename in self.breaks:
@@ -261,10 +267,7 @@
         # pair, then remove the breaks entry
         for bp in Breakpoint.bplist[filename, lineno][:]:
             bp.deleteMe()
-        if (filename, lineno) not in Breakpoint.bplist:
-            self.breaks[filename].remove(lineno)
-        if not self.breaks[filename]:
-            del self.breaks[filename]
+        self.prune_breaks(filename, lineno)
 
     def clear_bpbynumber(self, arg):
         try:
@@ -277,7 +280,8 @@
             return 'Breakpoint number (%d) out of range' % number
         if not bp:
             return 'Breakpoint (%d) already deleted' % number
-        self.clear_break(bp.file, bp.line)
+        bp.deleteMe()
+        self.prune_breaks(bp.file, bp.line)
 
     def clear_all_file_breaks(self, filename):
         filename = self.canonic(filename)
===================================================================

----------
components: Library (Lib)
messages: 122652
nosy: xdegaye
priority: normal
severity: normal
status: open
title: The pdb command 'clear bpnumber' may delete more than one breakpoint
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10561>
_______________________________________

From report at bugs.python.org  Sun Nov 28 12:52:33 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 28 Nov 2010 11:52:33 +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: <1290945153.12.0.207408298863.issue9709@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Thinking about it, declaring PyMODINIT_FUNC as void would be a huge
step backwards. Using PyMODINIT_FUNC is the correct way of doing things.
The current situation punishes developers who actually read the docs.

If a C module stops working because of the change, _all_ the maintainer
has to do is change a single line in the sources. PyMODINIT_FUNC is
nearly 10 years old, so I think this is not too much to ask.


May I suggest deprecating get_export_symbols() for these reasons:

  1) The docstring is incorrect: The function does not 'either
     use export_symbols or "PyInit_" + module_name'. It forcibly
     adds PyInit_" + module_name', if it isn't already present in
     export_symbols.

  2) PyMODINIT_FUNC - which is nearly 10 years old - has obsoleted
     this function.

  3) Developers who do the right thing are punished, since they have
     to investigate the warning.



It is also possible to leave the function (see initfunc2.patch). Then
again, on its own get_export_symbols() is practically useless.

----------
Added file: http://bugs.python.org/file19854/initfunc2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9709>
_______________________________________

From report at bugs.python.org  Sun Nov 28 13:30:03 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 28 Nov 2010 12:30:03 +0000
Subject: [issue8710] test_xpickle: compat tests: workaround for missing
	test_support
In-Reply-To: <1273834557.81.0.420477221669.issue8710@psf.upfronthosting.co.za>
Message-ID: <1290947403.75.0.681830297611.issue8710@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Right, Debian's solution is quite reasonable. Closing as wont_fix.

----------
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8710>
_______________________________________

From report at bugs.python.org  Sun Nov 28 13:54:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 28 Nov 2010 12:54:25 +0000
Subject: [issue10560] Fixes for Windows sources
In-Reply-To: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>
Message-ID: <1290948865.77.0.00569842288208.issue10560@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> loewis
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10560>
_______________________________________

From report at bugs.python.org  Sun Nov 28 14:09:33 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Sun, 28 Nov 2010 13:09:33 +0000
Subject: [issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you
	paste something.
In-Reply-To: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>
Message-ID: <1290949773.06.0.635020365072.issue10537@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Ned: I was thinking of Issue6075

The patch in that issue needs work, IIRC I was pretty sure at the time that the patch was too large and changed more code that it should have.

Sadly enough I have barely had time to do any open-source work at all the last couple of weeks, I should have some time before the end of the year...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10537>
_______________________________________

From report at bugs.python.org  Sun Nov 28 14:57:07 2010
From: report at bugs.python.org (Carlo Bramini)
Date: Sun, 28 Nov 2010 13:57:07 +0000
Subject: [issue10560] Fixes for Windows sources
In-Reply-To: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>
Message-ID: <1290952627.43.0.339770619906.issue10560@psf.upfronthosting.co.za>


Carlo Bramini <carlo.bramix at libero.it> added the comment:

According to the instructions received at #python-dev, I'm posting a new patch with the same fixes made on the most recent SVN sources (py3k).
Actually the new patch does not include the fixes made on the GetFileAttributesEx wrappers since they have been removed in the SVN sources; however I would like to remember that removing that code will also break support for Windows 98 and Windows ME: it's true that they have it but only ASCII version is working.

Sincerely,

Carlo Bramini.

----------
Added file: http://bugs.python.org/file19855/python-svn.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10560>
_______________________________________

From report at bugs.python.org  Sun Nov 28 15:12:52 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 28 Nov 2010 14:12:52 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290953572.72.0.728239663254.issue10500@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Scanning with Microsoft Security Essentials says "no threat detected".

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 15:18:40 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Nov 2010 14:18:40 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1290953920.45.0.991142119699.issue10544@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think I can probably fix it, but it's debatable whether it should be done, since it'd make list comps more of "quasi" functions.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Sun Nov 28 15:34:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 14:34:27 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1290954867.76.0.153657380885.issue5211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> In my opinion, 2.6.6 was faulty in the float + xint case, for the same
> reasons as above, and 2.7 is faulty in both float + xint and complex +
> xint.

Well, I disagree:  Python is behaving as designed and documented in these cases.  If you want to argue that the *design* decisions are the wrong ones, then I'd suggest opening a discussion on the python-ideas mailing list, where more people are likely to get involved---this tracker isn't really the right place for that sort of discussion.

Leaving complex out of the mix for the moment, it sounds to me as though you'd like, e.g.,

<float> + <subclass of int>

to call the int subclass's __radd__ method (if it exists) before calling the float's __add__ method.  Is that correct?

Or are you suggesting that float's __add__ method shouldn't accept instances of subclasses of int at all?  (i.e., that float.__add__ should return NotImplemented when given an instance of xint).

In the first case, you need to come up with general semantics that would give you the behaviour you want for float and xint---e.g., when given numeric objects x and y, what general rule should Python apply to decide whether to call x.__add__ or y.__radd__ first?

In the second case, I'd argue that you're going against the whole idea of object-oriented programming; by making xint a subclass of int, you're declaring that its instances *are* 'ints' in a very real sense, so it's entirely reasonable for float's __add__ method to accept them.

In either case, note that Python 2.x is not open for behaviour changes, only for bugfixes.  Since this isn't a bug (IMO), such changes could only happen in 3.x.

Please take further discussion to the python-ideas mailing list.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

From report at bugs.python.org  Sun Nov 28 15:43:05 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 28 Nov 2010 14:43:05 +0000
Subject: [issue1710703] zipfile.ZipFile behavior inconsistent.
Message-ID: <1290955385.93.0.616472632219.issue1710703@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Please fix this patch to raise BadZipFile instead of BadZipfile. See http://docs.python.org/dev/library/zipfile.html?highlight=zipfile#zipfile.BadZipfile. The use of the class name BadZipfile is deprecated. The class name BadZipFile is prefered.

----------
nosy: +Retro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1710703>
_______________________________________

From report at bugs.python.org  Sun Nov 28 15:50:23 2010
From: report at bugs.python.org (Stefan Behnel)
Date: Sun, 28 Nov 2010 14:50:23 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290955823.12.0.490870086686.issue10500@psf.upfronthosting.co.za>


Stefan Behnel <scoder at users.sourceforge.net> added the comment:

File checked with ClamAV under Linux, no findings.

----------
nosy: +scoder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 16:19:18 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 28 Nov 2010 15:19:18 +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: <1290957558.0.0.518903978948.issue10562@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

In Python, the letter 'j' denotes the imaginary unit. It would be great if we would follow mathematics in this regard and let the imaginary unit be denoted with an 'i'.

----------
components: Interpreter Core
messages: 122662
nosy: Retro
priority: normal
severity: normal
status: open
title: Change 'j' for imaginary unit into an 'i'
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 16:19:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Nov 2010 15:19:52 +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: <1290957592.58.0.913775027005.issue10562@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> mark.dickinson
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 16:21:27 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 28 Nov 2010 15:21:27 +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: <1290957687.79.0.598751303011.issue10562@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

We follow engineering which uses j.

(I was about to close this as wontfix but Antoine is particularly keen that Mark deals with this issue...)

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 16:36:21 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 28 Nov 2010 15:36:21 +0000
Subject: [issue10547] FreeBSD: wrong value for LDSHARED in sysconfig
In-Reply-To: <1290865671.36.0.14618274941.issue10547@psf.upfronthosting.co.za>
Message-ID: <1290958581.44.0.438540491746.issue10547@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

r86848: backported r85422, as required by the changes in r85358.


Antoine, there are some remaining {LDFLAGS}, two in the Darwin sections,
one in the OpenBSD section.

I think all of those should be removed as well. Do you agree?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10547>
_______________________________________

From report at bugs.python.org  Sun Nov 28 16:47:20 2010
From: report at bugs.python.org (Gerrit Holl)
Date: Sun, 28 Nov 2010 15:47:20 +0000
Subject: [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>


New submission from Gerrit Holl <topjaklont at gmail.com>:

When the time passed to time.ctime is large, it adds a newline:

>>> import time
>>> time.ctime(2<<36)
'Wed Apr  8 17:04:32 6325'
>>> time.ctime(2<<37)
'Wed Jul 14 08:09:04 10680\n'

----------
components: Library (Lib)
messages: 122665
nosy: Gerrit.Holl
priority: normal
severity: normal
status: open
title: Spurious newline in time.ctime
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10563>
_______________________________________

From report at bugs.python.org  Sun Nov 28 16:50:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Nov 2010 15:50:09 +0000
Subject: [issue10547] FreeBSD: wrong value for LDSHARED in sysconfig
In-Reply-To: <1290958581.44.0.438540491746.issue10547@psf.upfronthosting.co.za>
Message-ID: <1290959402.3534.16.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, there are some remaining {LDFLAGS}, two in the Darwin sections,
> one in the OpenBSD section.
> 
> I think all of those should be removed as well. Do you agree?

I didn't want to mess with these things too much. I guess you can try
and we'll see.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10547>
_______________________________________

From report at bugs.python.org  Sun Nov 28 16:50:36 2010
From: report at bugs.python.org (Tom Quaile)
Date: Sun, 28 Nov 2010 15:50:36 +0000
Subject: [issue10564] maths float error
In-Reply-To: <1290959436.5.0.0677880603523.issue10564@psf.upfronthosting.co.za>
Message-ID: <1290959436.5.0.0677880603523.issue10564@psf.upfronthosting.co.za>


New submission from Tom Quaile <tom.quaile at gmail.com>:

Using IDLE 3.2a4
Apologies in advance for probably wasting your time. If I'm wrong, just ignore me. I'm very new to Python. Is this a bug, my processor or me? I'm sending this in as I see it's an alpha release.

If the user supplies 100 as the answer, I would have expected a result of 115 for a 15% tip. I get 114.999999999.

----------
files: tip.py
messages: 122667
nosy: ipcctv
priority: normal
severity: normal
status: open
title: maths float error
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19856/tip.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10564>
_______________________________________

From report at bugs.python.org  Sun Nov 28 16:58:27 2010
From: report at bugs.python.org (Daniel Urban)
Date: Sun, 28 Nov 2010 15:58:27 +0000
Subject: [issue10565] isinstance(x, collections.Iterator) can return True,
	when x isn't iterable
In-Reply-To: <1290959907.04.0.171212908469.issue10565@psf.upfronthosting.co.za>
Message-ID: <1290959907.04.0.171212908469.issue10565@psf.upfronthosting.co.za>


New submission from Daniel Urban <urban.dani+py at gmail.com>:

If the type of x defines __next__, but not __iter__, isinstance(x, collections.Iterator) returns True, but in fact x isn't iterable.

>>> class X:
...     def __next__(self):
...             raise StopIteration()
...
>>> x = X()
>>> isinstance(x, collections.Iterator)
True
>>> issubclass(X, collections.Iterator)
True
>>> list(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'X' object is not iterable

The reason for this is that collections.Iterator.__subclasshook__ checks for a __next__ method, and if finds one, returns True. (The class provides an __iter__ mixin method, so this doesn't cause problems for classes inheriting collections.Iterator.)

A possible solution could be in collections.Iterator.__subclasshook__ checking for both required methods.

----------
components: Library (Lib)
messages: 122668
nosy: durban, rhettinger, stutzbach
priority: normal
severity: normal
status: open
title: isinstance(x, collections.Iterator) can return True, when x isn't iterable
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10565>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:03:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 16:03:47 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1290960227.67.0.369946646995.issue5211@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file19832/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:04:00 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 16:04:00 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1290960240.45.0.632329393288.issue5211@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file19828/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:04:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 16:04:10 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1290960250.83.0.218561969096.issue5211@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file19820/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:06:04 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 16:06: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: <1290960364.79.0.490161232692.issue10562@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Glad to oblige. :-)

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:09:31 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 28 Nov 2010 16:09:31 +0000
Subject: [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1290960571.39.0.140476199048.issue10563@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

There's an error in time_ctime where it expects the length of the string to be fixed:

    if (p[24] == '\n')
        p[24] = '\0';

It doesn't count on the year having 5 digits. It should probably say (untested):
    l = len(p);
    if (l > 0 && p[l-1] == '\n')
        p[l-1] = '\0';

I'll whip up a patch and some tests. I'm not sure if the tests will work on platforms other than Linux. I'll see what I can find out about ctime and large values.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10563>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:10:25 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 28 Nov 2010 16:10:25 +0000
Subject: [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1290960625.42.0.366664262231.issue10563@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

That should be strlen(), of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10563>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:12:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 16:12:02 +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: <1290960722.86.0.990237595756.issue10562@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Just to add my own thoughts:  'j' for *a* (not *the* </pedantry>) square root of -1 has, as Michael points out, a history of use in engineering (particularly electrical engineering) and physics.  Personally, I would have preferred 'i' to 'j' here, but changing it now would cause (IMO) gratuitous breakage.  It really doesn't seem a big enough issue to be worth making a fuss about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:12:53 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 28 Nov 2010 16:12:53 +0000
Subject: [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1290960773.32.0.00575714866565.issue10563@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

What platform are you running this on? My Fedora 32 bit system won't support a time_t that large.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10563>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:14:06 2010
From: report at bugs.python.org (Gerrit Holl)
Date: Sun, 28 Nov 2010 16:14:06 +0000
Subject: [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1290960846.05.0.275508399369.issue10563@psf.upfronthosting.co.za>


Gerrit Holl <topjaklont at gmail.com> added the comment:

I'm on a 64bit system (kubuntu lucid lynx)

$ uname -a
Linux sjisjka 2.6.32-25-generic #45-Ubuntu SMP Sat Oct 16 19:52:42 UTC 2010 x86_64 GNU/Linux

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10563>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:17:34 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 28 Nov 2010 16:17:34 +0000
Subject: [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1290961054.88.0.0564889572506.issue10563@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Can you try this diff and see if it solves the problem:

Index: Modules/timemodule.c
===================================================================
--- Modules/timemodule.c        (revision 86848)
+++ Modules/timemodule.c        (working copy)
@@ -639,6 +639,7 @@
     PyObject *ot = NULL;
     time_t tt;
     char *p;
+    Py_ssize_t len;
 
     if (!PyArg_UnpackTuple(args, "ctime", 0, 1, &ot))
         return NULL;
@@ -657,8 +658,10 @@
         PyErr_SetString(PyExc_ValueError, "unconvertible time");
         return NULL;
     }
-    if (p[24] == '\n')
-        p[24] = '\0';
+    len = strlen(p);
+    if (len > 0 && p[len-1] == '\n')
+        /* Remove the trailing newline, if present. */
+        p[len-1] = '\0';
     return PyUnicode_FromString(p);
 }

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10563>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:19:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 16:19:33 +0000
Subject: [issue10564] maths float error
In-Reply-To: <1290959436.5.0.0677880603523.issue10564@psf.upfronthosting.co.za>
Message-ID: <1290961173.92.0.973170606794.issue10564@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/issue10564>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:26:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 16:26:25 +0000
Subject: [issue10564] maths float error
In-Reply-To: <1290959436.5.0.0677880603523.issue10564@psf.upfronthosting.co.za>
Message-ID: <1290961585.95.0.758222592283.issue10564@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I get 114.999999999.

How many '9's are there on what you're getting?  If you really get '114.999999999' then something surprising is happening.  If, on the other hand, you get '114.99999999999999', then it's all as expected. :-)

The issue is one that affects the vast majority of popular programming languages, namely that numbers are stored internally in binary, so a number like 1.15 isn't exactly representable---you end up storing a (very good) approximation to 1.15 instead.  And then when you multiply by 100, you end up with a (very good) approximation to 115.0.

I highly recommend reading the floating-point section of the Python tutorial for an explanation of what's going on under the hood.

http://docs.python.org/dev/py3k/tutorial/floatingpoint.html

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10564>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:28:22 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Sun, 28 Nov 2010 16:28:22 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290961702.83.0.599925274768.issue10500@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

VirusTotal says it is clean.

http://www.virustotal.com/file-scan/report.html?id=ca802f144a7e8268a773fa2567fecb0a1d792c62c00f751f27d103a263352113-1290961377

I suggest to close this issue.

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:36:46 2010
From: report at bugs.python.org (Gerrit Holl)
Date: Sun, 28 Nov 2010 16:36:46 +0000
Subject: [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1290962206.72.0.218857434497.issue10563@psf.upfronthosting.co.za>


Gerrit Holl <topjaklont at gmail.com> added the comment:

Yes, this solves the issue:

$ ./python 
Python 3.1.3 (r313:86834, Nov 28 2010, 17:34:23) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import time
>>> time.ctime(2<<40)
'Fri Apr 10 03:12:32 71654'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10563>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:36:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 16:36:59 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290962219.95.0.443046006475.issue10557@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I am not sure, whether support for non-ascii digits in float()
> constructor is worth maintaining.

I'd be very happy to drop such support.  If you allow alternative digit sets, trying to work out exactly what should be supported and what shouldn't gets very messy;  it's even worse for int(), where bases > 10 have to be taken into account.

> (Anyone knows whether Arabic numbers are written right to left
> or left to right?  What is the proper decimal point character?)

Well, judging by the chocolate packaging I saw recently, they're written left to right (so presumably if you're reading right-to-left, you see the units first, then the tens, etc., which always struck me as the 'right' way to write things in the first place :-).  No idea about the proper decimal point character, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:37:18 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 28 Nov 2010 16:37:18 +0000
Subject: [issue5043] get_msvcr() returns None rather than []
In-Reply-To: <1232819450.01.0.0863165056727.issue5043@psf.upfronthosting.co.za>
Message-ID: <1290962238.13.0.291244445331.issue5043@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

a) NoneType object is not iterable. If the function don't return empty list later distutil will fail on the lines like  libraries.extend(self.dll_libraries)

b) method for detection of a msvc runtime is not correct. If the method return a library GCC will link to two c-runtimes. Also some function dearation are not visible if is not specified appropriate preprocessor directive.

So I could not found reason this method to exist .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5043>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:42:24 2010
From: report at bugs.python.org (Mark Florisson)
Date: Sun, 28 Nov 2010 16:42:24 +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: <1290962543.45.0.132664091788.issue10566@psf.upfronthosting.co.za>


New submission from Mark Florisson <markflorisson88 at gmail.com>:

Attached is a patch that adds a few features to the Python debugging support for gdb:

- listing of globals
- python breakpoints
- python stepping/stepping over/finishing of frames/running/continuing
- python code execution in the most recent Python frame (relative to the selected frame)

Unit tests are included in Lib/test/test_gdb.py. It should be compatible with both python 3 and python 2 (this is important because libpython.py is also part of the Cython debugger branch, see https://github.com/markflorisson88/cython/blob/master/Cython/Debugger/libpython.py ). Python 2 tests are in that Cython branch.

It would be great if libpython.py could be installed as an actual Python  module instead of a tool, where 'python-gdb.py' would be the actual tool that imports libpython.py. This may remove the need in the future to duplicate files in the Python source distribution and in future versions of Cython. Another good thing about that is that if users don't have python-gdb.py installed properly, or would like to use functionality without having loaded the interpreter in gdb (i.e. 'file python'), they can just do 'python import libpython' in gdb to load the Python support.

I can't assign this issue, but Dave Malcolm (dmalcolm) asked me to assign the issue to him, so I kindly request someone with these capabilities to assign this issue accordingly.

----------
components: Demos and Tools
files: libpython_patch.diff
keywords: patch
messages: 122681
nosy: eggy
priority: normal
severity: normal
status: open
title: gdb debugging support additions (Tools/gdb/libpython.py)
type: feature request
versions: Python 3.2
Added 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  Sun Nov 28 17:45:19 2010
From: report at bugs.python.org (Eric Smith)
Date: Sun, 28 Nov 2010 16:45:19 +0000
Subject: [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1290962719.05.0.957448898253.issue10563@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
components: +Extension Modules -Library (Lib)
keywords: +easy, patch
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10563>
_______________________________________

From report at bugs.python.org  Sun Nov 28 17:47:51 2010
From: report at bugs.python.org (Rafael Villar Burke)
Date: Sun, 28 Nov 2010 16:47:51 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290962871.63.0.12174679478.issue10500@psf.upfronthosting.co.za>


Rafael Villar Burke <pachiburke at gmail.com> added the comment:

Latest AVG Free on windows (9.0.872) says it's clean.

----------
nosy: +Rafael.Villar.Burke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 18:00:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 17:00:09 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290963609.51.0.300256939956.issue10557@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

About Alexander's solution:  might it make more sense to have PyUnicode_EncodeDecimal raise for inputs like this?  I see it as PyUnicode_EncodeDecimal's job to turn the unicode input into usable ASCII (or raise an exception);  it looks like that's not happening here.

Adding MAL to the nosy in case he wants to comment on this.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 18:24:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 17:24:21 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290962219.95.0.443046006475.issue10557@psf.upfronthosting.co.za>
Message-ID: <AANLkTimhKRW5ZBSRjqgJK-fm2o04i3K140o_6x223aP=@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 28, 2010 at 11:37 AM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
>> I am not sure, whether support for non-ascii digits in float()
>> constructor is worth maintaining.
>
> I'd be very happy to drop such support. ?If you allow alternative digit sets, trying to work out exactly what should
> be supported and what shouldn't gets very messy; ?it's even worse for int(), where bases > 10 have to be taken
> into account.
>

I think there is a proposal (if not already in Unicode 6.0) to add
hexadecimal value property to UCD, but I don't think it is right for
int() and float() to depend on UCD in the first place.  If people need
to process exotic decimals, we can expose 'decimal' encoding, however,
translating from code-point to decimal value is trivial - just
subtract the code-point value for zero.

>> (Anyone knows whether Arabic numbers are written right to left
>> or left to right? ?What is the proper decimal point character?)
>
> Well, judging by the chocolate packaging I saw recently, they're written left to right
> (so presumably if you're reading right-to-left, you see the units first, then the tens, etc.,
> which always struck me as the 'right' way to write things in the first place :-).

Did your chocolate packaging use European digits or Arabic-Indic ones?
 Note that they have different bidi properties:

'EN'
>>> unicodedata.bidirectional('\N{ARABIC-INDIC DIGIT ONE}')
'AN'

(I am not sure what 'AN' (Arabic Numeral?) bidi property actually mean.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 18:26:31 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Sun, 28 Nov 2010 17:26:31 +0000
Subject: [issue10560] Fixes for Windows sources
In-Reply-To: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>
Message-ID: <1290965191.6.0.483534859349.issue10560@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

posix_module has to use Py_LL(...)

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10560>
_______________________________________

From report at bugs.python.org  Sun Nov 28 18:27:17 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Sun, 28 Nov 2010 17:27:17 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290965237.26.0.250157744867.issue10500@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

Latest Norton 360 fully updated has it clean; further, File Insight has it marked as Trusted (thousands of Norton users have had the same file installed for over a month with no reported trouble). Seems clean to me.

----------
nosy: +ixokai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 18:33:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 17:33:49 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290965629.76.0.143553032365.issue10557@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Did your chocolate packaging use European digits or Arabic-Indic ones?
> Note that they have different bidi properties:

Good question;  I think it was Arabic-Indic digits, but to be honest I don't remember.  (It wasn't *all* that recently.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 18:34:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 17:34:07 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290963609.51.0.300256939956.issue10557@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=GYQ0CnUogPoFO_N4P+LpfZhVMen6_rQLgt93y@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 28, 2010 at 12:00 PM, Mark Dickinson <report at bugs.python.org> wrote:
>
> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> About Alexander's solution: ?might it make more sense to have PyUnicode_EncodeDecimal raise
> for inputs like this?

No, I think PyOS_string_to_double() can generate better error messages
than  PyUnicode_EncodeDecimal.  It is important to pass losslessly
encoded string to PyOS_string_to_double() for proper error reporting.
 Otherwise, we will have to catch the error in PyFloat_FromString()
just to add the string value to the message and may loose other
information such as the precise location of the offending character.
(AFAICT, we don't make use of it now, but this would be a meaningful
improvement.)

>?I see it as PyUnicode_EncodeDecimal's job to turn the unicode input into usable ASCII
> (or raise an exception); ?it looks like that's not happening here.

UTF-8 is quite usable by PyOS_string_to_double() .  UTF-8 encoder is
extremely fast and will only get faster over time.  In my opinion,
PyUnicode_EncodeDecimal() is either unnecessary or should be exposed
as a codec.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 18:48:48 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 28 Nov 2010 17:48:48 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290966528.93.0.911600804469.issue10557@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> PyUnicode_EncodeDecimal() is either unnecessary or should be exposed
> as a codec.

I'm depending on PyUnicode_EncodeDecimal in cdecimal. In fact, it saved
me quite a bit of trouble. I wouldn't be surprised if other extension
writers use it as well.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 18:51:47 2010
From: report at bugs.python.org (pbnan)
Date: Sun, 28 Nov 2010 17:51:47 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>
Message-ID: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>


New submission from pbnan <piotr at banaszkiewicz.org>:

Python:
Python 2.7 (r27:82500, Oct 20 2010, 03:21:03) 
[GCC 4.5.1] on linux2

Code:
>>> c = u'\u200b'
>>> c.isspace()
False

In both 2.6, 3.1 it works.

http://www.cs.tut.fi/~jkorpela/chars/spaces.html

----------
components: Unicode
messages: 122690
nosy: pbnan
priority: normal
severity: normal
status: open
title: Unicode space character \u200b unrecognised a space
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:01:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 28 Nov 2010 18:01:47 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290963609.51.0.300256939956.issue10557@psf.upfronthosting.co.za>
Message-ID: <4CF29908.40007@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Mark Dickinson wrote:
> 
> Mark Dickinson <dickinsm at gmail.com> added the comment:
> 
> About Alexander's solution:  might it make more sense to have PyUnicode_EncodeDecimal raise for inputs like this?  I see it as PyUnicode_EncodeDecimal's job to turn the unicode input into usable ASCII (or raise an exception);  it looks like that's not happening here.
> 
> Adding MAL to the nosy in case he wants to comment on this.

The purpose of the PyUnicode_EncodeDecimal() API is to convert
Unicode decimal digits to ASCII digits for interpretation by
the other usual functions to convert the ASCII representation to
numbers.

The proposed patch will not work, since it removes the support for
non-ASCII number code points, e.g. Asian number code points.

You might want to replace the error message by something more
related to floats in the float constructor. Note that UnicodeErrors
are subclasses of ValueErrors, so the errors are not unexpected
for number constructors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:05:13 2010
From: report at bugs.python.org (SilentGhost)
Date: Sun, 28 Nov 2010 18:05:13 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>
Message-ID: <1290967513.75.0.914198223967.issue10567@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

It returns False on the latest py3k checkout as well.

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:06:01 2010
From: report at bugs.python.org (SilentGhost)
Date: Sun, 28 Nov 2010 18:06:01 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>
Message-ID: <1290967561.85.0.676553473263.issue10567@psf.upfronthosting.co.za>


Changes by SilentGhost <michael.mischurow+bpo at gmail.com>:


----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:09:25 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 28 Nov 2010 18:09:25 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <4CF29908.40007@egenix.com>
Message-ID: <4CF29ACF.1030006@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

>>>> float('?')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError: could not convert string to float: ?
> 
>>>> float('42?')
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError

Note that fractional Unicode code points are not supported
by the encoding function.  Neither are code points which do
not evaluate to 0-9, e.g. ones that represent numbers
larger than 9.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:11:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 18:11:35 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>
Message-ID: <1290967895.31.0.515748917124.issue10567@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/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:20:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 18:20:52 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>
Message-ID: <1290968452.96.0.268748099721.issue10567@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The category of U-200B was changed in Unicode 4.0.1:

"""
The main new features in Unicode 4.0.1 are the following:
 ...
 * Changed: general category of U+200B ZERO WIDTH SPACE
""" http://unicode.org/versions/Unicode4.0.1/

----------
resolution:  -> invalid
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:23:56 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 28 Nov 2010 18:23:56 +0000
Subject: [issue1710703] zipfile.ZipFile behavior inconsistent.
Message-ID: <1290968636.25.0.670548398025.issue1710703@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not sure what you're referring to, all occurrences of BadZipfile (except for its definition and its documentation) have been removed in py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1710703>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:27:01 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Nov 2010 18:27:01 +0000
Subject: [issue10560] Fixes for Windows sources
In-Reply-To: <1290952627.43.0.339770619906.issue10560@psf.upfronthosting.co.za>
Message-ID: <4CF29EF1.3080305@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> According to the instructions received at #python-dev, I'm posting a
> new patch with the same fixes made on the most recent SVN sources
> (py3k). Actually the new patch does not include the fixes made on the
> GetFileAttributesEx wrappers since they have been removed in the SVN
> sources; however I would like to remember that removing that code
> will also break support for Windows 98 and Windows ME: it's true that
> they have it but only ASCII version is working.

Python has not been supporting Windows 98 anymore for quite some time
now. I don't see the need to support MSVC5, either. Since Windows 2000
isn't supported anymore, either, the LoadActCtxPointers function can
be dropped, and be replaced with a direct call to GetCurrentActCtx.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10560>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:28:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Nov 2010 18:28:17 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290968897.39.0.695827897133.issue10500@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks for the confirmations; closing this report as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:37:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 18:37:43 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <4CF29ACF.1030006@egenix.com>
Message-ID: <AANLkTikhFFj5BHMte8449YDGtJgWjT3H9sX8e_EehH5h@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Issue #10567 demonstrated the problem of relying on the Unicode
database in Python builtins.  Apparently, Unicode does not guarantee
stability of the character categories.   On the other hand, we are
already tied to UCD for the language definition.  Maybe Python should
document the version of Unicode it is using in any given version and
possibly upgrade to Unicode 6.0 should be postponed until the language
moratorium is lifted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:40:40 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Nov 2010 18:40:40 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>
Message-ID: <1290969640.85.0.653887777097.issue10567@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

In 2.6, there was a manually maintained list, probably dating back to before Unicode 4.0. Python uses the following criterion for determining white space characters:

/* Returns 1 for Unicode characters having the bidirectional type
   'WS', 'B' or 'S' or the category 'Zs', 0 otherwise. */

Since r75272, this is generated from the current Unicode database, and should thus be always correct.

Unless you can somehow prove that the criterion should be changed, or that Python computes it incorrectly, I'm closing this report as invalid.

----------
nosy: +loewis
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:51:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Nov 2010 18:51:26 +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: <1290970286.74.0.450305504696.issue9299@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Afaik, those error have nothing to do with this issue. I just included them for completeness in case they were helpful to GB.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9299>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:52:16 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Nov 2010 18:52:16 +0000
Subject: [issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you
	paste something.
In-Reply-To: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>
Message-ID: <1290970336.81.0.787873925685.issue10537@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/issue10537>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:52:17 2010
From: report at bugs.python.org (SilentGhost)
Date: Sun, 28 Nov 2010 18:52:17 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>
Message-ID: <1290970337.63.0.522774622465.issue10567@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

It's not just this character. isspace() is also False for \u200c and \u200d (from the same category). and \u2060, \u2800 and \ufeff

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:54:40 2010
From: report at bugs.python.org (SilentGhost)
Date: Sun, 28 Nov 2010 18:54:40 +0000
Subject: [issue10567] Some unicode space characters are not recognized as a
	space
In-Reply-To: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>
Message-ID: <1290970480.86.0.983468050378.issue10567@psf.upfronthosting.co.za>


Changes by SilentGhost <michael.mischurow+bpo at gmail.com>:


----------
title: Unicode space character \u200b unrecognised a space -> Some unicode space characters are not recognized as a space

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:55:29 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Nov 2010 18:55:29 +0000
Subject: [issue10565] isinstance(x, collections.Iterator) can return True,
	when x isn't iterable
In-Reply-To: <1290959907.04.0.171212908469.issue10565@psf.upfronthosting.co.za>
Message-ID: <1290970529.11.0.955722965389.issue10565@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> A possible solution could be in 
> collections.Iterator.__subclasshook__ 
> checking for both required methods.

That makes sense.  PEP 234 requires
iterators to support both methods.

----------
assignee:  -> rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10565>
_______________________________________

From report at bugs.python.org  Sun Nov 28 19:59:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Nov 2010 18:59:24 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290970337.63.0.522774622465.issue10567@psf.upfronthosting.co.za>
Message-ID: <4CF2A686.6030809@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> It's not just this character. isspace() is also False for \u200c and \u200d (from the same category). and \u2060, \u2800 and \ufeff

What reason do you have to believe that they should be classified as
whitespace, other than the web page you are quoting (which is apparently
out of date, and the fact that Python 2.6 was classifying
them this way, which are also out of date for the very same reason)?

----------
title: Some unicode space characters are not recognized as a space -> Unicode space character \u200b unrecognised a space

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:00:51 2010
From: report at bugs.python.org (SilentGhost)
Date: Sun, 28 Nov 2010 19:00:51 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>
Message-ID: <1290970851.36.0.217263325603.issue10567@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

I'm not quoting anything. Thank you very much.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:03:42 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Nov 2010 19:03:42 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1290971022.16.0.547054342462.issue10544@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This discussion should probably be moved to python-dev.  With tools like Twisted's inlineDefer or the Monocle package, there is a growing need to be able to use yield in complex expressions.  Yet, that goes against the trend toward making lists comps more like genexps and less like sugar for a simple for-loop accumulator.

Guido, do you have any thoughts on the subject?  Mark it a documentation issue or try out Benjamin's fix?

----------
assignee:  -> gvanrossum
nosy: +gvanrossum
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:07:41 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 28 Nov 2010 19:07:41 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290969640.85.0.653887777097.issue10567@psf.upfronthosting.co.za>
Message-ID: <4CF2A879.1040507@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:
> 
> In 2.6, there was a manually maintained list, probably dating back to before Unicode 4.0. 

That's not quite correct: Python 1.6.x - 2.5.x used tables for the
PyUnicode_ISSPACE() function that were created from the Unicode database.
Python 2.6.x introduced a short-cut table for ASCII whitespace, but still
reverted back to the generated tables for non-ASCII code points.

The tables were never manually maintained, but we also did not update
Python for each new Unicode version:

Python 1.6: Unicode 3.0
Python 2.0: Unicode 3.0
Python 2.1: Unicode 3.0
Python 2.2: Unicode 3.0
Python 2.3: Unicode 3.2
Python 2.4: Unicode 3.2
Python 2.5: Unicode 4.1
Python 2.6: Unicode 5.1
Python 2.7: Unicode 5.2

> Python uses the following criterion for determining white space characters:
>
> /* Returns 1 for Unicode characters having the bidirectional type
>    'WS', 'B' or 'S' or the category 'Zs', 0 otherwise. */

This definition has been used since Python 1.6.x.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:10:08 2010
From: report at bugs.python.org (SilentGhost)
Date: Sun, 28 Nov 2010 19:10:08 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290966707.34.0.718684122276.issue10567@psf.upfronthosting.co.za>
Message-ID: <1290971408.29.0.59610367976.issue10567@psf.upfronthosting.co.za>


Changes by SilentGhost <michael.mischurow+bpo at gmail.com>:


----------
nosy:  -SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:10:14 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 28 Nov 2010 19:10:14 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1290971414.92.0.0620817460889.issue3243@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Instead of 
    hasattr(str,'next')

consider using
    isinstance(str, collections.Iterable)

Also consider changing the variable name from the now overly type specific, "str" to something like "source" to indicate the significance of the data, not its type.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:14:45 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 28 Nov 2010 19:14:45 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1290971685.5.0.146186882727.issue10500@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

And I checked both .2 and .3 with McAfee "Nothing found"

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:15:18 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 28 Nov 2010 19:15:18 +0000
Subject: [issue10547] FreeBSD: wrong value for LDSHARED in sysconfig
In-Reply-To: <1290865671.36.0.14618274941.issue10547@psf.upfronthosting.co.za>
Message-ID: <1290971718.06.0.728640391677.issue10547@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

[Antoine]
> I didn't want to mess with these things too much. I guess you can try
> and we'll see.

You're right, it's better not to touch the Darwin stuff.


The 2.7 buildbots are green (including the FreeBSD ones!). I also
tested the patch successfully on OpenBSD 4.5.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10547>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:18:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Nov 2010 19:18:39 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <1290970851.36.0.217263325603.issue10567@psf.upfronthosting.co.za>
Message-ID: <4CF2AB05.6040609@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'm not quoting anything. Thank you very much.

Oops, sorry - I confused you with the OP.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:20:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 19:20:35 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <4CF2A879.1040507@egenix.com>
Message-ID: <AANLkTinUTjbd-FRhjeSiA4XeNaJbQS5Y+y9HeHJRu_9E@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 28, 2010 at 2:07 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> The tables were never manually maintained, but we also did not update
> Python for each new Unicode version:
>
> Python 1.6: Unicode 3.0
> Python 2.0: Unicode 3.0
> Python 2.1: Unicode 3.0
> Python 2.2: Unicode 3.0
> Python 2.3: Unicode 3.2
> Python 2.4: Unicode 3.2
> Python 2.5: Unicode 4.1
> Python 2.6: Unicode 5.1
> Python 2.7: Unicode 5.2
>

Thank you for the summary.  Note that Python reference pages have been
updated even less frequently. [1]  Since Python language and standard
library definitions are now (in 3.x) closely tied to the Unicode
definition, I wonder whether unicodedata.unidata_version should be
more prominently featured in the docs.  (Possibly even included in the
Python CLI banner, but that is probably an overkill.)

[1] http://mail.python.org/pipermail/docs/2010-November/002074.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:31:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 28 Nov 2010 19:31:57 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <4CF2A879.1040507@egenix.com>
Message-ID: <4CF2AE29.3010901@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> In 2.6, there was a manually maintained list, probably dating back to before Unicode 4.0. 
> 
> That's not quite correct: Python 1.6.x - 2.5.x used tables for the
> PyUnicode_ISSPACE() function that were created from the Unicode database.

That used to be the case until r39757, when you made this change:

------------------------------------------------------------------------
r39757 | lemburg | 2005-10-20 21:06:35 +0200 (Do, 20. Okt 2005) | 7 Zeilen
Ge?nderte Pfade:
   M /python/trunk/Objects/unicodectype.c

Enhance the performance of two important Unicode character
type lookups: whitespace and linebreak.

These lookup tables are from the Python 1.6 version with the addition
of the 205F code point which was added as whitespace code point to
Unicode since then.

------------------------------------------------------------------------

In 2.5 and 2.6, there was no table lookup anymore, but a switch
statement. Not sure how you arrived at the code; the commit message
doesn't say (but the wording suggests it was manually computed).
It was not updated in 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:35:13 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 28 Nov 2010 19:35:13 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <4CF2A879.1040507@egenix.com>
Message-ID: <4CF2AEED.7090500@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

It is still strange that the .isspace() property value changed,
since the code point has not changed in the recent Unicode versions:

4.1.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;
5.1.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;
5.2.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;
6.0.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;

based on http://www.unicode.org/Public/<version>/ucd/UnicodeData.txt

True
> python2.5 -c 'print u"\u200b".isspace()'
True
> python2.6 -c 'print u"\u200b".isspace()'
True
> python2.7 -c 'print u"\u200b".isspace()'
False

Looking at the code again: Now I know why...

The tables in unicodectype.c were generated from the Unicode database,
but not by the makeunicodedata.py script. I used a script to generate
those tables for Python 1.6.0 and it seems that they were never updated
since then. Python 2.7 then replaced them with the data from the
makeunicodedata.py script.

That's probably why Martin thought they were manually maintained.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:40:00 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 28 Nov 2010 19:40:00 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <4CF2AEED.7090500@egenix.com>
Message-ID: <4CF2B00C.6010406@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Going back further shows the change:

3.0.1: 200B;ZERO WIDTH SPACE;Zs;0;BN;;;;;N;;;;;
3.2.0: 200B;ZERO WIDTH SPACE;Zs;0;BN;;;;;N;;;;;
4.0.1: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;
4.1.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;
5.1.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;
5.2.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;
6.0.0: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;

Interesting that no one noticed in all these years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 20:42:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 19:42:20 +0000
Subject: [issue10567] Unicode space character \u200b unrecognised a space
In-Reply-To: <4CF2B00C.6010406@egenix.com>
Message-ID: <AANLkTik3WLG+TZ7o-wra0Gp9FqMjgDNGkcy9fe5d3pcS@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 28, 2010 at 2:40 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> Going back further shows the change:
>
> 3.0.1: 200B;ZERO WIDTH SPACE;Zs;0;BN;;;;;N;;;;;
> 3.2.0: 200B;ZERO WIDTH SPACE;Zs;0;BN;;;;;N;;;;;
> 4.0.1: 200B;ZERO WIDTH SPACE;Cf;0;BN;;;;;N;;;;;

Yes, see msg122694 above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10567>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:09:15 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 28 Nov 2010 20:09:15 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290974955.2.0.0115890586382.issue10557@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> (Anyone knows whether Arabic numbers are written right to left or left 
> to right?  What is the proper decimal point character?)

Thousands separator: U+066C
Decimal point: U+066B

?????????? should be: 123,123.12


Wikipedia says that digits are arranged in the usual way, lowest
value digit to the right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:14:56 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 28 Nov 2010 20:14:56 +0000
Subject: [issue8110] subprocess.py doesn't correctly detect Windows machines
In-Reply-To: <1268236633.45.0.419738445411.issue8110@psf.upfronthosting.co.za>
Message-ID: <1290975296.39.0.534165723686.issue8110@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Jeff Hardy just made this change for IronPython 2.7: http://bitbucket.org/ironpython/ironlanguages/changeset/b6bb2a9a7bc5

Any opposition to us matching that so they don't need to patch Lib/subprocess.py?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8110>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:18:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 20:18:46 +0000
Subject: [issue10568] Python and the Unicode Character Database
In-Reply-To: <AANLkTinsUM3Vw4+UPDuiKJntFiLhtNSSHzhKVF9K9bHi@mail.gmail.com>
Message-ID: <AANLkTinsUM3Vw4+UPDuiKJntFiLhtNSSHzhKVF9K9bHi@mail.gmail.com>


New submission from Alexander Belopolsky <alexander.belopolsky at gmail.com>:

Two recently reported issues brought into light the fact that Python
language definition is closely tied to character properties maintained
by the Unicode Consortium. [1,2]  For example, when Python switches to
Unicode 6.0.0 (planned for the upcoming 3.2 release), we will gain two
additional characters that Python can use in identifiers. [3]

With Python 3.1:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1
    ? = 1
      ^
SyntaxError: invalid character in identifier

but with Python 3.2a4:

1

Of course, the likelihood is low that this change will affect any
user, but the change in str.isspace() reported in [1] is likely to
cause some trouble:

[u'A', u'B']

[u'A\u200bB']

While we have little choice but to follow UCD in defining
str.isidentifier(), I think Python can promise users more stability in
what it treats as space or as a digit in its builtins.   For example,
I don't think that supporting

1234.56

is more important than to assure users that once their program
accepted some text as a number, they can assume that the text is
ASCII.

[1] http://bugs.python.org/issue10567
[2] http://bugs.python.org/issue10557
[3] http://www.unicode.org/versions/Unicode6.0.0/#Database_Changes

----------
messages: 122718
nosy: Alexander.Belopolsky
priority: normal
severity: normal
status: open
title: Python and the Unicode Character Database

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10568>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:22:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 20:22:06 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290974955.2.0.0115890586382.issue10557@psf.upfronthosting.co.za>
Message-ID: <AANLkTik3hiOU6=55bbKsx1ioJRm+nQgtDx6P+h=xsYDD@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 28, 2010 at 3:09 PM, Stefan Krah <report at bugs.python.org> wrote:
..
> Decimal point: U+066B

Well, not so fast:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'decimal' codec can't encode character '\u066b' in
position 1: invalid decimal Unicode string

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:25:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 20:25:55 +0000
Subject: [issue10568] Python and the Unicode Character Database
In-Reply-To: <AANLkTinsUM3Vw4+UPDuiKJntFiLhtNSSHzhKVF9K9bHi@mail.gmail.com>
Message-ID: <1290975955.02.0.0692385962868.issue10568@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This was meant as python-dev post, not an issue. (Sent to wrong address by mistake.)

----------
nosy: +belopolsky
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10568>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:28:26 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 28 Nov 2010 20:28:26 +0000
Subject: [issue4214] no extension debug info with msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <1290976106.57.0.012669082935.issue4214@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A .pdb is the "program database" that contain debug info, i.e. the mapping between assembler positions and source lines, the description of data structures, and other things that are necessary to debug a program.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4214>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:30:05 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 28 Nov 2010 20:30:05 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290960722.86.0.990237595756.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=awMRba5fV817MdJOn0nRrSVtB_MD9oxun9wA9@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

"The Python programming language also uses j to denote the imaginary unit.
MATLAB associates both i and j with the imaginary unit."
-Wikipedia<http://en.wikipedia.org/wiki/Imaginary_unit#Alternative_notations>

It would be a welcome feature in Python if the programming language would,
like MATLAB, associate both i and j with the imaginary unit.

----------
Added file: http://bugs.python.org/file19858/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
&quot;The Python programming language also uses j to denote the imaginary unit. MATLAB associates both i and j with the imaginary unit.&quot; -<a href="http://en.wikipedia.org/wiki/Imaginary_unit#Alternative_notations">Wikipedia</a><br>
<br>It would be a welcome feature in Python if the programming language would, like MATLAB, associate both i and j with the imaginary unit.

From report at bugs.python.org  Sun Nov 28 21:30:40 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 28 Nov 2010 20:30:40 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290976240.88.0.590221602119.issue10557@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> UnicodeEncodeError: 'decimal' codec can't encode character '\u066b'

Hmm, looks like a bug? I think U+066B is correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:32:31 2010
From: report at bugs.python.org (Blair)
Date: Sun, 28 Nov 2010 20:32:31 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1290960250.86.0.579669665431.issue5211@psf.upfronthosting.co.za>
Message-ID: <AANLkTintw2poKWUJJRFFoF1F4XvcOC3aEsEf5j1BjPhS@mail.gmail.com>


Blair <bidihall at gmail.com> added the comment:

Just to keep this discussion as clear as possible Mark, it was your first
option that I suggest is needed.

When that is done (as it was for a subclass of float in 2.6.6) it is
possible for the author of the subclass to implement commutative binary
operations (like + and * that must behave the same regardless of argument
order). Otherwise (as far as I can see) this cannot be done.

On Mon, Nov 29, 2010 at 5:04 AM, Mark Dickinson <report at bugs.python.org>wrote:

>
> Changes by Mark Dickinson <dickinsm at gmail.com>:
>
>
> Removed file: http://bugs.python.org/file19820/unnamed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5211>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19859/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
-------------- next part --------------
Just to keep this discussion as clear as possible Mark, it was your first option that I suggest is needed. <br><br>When that is done (as it was for a subclass of float in 2.6.6) it is possible for the author of the subclass to implement commutative binary operations (like + and * that must behave the same regardless of argument order). Otherwise (as far as I can see) this cannot be done.<br>
<br><br><div class="gmail_quote">On Mon, Nov 29, 2010 at 5:04 AM, Mark Dickinson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
Changes by Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt;:<br>
<br>
<br>
</div>Removed file: <a href="http://bugs.python.org/file19820/unnamed" target="_blank">http://bugs.python.org/file19820/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/issue5211" target="_blank">http://bugs.python.org/issue5211</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Sun Nov 28 21:37:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 20:37:01 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290976240.88.0.590221602119.issue10557@psf.upfronthosting.co.za>
Message-ID: <AANLkTinrLb8z=FVSZj1zJFKqQ4r1MqT-HULED0WH=KWG@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 28, 2010 at 3:30 PM, Stefan Krah <report at bugs.python.org> wrote:
..
>> UnicodeEncodeError: 'decimal' codec can't encode character '\u066b'
>
> Hmm, looks like a bug? I think U+066B is correct.
>
Really?  What about

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'decimal' codec can't encode character '\uff0e' in
position 4: invalid decimal Unicode string

.. and where do we draw the line?  Note that I am not against
Decimal() accepting any c with c.isdigit() returning True, but
builtins should be less promiscuous IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:38:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 20:38:15 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290976695.52.0.199541154915.issue10557@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Sending this by e-mail was not a good idea ...

On Sun, Nov 28, 2010 at 3:30 PM, Stefan Krah <report at bugs.python.org> wrote:
..
>> UnicodeEncodeError: 'decimal' codec can't encode character '\u066b'
>
> Hmm, looks like a bug? I think U+066B is correct.
>
Really?  What about

>>> float('???????')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'decimal' codec can't encode character '\uff0e' in
position 4: invalid decimal Unicode string

.. and where do we draw the line?  Note that I am not against
Decimal() accepting any c with c.isdigit() returning True, but
builtins should be less promiscuous IMO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:38:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 20:38:25 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1290976705.3.0.418053585556.issue10557@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg122725

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:43:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 28 Nov 2010 20:43: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: <1290977002.19.0.888481631433.issue10562@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file19858/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:46:21 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 20:46:21 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1290977181.61.0.0979561407185.issue5211@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Just to keep this discussion as clear as possible Mark, it was your
> first option that I suggest is needed.

Okay, so you want <float instance> + <xint instance> to try xint.__radd__ before float.__add__.

How do you propose this be achieved?  Can you explain exactly what semantics you'd like to see?  You've indicated what you want to happen for float and xint, but how should Python behave in general here?

In particular, when evaluating 'x + y' for general Python objects x and y, what rule or rules should Python use to decide whether to try x.__add__(y) or y.__radd__(x) first?

It seems you want some general mechanism that results in xint being 'preferred' to float, in the sense that xint.__radd__ and xint.__add__ will be tried in preference to float.__add__ and float.__radd__ (respectively).  But it's not clear to me what criterion Python would use to determine which out of two types (neither one inheriting from the other) should be 'preferred' in this sense.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:48:33 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 20:48:33 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1234307963.56.0.00813246872741.issue5211@psf.upfronthosting.co.za>
Message-ID: <1290977313.34.0.403742610939.issue5211@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file19859/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:49:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 20:49:11 +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: <1290977351.85.0.922876824845.issue10562@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Why not allow complex('1i')?

(Tongue in cheek: I am really looking for arguments against lax parsing in number builtins.  See issue 10557.)

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:55:40 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 20:55:40 +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: <1290977740.76.0.867101280835.issue10562@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> It would be a welcome feature in Python if the programming language
> would, like MATLAB, associate both i and j with the imaginary unit.

I suggest taking this to the python-ideas mailing list.  A working patch might increase the idea's chances.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 21:58:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 20:58: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: <1290977938.59.0.22083444073.issue10562@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Why not allow complex('1i')?

Indeed, if 4i were permitted as an imaginary literal, I'd expect to allow complex('3 + 4i') as well.

(And possible just plain complex('i') too, since complex('j') is currently allowed.  Grr.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 22:03:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 28 Nov 2010 21:03:15 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290977938.59.0.22083444073.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTinD7Dt3oDJkZxj-xW5t4jVACESNAsd2qcty1fdE@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Nov 28, 2010 at 3:58 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
> I'd expect to allow complex('3 + 4i') as well.

And with spaces surrounding '+' too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 22:14:23 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 28 Nov 2010 21:14:23 +0000
Subject: [issue10562] Change 'j' for imaginary unit into an 'i'
In-Reply-To: <1290977938.59.0.22083444073.issue10562@psf.upfronthosting.co.za>
Message-ID: <AANLkTikEnddDmu3EcJvyzL7uPuEy=nHGnrSYmdGtokvk@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

It would be great if the feature of having both j and i would exist in the
interpreter core, as well as the built-in function complex() to accept i.

----------
Added file: http://bugs.python.org/file19860/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________
-------------- next part --------------
It would be great if the feature of having both j and i would exist in the interpreter core, as well as the built-in function complex() to accept i.

From report at bugs.python.org  Sun Nov 28 22:17:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Nov 2010 21:17: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: <1290979028.71.0.0443785233159.issue10562@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There should be an environment variable to make the symbol settable.

$ PYTHONIMAGINARYSYMBOL=i python -c "import cmath; print(cmath.sqrt(-1))"
1i

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 22:17:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 28 Nov 2010 21:17: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: <1290979052.45.0.723998792746.issue10562@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(and perhaps a ResourceWarning if you choose something different from i and j)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 22:19:18 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 28 Nov 2010 21:19:18 +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: <1290979158.99.0.0303382622986.issue10562@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


Removed file: http://bugs.python.org/file19860/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10562>
_______________________________________

From report at bugs.python.org  Sun Nov 28 22:37:19 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 28 Nov 2010 21:37:19 +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: <1290980239.18.0.575818587678.issue10548@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The same is also true for tearDown and cleanUp functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10548>
_______________________________________

From report at bugs.python.org  Sun Nov 28 22:47:59 2010
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 28 Nov 2010 21:47:59 +0000
Subject: [issue10569] abc: `issubclass([], my_abstract_type)` raises exception
In-Reply-To: <1290980879.69.0.728578959606.issue10569@psf.upfronthosting.co.za>
Message-ID: <1290980879.69.0.728578959606.issue10569@psf.upfronthosting.co.za>


New submission from Ram Rachum <cool-rr at cool-rr.com>:

>>> import abc
>>> class A(object, metaclass=abc.ABCMeta):
...     pass
>>> issubclass([], A)
Traceback (most recent call last):
  File "<pyshell#2>", line 1, in <module>
    issubclass([], A)
  File "c:\Python32\lib\abc.py", line 137, in __subclasscheck__
    if subclass in cls._abc_cache:
  File "c:\Python32\lib\_weakrefset.py", line 69, in __contains__
    return ref(item) in self.data
TypeError: cannot create weak reference to 'list' object

I should be able to check whether an object is a subclass of something without confirming it's a type first. I think this call should just return False.

----------
components: Library (Lib)
messages: 122736
nosy: cool-RR
priority: normal
severity: normal
status: open
title: abc: `issubclass([], my_abstract_type)` raises exception
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10569>
_______________________________________

From report at bugs.python.org  Sun Nov 28 22:59:00 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 28 Nov 2010 21:59:00 +0000
Subject: [issue10569] abc: `issubclass([], my_abstract_type)` raises exception
In-Reply-To: <1290980879.69.0.728578959606.issue10569@psf.upfronthosting.co.za>
Message-ID: <1290981540.18.0.933827532281.issue10569@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I don't agree. "issubclass(1, list)" has always raised an exception.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10569>
_______________________________________

From report at bugs.python.org  Sun Nov 28 23:01:56 2010
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 28 Nov 2010 22:01:56 +0000
Subject: [issue10569] abc: `issubclass([], my_abstract_type)` raises exception
In-Reply-To: <1290980879.69.0.728578959606.issue10569@psf.upfronthosting.co.za>
Message-ID: <1290981716.1.0.337834845211.issue10569@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

But do you think it's a good idea that `issubclass(1, list)` raises an exception? Why not simply return `False`?

Do you think there's someone out there who's counting on `issubclass` to raise an exception?

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10569>
_______________________________________

From report at bugs.python.org  Sun Nov 28 23:16:42 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 28 Nov 2010 22:16:42 +0000
Subject: [issue10569] abc: `issubclass([], my_abstract_type)` raises exception
In-Reply-To: <1290980879.69.0.728578959606.issue10569@psf.upfronthosting.co.za>
Message-ID: <1290982602.79.0.503768587178.issue10569@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

issubclass is for relationship between classes. Did you consider isinstance() instead?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10569>
_______________________________________

From report at bugs.python.org  Sun Nov 28 23:22:20 2010
From: report at bugs.python.org (Ram Rachum)
Date: Sun, 28 Nov 2010 22:22:20 +0000
Subject: [issue10569] abc: `issubclass([], my_abstract_type)` raises exception
In-Reply-To: <1290980879.69.0.728578959606.issue10569@psf.upfronthosting.co.za>
Message-ID: <1290982940.03.0.614838221075.issue10569@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Amaury, I am aware of what `issubclass` does and what `isinstance` does. I am not manually feeding `[]` into `issubclass`. I have an object which can be either a list, or a string, or a callable, or a type. And I want to check whether it's a sub-class of some base class.

So I don't think I should be taking extra precautions before using `issubclass`: If my object is not a subclass of the given base class, I should just get `False`.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10569>
_______________________________________

From report at bugs.python.org  Sun Nov 28 23:31:36 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 28 Nov 2010 22:31:36 +0000
Subject: [issue10569] abc: `issubclass([], my_abstract_type)` raises exception
In-Reply-To: <1290980879.69.0.728578959606.issue10569@psf.upfronthosting.co.za>
Message-ID: <1290983496.42.0.0105258434446.issue10569@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Tell python-ideas about it.

----------
nosy: +benjamin.peterson
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10569>
_______________________________________

From report at bugs.python.org  Sun Nov 28 23:40:16 2010
From: report at bugs.python.org (Blair)
Date: Sun, 28 Nov 2010 22:40:16 +0000
Subject: [issue5211] Fix complex type to avoid coercion in 2.7.
In-Reply-To: <1290977313.41.0.2900788169.issue5211@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=5Em4s=iMFQWdbt4gmU7b1pUtY2OCRTy9as2TK@mail.gmail.com>


Blair <bidihall at gmail.com> added the comment:

I am not really the person (I don't know how Python is implemented) to
explain how the correct behaviour should be achieved (sorry). I do
appreciate that this may seem like exceptional behaviour. Numbers are a bit
different.

However, for what its worth, I think that the 'correct behaviour' was
implemented for subclasses of float and was working in Python 2.6, but not
now in 2.7. I don't know how the earlier implementation was done, but it
does work (I have used it to develop a nice little math library). Would
there be any documentation about the implementation?

I would say that the semantics do not need to apply to arbitrary Python
objects. The problem arises for numeric type subclasses when they are mixed
with non-subclassed numeric types.

In that case:

For 'x opn y' any binary operator (like +,*, etc), if (and only if)  'x' is
a built-in numeric type (int, long, float, complex) and 'y' is a subclass of
a built-in numeric type, then y.__ropn__(x) (if it exists) should be called
before x.__opn__(y).

If that were done, then subclasses of number types can implement commutative
operator properties. Otherwise, I don't think it works properly.

I see this as 'special' behaviour required of the int, long, float and
complex classes, rather than special behaviour for all Python objects.

If both 'x' and 'y' are subclasses of built in number types the required
behaviour seems too complicated to specify. I would be inclined to do
nothing special. That is, if both 'x' and 'y' are derived from built in
numeric classes (possibly different types) then x.__opn__(y) would be
called.

And should this apply to non-number types? I think not. Numbers deserve
special treatment.

I hope this helps.

On Mon, Nov 29, 2010 at 9:48 AM, Mark Dickinson <report at bugs.python.org>wrote:

>
> Changes by Mark Dickinson <dickinsm at gmail.com>:
>
>
> Removed file: http://bugs.python.org/file19859/unnamed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue5211>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19861/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5211>
_______________________________________
-------------- next part --------------
I am not really the person (I don&#39;t know how Python is implemented) to explain how the correct behaviour should be achieved (sorry). I do appreciate that this may seem like exceptional behaviour. Numbers are a bit different.<br>
<br>However, for what its worth, I think that the &#39;correct behaviour&#39; was implemented for subclasses of float and was working in Python 2.6, but not now in 2.7. I don&#39;t know how the earlier implementation was done, but it does work (I have used it to develop a nice little math library). Would there be any documentation about the implementation?<br>
<br>I would say that the semantics do not need to apply to arbitrary Python objects. The problem arises for numeric type subclasses when they are mixed with non-subclassed numeric types.?? <br><br>In that case:<br><br>For &#39;x opn y&#39; any binary operator (like +,*, etc), if (and only if)?? &#39;x&#39; is a built-in numeric type (int, long, float, complex) and &#39;y&#39; is a subclass of a built-in numeric type, then y.__ropn__(x) (if it exists) should be called before x.__opn__(y).<br>
<br>If that were done, then subclasses of number types can implement commutative operator properties. Otherwise, I don&#39;t think it works properly.<br><br>I see this as &#39;special&#39; behaviour required of the int, long, float and complex classes, rather than special behaviour for all Python objects.<br>
<br>If both &#39;x&#39; and &#39;y&#39; are subclasses of built in number types the required behaviour seems too complicated to specify. I would be inclined to do nothing special. That is, if both &#39;x&#39; and &#39;y&#39; are derived from built in?? numeric classes (possibly different types) then x.__opn__(y) would be called.<br>
<br>And should this apply to non-number types? I think not. Numbers deserve special treatment.<br><br>I hope this helps.<br><br><div class="gmail_quote">On Mon, Nov 29, 2010 at 9:48 AM, Mark Dickinson <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><br>
Changes by Mark Dickinson &lt;<a href="mailto:dickinsm at gmail.com">dickinsm at gmail.com</a>&gt;:<br>
<br>
<br>
</div>Removed file: <a href="http://bugs.python.org/file19859/unnamed" target="_blank">http://bugs.python.org/file19859/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/issue5211" target="_blank">http://bugs.python.org/issue5211</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Sun Nov 28 23:42:24 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 28 Nov 2010 22:42:24 +0000
Subject: [issue10569] abc: `issubclass([], my_abstract_type)` raises exception
In-Reply-To: <1290980879.69.0.728578959606.issue10569@psf.upfronthosting.co.za>
Message-ID: <1290984144.99.0.900267674975.issue10569@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

FWIW (which isn't much I guess) it annoys me that I have to protect calls to issubclass with if isinstance(obj, type).

----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10569>
_______________________________________

From report at bugs.python.org  Sun Nov 28 23:57:26 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Sun, 28 Nov 2010 22:57:26 +0000
Subject: [issue10499] Modular interpolation in configparser
In-Reply-To: <1290395793.65.0.355106669717.issue10499@psf.upfronthosting.co.za>
Message-ID: <1290985046.39.0.569340012859.issue10499@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Review posted.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10499>
_______________________________________

From report at bugs.python.org  Mon Nov 29 00:27:10 2010
From: report at bugs.python.org (Michael Foord)
Date: Sun, 28 Nov 2010 23:27:10 +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: <1290986830.28.0.951918214281.issue10548@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Note that if an error is raised in a tearDown or cleanUp then unexpected-success should not be reported either. Not very important but might as well be fixed at the same time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10548>
_______________________________________

From report at bugs.python.org  Mon Nov 29 00:38:55 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Sun, 28 Nov 2010 23:38:55 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>


New submission from Jakub Wilk <jwilk at jwilk.net>:

$ python3 --version
Python 3.1.3

$ python3 setup.py bdist upload --sign
[snip]
Traceback (most recent call last):
  File "setup.py", line 71, in <module>
    cmdclass = dict(build_py=build_py)
  File "/usr/local/lib/python3.1/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/usr/local/lib/python3.1/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python3.1/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.1/distutils/command/upload.py", line 66, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/local/lib/python3.1/distutils/command/upload.py", line 155, in upload_file
    body.write(value)
TypeError: 'str' does not support the buffer interface


Without --sign it works just fine.

----------
components: Library (Lib)
messages: 122746
nosy: jwilk
priority: normal
severity: normal
status: open
title: curses.tigetstr() returns bytes, but curses.tparm() expects a string
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10570>
_______________________________________

From report at bugs.python.org  Mon Nov 29 00:38:59 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Sun, 28 Nov 2010 23:38:59 +0000
Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does
	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>


New submission from Jakub Wilk <jwilk at jwilk.net>:

$ python3 --version
Python 3.1.3

$ python3 setup.py bdist upload --sign
[snip]
Traceback (most recent call last):
  File "setup.py", line 71, in <module>
    cmdclass = dict(build_py=build_py)
  File "/usr/local/lib/python3.1/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/usr/local/lib/python3.1/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/usr/local/lib/python3.1/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/usr/local/lib/python3.1/distutils/command/upload.py", line 66, in run
    self.upload_file(command, pyversion, filename)
  File "/usr/local/lib/python3.1/distutils/command/upload.py", line 155, in upload_file
    body.write(value)
TypeError: 'str' does not support the buffer interface


Without --sign it works just fine.

----------
assignee: tarek
components: Distutils
messages: 122747
nosy: eric.araujo, jwilk, tarek
priority: normal
severity: normal
status: open
title: "setup.py upload --sign" broken: TypeError: 'str' does not support the buffer interface
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10571>
_______________________________________

From report at bugs.python.org  Mon Nov 29 00:39:11 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 28 Nov 2010 23:39:11 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1290987551.43.0.578198943041.issue8879@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Amaury -- how does issue8879_unicode.diff look? Made the suggested change and added a test.

----------
stage: committed/rejected -> patch review
Added file: http://bugs.python.org/file19862/issue8879_unicode.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Mon Nov 29 00:48:02 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 28 Nov 2010 23:48:02 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1290988082.26.0.188260398858.issue8879@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Looks good, except that win32_error("link", NULL) should be called instead of posix_error(). errno is not guaranteed to be correctly set by the win32 api, and GetLastError() ususally gives more accurate errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Mon Nov 29 01:01:34 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 29 Nov 2010 00:01:34 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1290988894.55.0.249389737744.issue8879@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Committed in r86854 with your win32_error suggestion. Thanks for your help and input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Mon Nov 29 01:52:59 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 29 Nov 2010 00:52:59 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

Having tests in Lib/test instead of inside the package makes it easier to grep the unittest package without grepping the tests. The Windows installer has an "install without tests" option which is easier to honour if the tests aren't in the package.

However, currently all packages that have test *packages* have the tests in the package rather than inside Lib/test. (There are no test packages inside Lib/test.)

Examples: email, distutils, ctypes, importlib, json, lib2to3, sqlite3

I also maintain an external port of unittest from Python 3. This is unittest2-py3k. Moving the tests would make it *slightly* harder to keep this in sync. I'm moving to maintaining this port as a set of patches rather than a separate branch. These patches can be applied automatically to unittest from py3k head. unittest2-py3k will be built automatically by a script, so it isn't a big deal.

----------
assignee: michael.foord
keywords: easy
messages: 122751
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Move unittest test package to Lib/test
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 01:55:59 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 29 Nov 2010 00:55:59 +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: <1290992159.72.0.107137027413.issue10573@psf.upfronthosting.co.za>


New submission from Michael Foord <michael at voidspace.org.uk>:

The unittest documentation, argument names and implementation need to be consistent about the order of (actual, expected) for TestCase.assert methods that take two arguments. 

This is particularly relevant for the methods that produce 'diffed' output on failure - as the order determines whether mismatched items are missing from the expected or additional to the expected.

The documentation, signatures and implementation of all two argument asserts need to be checked to ensure they are the same and implemented correctly.

Personally I prefer (actual, expected).

----------
assignee: michael.foord
components: Documentation, Library (Lib)
messages: 122752
nosy: michael.foord
priority: normal
severity: normal
status: open
title: Consistency in unittest assert methods: order of actual, expected
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10573>
_______________________________________

From report at bugs.python.org  Mon Nov 29 02:02:09 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 29 Nov 2010 01:02:09 +0000
Subject: [issue1705520] API for excluding methods from unittest stack traces
Message-ID: <1290992529.86.0.569877175854.issue1705520@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

__unittest needs to die (with appropriate deprecation).

I agree that a nicer API for marking functions and methods as needing to be excluded from unittest stacktraces would be useful. A decorator is a good way to expose that API to developers. Internally unittest could use the new API and __unittest can go away.

Introspecting stack frames is a bad way to implement this, as it doesn't play well with other implementations (like IronPython which doesn't have introspectable Python stack frames by default).

----------
assignee: purcell -> michael.foord
title: pyunit should allow __unittest in locals to trim stackframes -> API for excluding methods from unittest stack traces

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1705520>
_______________________________________

From report at bugs.python.org  Mon Nov 29 02:02:26 2010
From: report at bugs.python.org (Carlo Bramini)
Date: Mon, 29 Nov 2010 01:02:26 +0000
Subject: [issue10560] Fixes for Windows sources
In-Reply-To: <1290943077.95.0.556815872588.issue10560@psf.upfronthosting.co.za>
Message-ID: <1290992546.34.0.801701471114.issue10560@psf.upfronthosting.co.za>


Carlo Bramini <carlo.bramix at libero.it> added the comment:

I modified the patch by using Py_LL() as suggested in a previous comment.

I just would like to say that these fixes are not required to compiling under MSVC5: I was able to compile all the sources as they were, even without changes and this is a great thing.
I have just noticed, from some strange warning messages, that few things required to be fixed, now reduced to correct __STDC__ syntax to some functions (declaring in that manner is wrong anyways, since it's C89) and fix a constant with the right modifier.

----------
Added file: http://bugs.python.org/file19863/python-svn.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10560>
_______________________________________

From report at bugs.python.org  Mon Nov 29 02:42:40 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Mon, 29 Nov 2010 01:42:40 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1290994960.93.0.0578896129584.issue10478@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

Would avoiding PyErr_CheckSignals() while the file object is in inconsistent state be a reasonable alternative?

I am guessing that it's not that uncommon for a signal handler to need IO (e.g to log a signal). 

If making IO safer is not an option, then I think, this limitation needs to be documented (especially, given that this seems to be a behavior change from Python 2.x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10478>
_______________________________________

From report at bugs.python.org  Mon Nov 29 02:46:31 2010
From: report at bugs.python.org (Xuanji Li)
Date: Mon, 29 Nov 2010 01:46:31 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1290995191.41.0.776257186004.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Hi Raymond, I assume you're referring to catlee's patch? 'str' has been changed to 'data' in python 3.2

While porting the patch I ran into this issue, which is that isinstance(str, collections.Iterable) doesn't behave exactly like hasattr(str,'next')


>>> hasattr("lol", '__next__')
False
>>> isinstance("lol", collections.Iterable)
True

so using the isinstance method would actually match against strings, which iirc would make the program fail. I can confirm later if needed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Mon Nov 29 02:49:01 2010
From: report at bugs.python.org (Ilya Sandler)
Date: Mon, 29 Nov 2010 01:49:01 +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: <1290995341.61.0.521357244216.issue7245@psf.upfronthosting.co.za>


Ilya Sandler <ilya.sandler at gmail.com> added the comment:

The patch tries to write to stdout in signal handler. 

This currently does not work in the python 3.x  (see
http://bugs.python.org/issue10478).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7245>
_______________________________________

From report at bugs.python.org  Mon Nov 29 02:52:07 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Nov 2010 01:52:07 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1290995527.41.0.373861778409.issue5150@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: rhettinger -> ned.deily
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Mon Nov 29 03:39:10 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Nov 2010 02:39:10 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1290998350.85.0.605624495004.issue10273@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Ezio, please do the regexp-->regex changes and move the tests under Lib/test.

----------
assignee: rhettinger -> ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10273>
_______________________________________

From report at bugs.python.org  Mon Nov 29 04:13:56 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Nov 2010 03:13:56 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1291000436.7.0.985183682766.issue10544@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think it is definitely wrong the way it works in 3.x.  (Especially since it works as expected in 2.x.)

I agree with Inyeol's preference of fixes: (1) make it work properly for listcomps as well as genexps, (2) if that's not possible, forbid yield in a genexp or listcomp.

Note that even though yield in a genexp could be considered as having a well-defined meaning, that meaning is not useful and I would consider it as merely a coincidence of the specification, not an intentional effect.  So I would be fine changing its meaning.  (My assumption is that since it is not useful there is -- almost -- no code depending on that meaning.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Mon Nov 29 04:14:30 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Nov 2010 03:14:30 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1291000470.44.0.221326247949.issue10544@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

PS. Wasn't there a similar issue with something inside a genexp that raises StopIteration?  Did we ever solve that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Mon Nov 29 04:14:41 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Nov 2010 03:14:41 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1291000481.39.0.458131250861.issue10544@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
assignee: gvanrossum -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Mon Nov 29 04:19:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 03:19:10 +0000
Subject: [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1291000750.64.0.387463823668.issue10563@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This looks like a bug in the underlying platform. POSIX requires [1] that the output of ctime() fits in a 26-character buffer.  Note that a change has been recently made to time.asctime() to reject year > 9999.  See r85137 and issue6608.  I think for consistency, we should reject huge timestamps in time ctime() as well. 


[1] http://www.opengroup.org/onlinepubs/009695399/functions/ctime.html

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10563>
_______________________________________

From report at bugs.python.org  Mon Nov 29 04:21:21 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 03:21:21 +0000
Subject: [issue10563] Spurious newline in time.ctime
In-Reply-To: <1290959240.08.0.913009457798.issue10563@psf.upfronthosting.co.za>
Message-ID: <1291000881.21.0.0707140233816.issue10563@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
stage: unit test needed -> needs patch
type:  -> feature request
versions: +Python 3.2 -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10563>
_______________________________________

From report at bugs.python.org  Mon Nov 29 04:27:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 03:27:06 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1291001226.41.0.945159010759.issue10544@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/issue10544>
_______________________________________

From report at bugs.python.org  Mon Nov 29 04:32:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 03:32:57 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1291001577.69.0.192534974274.issue10544@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Isn't this the same issue as #3267?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Mon Nov 29 04:56:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Nov 2010 03:56:53 +0000
Subject: [issue10565] isinstance(x, collections.Iterator) can return True,
	when x isn't iterable
In-Reply-To: <1290959907.04.0.171212908469.issue10565@psf.upfronthosting.co.za>
Message-ID: <1291003013.48.0.444201332236.issue10565@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r86857.
Needs backport.

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10565>
_______________________________________

From report at bugs.python.org  Mon Nov 29 04:59:47 2010
From: report at bugs.python.org (Vil)
Date: Mon, 29 Nov 2010 03:59:47 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290934573.54.0.0479091810757.issue10500@psf.upfronthosting.co.za>
Message-ID: <AANLkTikkHpKoOeOZs0urneBtwuvOxrAfthz=2uon+6Tu@mail.gmail.com>


Vil <vilignoble at gmail.com> added the comment:

I am using CA antivirus, I downloaded 3.13 in link
http://www.python.org/ftp/python/3.1.3/python-3.1.3.msi

and it is still showing Win32/Palevo.DZ when i scan and it quarantines and
then erases the installer msix86 binary (does not include source)

On Sun, Nov 28, 2010 at 2:56 AM, Ezio Melotti <report at bugs.python.org>wrote:

>
> Ezio Melotti <ezio.melotti at gmail.com> added the comment:
>
> I checked both the 3.1.2 and 3.1.3 x86 msi installers on windows xp machine
> using Avast and it didn't find anything.
>
> ----------
> nosy: +ezio.melotti
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10500>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19864/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________
-------------- next part --------------
I am using CA antivirus, I downloaded 3.13 in link <br><a href="http://www.python.org/ftp/python/3.1.3/python-3.1.3.msi">http://www.python.org/ftp/python/3.1.3/python-3.1.3.msi</a><br><br>and it is still showing Win32/Palevo.DZ when i scan and it quarantines and then erases the installer msix86 binary (does not include source)<br>
<br><br><div class="gmail_quote">On Sun, Nov 28, 2010 at 2:56 AM, Ezio Melotti <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Ezio Melotti &lt;<a href="mailto:ezio.melotti at gmail.com">ezio.melotti at gmail.com</a>&gt; added the comment:<br>
<br>
I checked both the 3.1.2 and 3.1.3 x86 msi installers on windows xp machine using Avast and it didn&#39;t find anything.<br>
<br>
----------<br>
nosy: +ezio.melotti<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/issue10500" target="_blank">http://bugs.python.org/issue10500</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Mon Nov 29 05:01:26 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 29 Nov 2010 04:01:26 +0000
Subject: [issue10544] yield expression inside generator expression does nothing
In-Reply-To: <1290799279.15.0.89740732651.issue10544@psf.upfronthosting.co.za>
Message-ID: <1291003286.54.0.0484262263254.issue10544@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Yes it is, but I was never asked about it back then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10544>
_______________________________________

From report at bugs.python.org  Mon Nov 29 05:13:40 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 29 Nov 2010 04:13:40 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1291004020.55.0.113752432752.issue10500@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I would recommend to the poster to contact CA and to notify them that they have a false positive no other antivirus (check VirusTotal site) in the world is having :-).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Mon Nov 29 05:26:01 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 29 Nov 2010 04:26:01 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1291004761.86.0.93262809204.issue8879@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

This patch seems to break quite a few buildbots.

for instance: http://www.python.org/dev/buildbot/all/builders/x86%20OpenIndiana%203.x/builds/81/steps/test/logs/stdio

"""
test_mbcs_name (test.test_os.LinkTests) ... test test_os failed -- Traceback (most recent call last):
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_os.py", line 893, in test_mbcs_name
    self._test_link(self.file1, self.file2)
  File "/export/home/buildbot/32bits/3.x.cea-indiana-x86/build/Lib/test/test_os.py", line 876, in _test_link
    with open(file1, "w") as f1:
UnicodeEncodeError: 'ascii' codec can't encode characters in position 15-16: ordinal not in range(128)
"""

----------
nosy: +jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Mon Nov 29 05:26:27 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Mon, 29 Nov 2010 04:26:27 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1291004787.19.0.317358797564.issue10500@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

I downloaded that linked MSI again (as its different from the one originally reported)-- and it too is still coming up as clean.

I would suggest that its clearly either a false positive as Jes?s is suggesting... or something on your side or between you and python.org is infecting it as or right after you download it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Mon Nov 29 05:32:08 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 29 Nov 2010 04:32:08 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1290417396.82.0.802984797012.issue10500@psf.upfronthosting.co.za>
Message-ID: <1291005128.96.0.865011980714.issue10500@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

The virustotal (Note: I am associated to those guys) link I posted included HASHES you can verify in your side to know if it is a false positive or the file is actually altered by "something" in transit/in your site.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________

From report at bugs.python.org  Mon Nov 29 05:33:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 29 Nov 2010 04:33:36 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1291005216.89.0.849994009751.issue8879@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Maybe the test should be Windows-only?
I don't really know the answer...things tend to fall apart when I get involved with Unicode, encoding, codecs, etc. :/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Mon Nov 29 05:53:23 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 29 Nov 2010 04:53:23 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1291006403.4.0.17121322353.issue8879@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I am not familiar with this either, but better to restrict the test to platforms with actual mbcs encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8879>
_______________________________________

From report at bugs.python.org  Mon Nov 29 05:59:02 2010
From: report at bugs.python.org (Roy H. Han)
Date: Mon, 29 Nov 2010 04:59:02 +0000
Subject: [issue10574] email.header.decode_header fails if the string contains
	multiple directives
In-Reply-To: <1291006742.3.0.976657796626.issue10574@psf.upfronthosting.co.za>
Message-ID: <1291006742.3.0.976657796626.issue10574@psf.upfronthosting.co.za>


New submission from Roy H. Han <starsareblueandfaraway at gmail.com>:

email.header.decode_header fails for the following message subject:
::

    email.header.decode_header('=?UTF-8?B?MjAxMSBBVVRNIENBTEwgZm9yIE5PTUlO?==?UTF-8?B?QVRJT05TIG9mIFZQIGZvciBNZW1iZXJz?==?UTF-8?B?aGlw?=')


If the directives are removed and the padding problems are fixed, the subject parses correctly.
::

    email.header.decode_header('=?UTF-8?B?%s==?=' % '=?UTF-8?B?MjAxMSBBVVRNIENBTEwgZm9yIE5PTUlO?==?UTF-8?B?QVRJT05TIG9mIFZQIGZvciBNZW1iZXJz?==?UTF-8?B?aGlw?='.replace('=?UTF-8?B?', '').replace('?', '').replace('=', ''))

----------
components: Library (Lib)
messages: 122772
nosy: starsareblueandfaraway
priority: normal
severity: normal
status: open
title: email.header.decode_header fails if the string contains multiple directives
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10574>
_______________________________________

From report at bugs.python.org  Mon Nov 29 06:12:29 2010
From: report at bugs.python.org (Roy Hyunjin Han)
Date: Mon, 29 Nov 2010 05:12:29 +0000
Subject: [issue10574] email.header.decode_header fails if the string contains
	multiple directives
In-Reply-To: <1291006742.3.0.976657796626.issue10574@psf.upfronthosting.co.za>
Message-ID: <1291007549.31.0.430176835889.issue10574@psf.upfronthosting.co.za>


Roy Hyunjin Han <starsareblueandfaraway at gmail.com> added the comment:

Currently using the following workaround.

import re
import email.header

def decodeSafely(x):
    match = re.search('(=\?.*?\?B\?)', x)
    if not match:
        return x
    encoding = match.group(1)
    return email.header.decode_header('%s%s==?=' % (encoding, x.replace(encoding, '').replace('?', '').replace('=', '')))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10574>
_______________________________________

From report at bugs.python.org  Mon Nov 29 06:59:34 2010
From: report at bugs.python.org (Roy Hyunjin Han)
Date: Mon, 29 Nov 2010 05:59:34 +0000
Subject: [issue10574] email.header.decode_header fails if the string contains
	multiple directives
In-Reply-To: <1291006742.3.0.976657796626.issue10574@psf.upfronthosting.co.za>
Message-ID: <1291010374.27.0.926082536926.issue10574@psf.upfronthosting.co.za>


Roy Hyunjin Han <starsareblueandfaraway at gmail.com> added the comment:

Improved workaround to handle another degenerate case where the encoded string is in between non-encoded strings.

import re
import email.header

pattern_ecre = re.compile(r'((=\?.*?\?[qb]\?).*\?=)', re.VERBOSE | re.IGNORECASE | re.MULTILINE)

def decodeSafely(x):
    match = pattern_ecre.search(x)
    if not match:
        return x
    string, encoding = match.groups()
    stringBefore, string, stringAfter = x.partition(string)
    return stringBefore + email.header.decode_header('%s%s==?=' % (encoding, string.replace(encoding, '').replace('?', '').replace('=', '')))[0][0] + stringAfter

print decodeSafely('=?UTF-8?B?MjAxMSBBVVRNIENBTEwgZm9yIE5PTUlO?==?UTF-8?B?QVRJT05TIG9mIFZQIGZvciBNZW1iZXJz?==?UTF-8?B?aGlw?=')
print decodeSafely('"=?UTF-8?B?QVVUTSBIZWFkcXVhcnRlcnM=?="<info at autm.net>')

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10574>
_______________________________________

From report at bugs.python.org  Mon Nov 29 07:23:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 06:23:09 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1290914546.61.0.639677577533.issue10557@psf.upfronthosting.co.za>
Message-ID: <1291011789.32.0.244648538312.issue10557@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

After a bit of svn archeology, it does appear that Arabic-Indic digits' support was deliberate at least in the sense that the feature was tested for when the code was first committed. See r15000.

The test migrated from file to file over the last 10 years, but it is still present in test_float.py:

        self.assertEqual(float(b"  \u0663.\u0661\u0664  ".decode('raw-unicode-escape')), 3.14)

(It should probably be now rewritten using a string literal.)

I am now attaching the patch (issue10557.diff) that fixes the bug without sacrificing non-ASCII digit support.

If this approach is well-received, I would like to replace all calls to PyUnicode_EncodeDecimal() with the calls to the new _PyUnicode_EncodeDecimalUTF8() and deprecate Latin-1-oriented PyUnicode_EncodeDecimal().

For the future, I note that starting with Unicode 6.0.0, the Unicode Consortium promises that

"""
Characters with the property value Numeric_Type=de (Decimal) only occur in contiguous ranges of 10 characters, with ascending numeric values from 0 to 9 (Numeric_Value=0..9).
"""

This makes it very easy to check a numeric string does not contain a mix of digits from different scripts.

I still believe that proper API should require explicit choice of language or locale before allowing digits other than 0-9 just as int() would not accept hexadecimal digits without explicit choice of base >= 16.  But this would be a subject of a feature request.

----------
Added file: http://bugs.python.org/file19865/issue10557.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Mon Nov 29 07:46:02 2010
From: report at bugs.python.org (Roy Hyunjin Han)
Date: Mon, 29 Nov 2010 06:46:02 +0000
Subject: [issue10574] email.header.decode_header fails if the string contains
	multiple directives
In-Reply-To: <1291006742.3.0.976657796626.issue10574@psf.upfronthosting.co.za>
Message-ID: <1291013162.69.0.338539552541.issue10574@psf.upfronthosting.co.za>


Roy Hyunjin Han <starsareblueandfaraway at gmail.com> added the comment:

The following code seems to solve the first case just as well.  It seems that it is a problem of missing whitespace.

email.header.decode_header('=?UTF-8?B?MjAxMSBBVVRNIENBTEwgZm9yIE5PTUlO?==?UTF-8?B?QVRJT05TIG9mIFZQIGZvciBNZW1iZXJz?==?UTF-8?B?aGlw?='.replace('?==?', '?= =?'))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10574>
_______________________________________

From report at bugs.python.org  Mon Nov 29 08:22:47 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 29 Nov 2010 07:22:47 +0000
Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does
	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1291015367.13.0.650924616336.issue10571@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

that seems to be the wrong report. did you mean

Package: python3.1
Version: 3.1.2+20101012-1
Severity: normal

curses.tigetstr() returns bytes (which makes sense), but curses.tparm() expects
a Unicode string as first argument. As a consequence even the example given in
the documentation doesn't work:

>>> from curses import *
>>> setupterm()
>>> tparm(tigetstr("cup"), 5, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be string, not bytes

----------
assignee: tarek -> 
components: +Library (Lib) -Distutils
nosy: +doko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10571>
_______________________________________

From report at bugs.python.org  Mon Nov 29 09:24:27 2010
From: report at bugs.python.org (Daniel Tavares)
Date: Mon, 29 Nov 2010 08:24:27 +0000
Subject: [issue9162] License for multiprocessing files
In-Reply-To: <1278311687.0.0.315948028382.issue9162@psf.upfronthosting.co.za>
Message-ID: <1291019067.04.0.686353580954.issue9162@psf.upfronthosting.co.za>


Daniel Tavares <danielmtavares at gmail.com> added the comment:

Replaced all entries of "--- see COPYING.txt" with the BSD license. See patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file19866/issue9162.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9162>
_______________________________________

From report at bugs.python.org  Mon Nov 29 09:41:38 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Nov 2010 08:41:38 +0000
Subject: [issue10535] Enable warnings by default in unittest
In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>
Message-ID: <1291020098.23.0.699735793993.issue10535@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

Attached a new patch.

A few comments about it:
1) A new category for UnittestWarnings could still be added to make it easier to filter warnings using the -W python flags and thus providing more control;
2) I didn't change the deprecation message in the patch -- I will probably do it in a separate commit;
3) The patch touches a few unrelated unittest/test/test_*.py files that were checking for the number of args explicitely;
4) In order to test the different combinations of flags/args I created a new _test_warnings.py file called from test_runner.py via subprocess;
5) unittest warnings are now printed only once even when 'always' is passed as an arg, but not when it's set with -W (this somehow addresses the "limitation" described in my previous message);

----------
Added file: http://bugs.python.org/file19867/issue10535-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10535>
_______________________________________

From report at bugs.python.org  Mon Nov 29 09:41:49 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 29 Nov 2010 08:41:49 +0000
Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does
	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1291020109.0.0.029925286973.issue10571@psf.upfronthosting.co.za>


Jakub Wilk <jwilk at jwilk.net> added the comment:

Matthias: Nope, this one is OK.

----------
assignee:  -> tarek
components: +Distutils -Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10571>
_______________________________________

From report at bugs.python.org  Mon Nov 29 09:44:07 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 29 Nov 2010 08:44:07 +0000
Subject: [issue10570] curses.tigetstr() returns bytes,
	but curses.tparm() expects a string
In-Reply-To: <1290987535.2.0.130889699839.issue10570@psf.upfronthosting.co.za>
Message-ID: <1291020247.48.0.488732933716.issue10570@psf.upfronthosting.co.za>


Jakub Wilk <jwilk at jwilk.net> added the comment:

Ugh. Please disregard the first message. What I wanted to write is:

In Python 3.1.3, curses.tigetstr() returns bytes (which makes sense), but
curses.tparm() expects a Unicode string as first argument. As a consequence
even the example given in the documentation doesn't work:

>>> from curses import *
>>> setupterm()
>>> tparm(tigetstr("cup"), 5, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: must be string, not bytes

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10570>
_______________________________________

From report at bugs.python.org  Mon Nov 29 09:51:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 29 Nov 2010 08:51:26 +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: <1291020686.47.0.306065556547.issue10242@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

ISTM that the new name is worse than the old name.  I hadn't followed this issue, heard assertCountEqual the first time today, and couldn't guess what it does.  I'd have assumed that it checks only for equality of the number of items in a sequence, not for equality of the actual items.

I appreciate that it's hard finding good short names, but just because the implementation uses collections.Counter does not mean that Count needs to be in the method name :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10242>
_______________________________________

From report at bugs.python.org  Mon Nov 29 09:58:33 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 29 Nov 2010 08:58:33 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <20101129085731.GE2023@rubuntu>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sun, Nov 28, 2010 at 05:48:20AM +0000, ?ric Araujo wrote:
> I?m not committing directly because I?d like feedback: Is the
> wording okay for the beginning of the tutorial?

It seems fine and useful. Please go ahead.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Mon Nov 29 10:15:10 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 29 Nov 2010 09:15:10 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291022110.58.0.741167345476.issue3243@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

xuanji, the issue you stumbled upon was just fixed by Raymond for the report Issue10565.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Mon Nov 29 10:38:17 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Nov 2010 09:38:17 +0000
Subject: [issue10535] Enable warnings by default in unittest
In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>
Message-ID: <1291023497.21.0.783598971999.issue10535@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Removed file: http://bugs.python.org/file19867/issue10535-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10535>
_______________________________________

From report at bugs.python.org  Mon Nov 29 10:38:35 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Nov 2010 09:38:35 +0000
Subject: [issue10535] Enable warnings by default in unittest
In-Reply-To: <1290722916.62.0.0639858562622.issue10535@psf.upfronthosting.co.za>
Message-ID: <1291023515.02.0.758234972615.issue10535@psf.upfronthosting.co.za>


Changes by Ezio Melotti <ezio.melotti at gmail.com>:


Added file: http://bugs.python.org/file19868/issue10535-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10535>
_______________________________________

From report at bugs.python.org  Mon Nov 29 10:41:37 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 29 Nov 2010 09:41:37 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <1291011789.32.0.244648538312.issue10557@psf.upfronthosting.co.za>
Message-ID: <4CF3754C.4080705@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:
> 
> After a bit of svn archeology, it does appear that Arabic-Indic digits' support was deliberate at least in the sense that the feature was tested for when the code was first committed. See r15000.

As I mentioned on python-dev (http://mail.python.org/pipermail/python-dev/2010-November/106077.html)
this support was added intentionally.

> The test migrated from file to file over the last 10 years, but it is still present in test_float.py:
> 
>         self.assertEqual(float(b"  \u0663.\u0661\u0664  ".decode('raw-unicode-escape')), 3.14)
> 
> (It should probably be now rewritten using a string literal.)
> 
> I am now attaching the patch (issue10557.diff) that fixes the bug without sacrificing non-ASCII digit support.
> If this approach is well-received, I would like to replace all calls to PyUnicode_EncodeDecimal() with the calls to the new _PyUnicode_EncodeDecimalUTF8() and deprecate Latin-1-oriented PyUnicode_EncodeDecimal().

It would be better to copy and iterate over the Unicode string first,
replacing any decimal code points with ASCII ones and then call the
UTF-8 encoder.

The code as it stands is very inefficient, since it will most likely
run the memcpy() part for every code point after the first non-ASCII
decimal one.

> For the future, I note that starting with Unicode 6.0.0, the Unicode Consortium promises that
> 
> """
> Characters with the property value Numeric_Type=de (Decimal) only occur in contiguous ranges of 10 characters, with ascending numeric values from 0 to 9 (Numeric_Value=0..9).
> """
> 
> This makes it very easy to check a numeric string does not contain a mix of digits from different scripts.

I'm not sure why you'd want to check for such ranges.

> I still believe that proper API should require explicit choice of language or locale before allowing digits other than 0-9 just as int() would not accept hexadecimal digits without explicit choice of base >= 16.  But this would be a subject of a feature request.

Since when do we require a locale or language to be specified when
using Unicode ?

The codecs, Unicode methods and other Unicode support features
happily work with all kinds of languages, mixed or not, without any
such specification.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________

From report at bugs.python.org  Mon Nov 29 12:10:56 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 29 Nov 2010 11:10:56 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>
Message-ID: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>


New submission from Marc-Andre Lemburg <mal at egenix.com>:

The script only patches numeric data into the table (field 8), but does not update the digit field (field 7).

As a result, ideographs used for Chinese digits are not recognized as digits and not evaluated by int(), long() and float():

    http://en.wikipedia.org/wiki/Numbers_in_Chinese_culture

>>> unicode('?', 'utf-8')
u'\u4e09'

>>> int(unicode('?', 'utf-8'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'decimal' codec can't encode character u'\u4e09' in position 0: invalid decimal Unicode string
> <stdin>(1)<module>()

>>> import unicodedata
>>> unicodedata.digit(unicode('?', 'utf-8'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: not a digit

The code point refers to the digit 3.

----------
components: Unicode
messages: 122786
nosy: lemburg
priority: normal
severity: normal
status: open
title: makeunicodedata.py does not support Unihan digit data
versions: Python 2.7, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 12:23:44 2010
From: report at bugs.python.org (Xuanji Li)
Date: Mon, 29 Nov 2010 11:23:44 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291029824.98.0.751579475974.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

What a timely coincidence. I'll try out the change soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Mon Nov 29 12:24:17 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 29 Nov 2010 11:24:17 +0000
Subject: [issue10273] Clean-up Unittest API
In-Reply-To: <1288570422.58.0.20051998916.issue10273@psf.upfronthosting.co.za>
Message-ID: <1291029857.14.0.210648166213.issue10273@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Raymond - I created a new issue for moving the tests: issue 10572

However, it seems that you are incorrect in saying that Python practise is to avoid putting tests inside standard library packages. In fact current Python practise seems to be that where tests themselves are a package they are *always* inside the standard library package and *not* inside Lib/test. For example:  email, distutils, ctypes, importlib, json, lib2to3, sqlite3, tkinter, 

I couldn't see any counter-examples. There are no test packages inside Lib/test (other than leakers that are obviously a category of tests and not tests for a particular package).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10273>
_______________________________________

From report at bugs.python.org  Mon Nov 29 12:28:17 2010
From: report at bugs.python.org (Mark Florisson)
Date: Mon, 29 Nov 2010 11:28:17 +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: <1291030097.08.0.496296621553.issue10566@psf.upfronthosting.co.za>


Mark Florisson <markflorisson88 at gmail.com> added the comment:

I forgot to mention, this patch works with gdb 7.2 or higher, but it does not prevent using other libpython functionality with gdb 7.1 or running the tests with gdb 7.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10566>
_______________________________________

From report at bugs.python.org  Mon Nov 29 12:43:48 2010
From: report at bugs.python.org (MizardX)
Date: Mon, 29 Nov 2010 11:43:48 +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: <1291031028.88.0.2334839952.issue5863@psf.upfronthosting.co.za>


MizardX <mizardx at gmail.com> added the comment:

Would if I could. But, No.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Mon Nov 29 13:02:22 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 29 Nov 2010 12:02:22 +0000
Subject: [issue10561] The pdb command 'clear bpnumber' may delete more than
	one breakpoint
In-Reply-To: <1290944336.84.0.679625072616.issue10561@psf.upfronthosting.co.za>
Message-ID: <1291032142.18.0.573770016263.issue10561@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r86861. Xavier, I noticed that pdb.py itself was not calling the proper method. Added the tests to the patch. Thanks.

BTW, please provide patches against py3k as that is development version.

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10561>
_______________________________________

From report at bugs.python.org  Mon Nov 29 13:10:30 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Nov 2010 12:10:30 +0000
Subject: [issue10262] Add --disable-abi-flags option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1291032630.21.0.90300627044.issue10262@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I agree with the intent: package maintainers, or people compiling python for their own need, should have the right to choose the suffix used by extension modules.

I suggest another option though, one that directly sets the SOABI used in extension file names. This would override both the default SOABI (python3.2) and the flags added to it.
For example, when no flag is passed to ./configure, the default is equivalent to 
    --soabi=cpython3.2m
And we can get the 2.x naming scheme back simply with:
    --soabi=
Yes, this flag should be only used when you know what you are doing.  This builds a version of python that will be unable to load extensions built by other people.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Mon Nov 29 13:15:56 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 29 Nov 2010 12:15:56 +0000
Subject: [issue10262] Add --disable-abi-flags option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1291032956.86.0.619885713908.issue10262@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

I still fail to see the rationale for being able to build with a different soabi name.  But anyway, as long as the default is to build with the soabi name, I'm +/-0 on this option.

Note that the soabi name isn't fixed but changes with other configure options.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Mon Nov 29 13:21:52 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 29 Nov 2010 12:21:52 +0000
Subject: [issue10262] Add --disable-abi-flags option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1291033312.66.0.187137371222.issue10262@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Note that the soabi name isn't fixed but changes with other configure options.
The default value, yes.
But my proposal of a --soabi option would not respect this. The caller is responsible for changing the --soabi value when he adds other options.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Mon Nov 29 13:33:10 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Mon, 29 Nov 2010 12:33:10 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

As discussed here: http://mail.python.org/pipermail/python-ideas/2010-November/008813.html:

Adding the ability to register callbacks to be invoked before and after garbage collection runs.  This can be used to gather run-time statistics such as timing information and frequency of garbage collection runs, and to perform application-specific cleanup of uncollecatable objects from gc.garbage.

The first patch is the code as currently in use in our codebase at CCP (ported from 2.7).  There is only one callback registered and the callback signature is perhaps a bit lame.  Also, no error checking.  But it is shown here for reference and as a basis for discussion.

----------
components: Interpreter Core
files: gccallback1.patch
keywords: patch
messages: 122795
nosy: krisvale
priority: normal
severity: normal
status: open
title: Add a progress callback to gcmodule
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19869/gccallback1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Mon Nov 29 13:41:33 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 29 Nov 2010 12:41:33 +0000
Subject: [issue10561] The pdb command 'clear bpnumber' may delete more than
	one breakpoint
In-Reply-To: <1290944336.84.0.679625072616.issue10561@psf.upfronthosting.co.za>
Message-ID: <1291034493.55.0.402870327658.issue10561@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

r86862 - release31-maint and r86863 - release27-maint.

----------
status: open -> closed
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10561>
_______________________________________

From report at bugs.python.org  Mon Nov 29 14:28:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 13:28:44 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291037324.47.0.389336477949.issue10572@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/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 14:30:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 13:30:53 +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: <1291037453.88.0.999484933585.issue10566@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> dmalcolm
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10566>
_______________________________________

From report at bugs.python.org  Mon Nov 29 14:44:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 13:44:35 +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: <1291038275.71.0.881424720383.issue5863@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

That?s a perfectly fine reply.  Someone will see this feature request and propose a patch eventually.  Another way to help is to write tests, since those are in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Mon Nov 29 14:45:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 13:45:45 +0000
Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does
	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1291038345.18.0.14453954062.issue10571@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg122777

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10571>
_______________________________________

From report at bugs.python.org  Mon Nov 29 14:45:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 13:45:48 +0000
Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does
	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1291038348.71.0.719514746985.issue10571@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg122780

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10571>
_______________________________________

From report at bugs.python.org  Mon Nov 29 14:58:53 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 29 Nov 2010 13:58:53 +0000
Subject: [issue10262] Add --disable-abi-flags option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1291039133.87.0.140917564921.issue10262@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

+0 for Amaury's suggestion in msg122792.  Who wants to write that patch?  I'd happily review it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Mon Nov 29 14:59:20 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 29 Nov 2010 13:59:20 +0000
Subject: [issue10262] Add --soabi option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1291039160.5.0.991707631798.issue10262@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
title: Add --disable-abi-flags option to `configure` -> Add --soabi option to `configure`

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Mon Nov 29 14:59:59 2010
From: report at bugs.python.org (xhresko)
Date: Mon, 29 Nov 2010 13:59:59 +0000
Subject: [issue10577] (Fancy) URL opener stucks whet try to open page
In-Reply-To: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>
Message-ID: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>


New submission from xhresko <juraj.hresko at gmail.com>:

(Fancy) URL opener stucks whet try to open page, which is automaticaly forwarded. I tried url "http://www.ihned.cz", which stuck while "http://ihned.cz" is ok. This type of behavior is different from one in the Python 2.7, which works ok. 

///// CODE
opener = urllib.FancyURLopener({})
f = opener.open("http://www.ihned.cz/")
/////

----------
components: Library (Lib)
messages: 122799
nosy: xhresko
priority: normal
severity: normal
status: open
title: (Fancy) URL opener stucks whet try to open page
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10577>
_______________________________________

From report at bugs.python.org  Mon Nov 29 15:05:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 14:05:41 +0000
Subject: [issue6671] webbrowser doesn't respect xfce default browser
In-Reply-To: <1249814125.92.0.530552321419.issue6671@psf.upfronthosting.co.za>
Message-ID: <1291039541.27.0.247887427547.issue6671@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Gajim lists processes thanks to /proc, which is platform-specific; a Web search shows the use of pidof, to the same effect; I looked for an envvar (I use Xfce) and found nothing.

----------
nosy: +eric.araujo
title: webbrowser.py doesn't respect xfce default browser -> webbrowser doesn't respect xfce default browser

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6671>
_______________________________________

From report at bugs.python.org  Mon Nov 29 15:06:36 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Mon, 29 Nov 2010 14:06:36 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291039596.05.0.61260008426.issue10576@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/issue10576>
_______________________________________

From report at bugs.python.org  Mon Nov 29 15:08:32 2010
From: report at bugs.python.org (SilentGhost)
Date: Mon, 29 Nov 2010 14:08:32 +0000
Subject: [issue10577] (Fancy) URL opener stuck when trying to open redirected
	url
In-Reply-To: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>
Message-ID: <1291039712.88.0.22750479103.issue10577@psf.upfronthosting.co.za>


Changes by SilentGhost <michael.mischurow+bpo at gmail.com>:


----------
title: (Fancy) URL opener stucks whet try to open page -> (Fancy) URL opener stuck when trying to open redirected url

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10577>
_______________________________________

From report at bugs.python.org  Mon Nov 29 15:09:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 14:09:33 +0000
Subject: [issue10578] Add mock PyPI server to test distutils
In-Reply-To: <1291039773.01.0.204662376507.issue10578@psf.upfronthosting.co.za>
Message-ID: <1291039773.01.0.204662376507.issue10578@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

In distutils2, we have a mock PyPI server to test index-related behavior, but in distutils we fix such things without automated tests.  I would like to add the mock server to distutils.

----------
assignee: tarek
components: Distutils, Tests
messages: 122801
nosy: eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Add mock PyPI server to test distutils
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10578>
_______________________________________

From report at bugs.python.org  Mon Nov 29 15:10:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 14:10:14 +0000
Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does
	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1291039814.19.0.783512167166.issue10571@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you for the report.  Do you want to propose a patch?

----------
assignee: tarek -> eric.araujo
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10571>
_______________________________________

From report at bugs.python.org  Mon Nov 29 15:12:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 14:12:15 +0000
Subject: [issue10559] NameError in tutorial/interpreter
In-Reply-To: <1290923300.31.0.847319957553.issue10559@psf.upfronthosting.co.za>
Message-ID: <1291039935.23.0.140125873896.issue10559@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

What about:

?You need to execute ``import sys`` before you can use ``sys.argv``.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10559>
_______________________________________

From report at bugs.python.org  Mon Nov 29 15:17:05 2010
From: report at bugs.python.org (SilentGhost)
Date: Mon, 29 Nov 2010 14:17:05 +0000
Subject: [issue10577] (Fancy) URL opener stuck when trying to open redirected
	url
In-Reply-To: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>
Message-ID: <1291040225.66.0.68993592027.issue10577@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

@xhresko: This is not valid py3k code.

It is 302 redirect. I get the following error:

IOError: [Errno socket error] [Errno 10060] A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

----------
nosy: +SilentGhost

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10577>
_______________________________________

From report at bugs.python.org  Mon Nov 29 15:22:42 2010
From: report at bugs.python.org (SilentGhost)
Date: Mon, 29 Nov 2010 14:22:42 +0000
Subject: [issue10577] (Fancy) URL opener stuck when trying to open redirected
	url
In-Reply-To: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>
Message-ID: <1291040562.0.0.266223136141.issue10577@psf.upfronthosting.co.za>


SilentGhost <michael.mischurow+bpo at gmail.com> added the comment:

@xhresko: why are you passing empty dict to the constructor? it works just fine with opener = urllib.request.FancyURLopener() 

resolution: invalid ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10577>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:02:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 15:02:31 +0000
Subject: [issue4214] no extension debug info with msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <1291042951.64.0.959216742087.issue4214@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for explaining.  Is someone willing to add a test in test_msvc9compiler?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4214>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:05:06 2010
From: report at bugs.python.org (Jakub Wilk)
Date: Mon, 29 Nov 2010 15:05:06 +0000
Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does
	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1291043106.23.0.107431425924.issue10571@psf.upfronthosting.co.za>


Jakub Wilk <jwilk at jwilk.net> added the comment:

Patch attached.

----------
keywords: +patch
Added file: http://bugs.python.org/file19870/issue10571.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10571>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:12:37 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Nov 2010 15:12:37 +0000
Subject: [issue10578] Add mock PyPI server to test distutils
In-Reply-To: <1291039773.01.0.204662376507.issue10578@psf.upfronthosting.co.za>
Message-ID: <1291043557.69.0.591902438428.issue10578@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Please no more enhancements in distutils ! even in the tests.

Distutils is on maintenance mode, and we need to do the bare minimum there. we need to do the minimum changes.

If there's a bug in PyPI related code in distutils, you need to do this:

- fix the bug in distutils2, with the mock server + a test
- backport the bugfix only

----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10578>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:15:40 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 29 Nov 2010 15:15:40 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>
Message-ID: <1291043740.62.0.294053403052.issue10575@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The code point is also not listed as decimal digit (relevant for the int() decimal parsing):

>>> unicodedata.decimal(unicode('?', 'utf-8'))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: not a decimal

This is the relevant part of the script:

        for line in open(unihan):
            if not line.startswith('U+'):
                continue
            code, tag, value = line.split(None, 3)[:3]
            if tag not in ('kAccountingNumeric', 'kPrimaryNumeric',
                           'kOtherNumeric'):
                continue
            value = value.strip().replace(',', '')
            i = int(code[2:], 16)
            # Patch the numeric field
            if table[i] is not None:
                table[i][8] = value

The decimal column is not set for code points that have a kPrimaryNumeric value set. Position table[i][8] refers to the
numeric database entry, which correctly gives:

>>> unicodedata.numeric(unicode('?', 'utf-8'))
3.0

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:16:08 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Mon, 29 Nov 2010 15:16:08 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1291043768.82.0.420491164239.issue10541@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

OK, I reran the test with::

   ./python -mtest.regrtest -T -N test_urllib

and this does indeed produce coverage files (for _abcoll, _weakrefset, abc, base64, codecs, collections, contextlib, functools, genericpath, hashlib, locale, mimetypes, os, posixpath, quopri, random, re, sre_compile, sre_parse, ssl, stat, tempfile, textwrap, trace, uu, warnings).

However running the complete test suite via::

   ./python -mtest.regrtest -T -N -uurlfetch,largefile,network,decimal

fails with::

Not printing coverage data for '/tmp/tmp0fdr9o/t4/sub/subsub/__init__.py': [Errno 2] No such file or directory: '/tmp/tmp0fdr9o/t4/sub/subsub/__init__.py'
Traceback (most recent call last):
  File "/home/coverage/python/Lib/runpy.py", line 160, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/home/coverage/python/Lib/runpy.py", line 73, in _run_code
    exec(code, run_globals)
  File "/home/coverage/python/Lib/test/regrtest.py", line 1502, in <module>
    main()
  File "/home/coverage/python/Lib/test/regrtest.py", line 698, in main
    r.write_results(show_missing=True, summary=True, coverdir=coverdir)
  File "/home/coverage/python/Lib/trace.py", line 331, in write_results
    with open(filename, 'rb') as fp:
IOError: [Errno 2] No such file or directory: '/tmp/tmp0fdr9o/t4/sub/subsub/__init__.py'
sys:1: ResourceWarning: unclosed file <_io.TextIOWrapper name='/dev/null' encoding='ANSI_X3.4-1968'>

(attached is the complete output of running the test suite (build2.log).)

----------
Added file: http://bugs.python.org/file19871/build2.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:16:17 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 29 Nov 2010 15:16:17 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>
Message-ID: <1291043777.66.0.641051162067.issue10575@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Here's a quick overview of the fields that are set for U+4E09:

http://www.fileformat.info/info/unicode/char/4e09/index.htm

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:17:24 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 29 Nov 2010 15:17:24 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>
Message-ID: <1291043844.38.0.904181171533.issue10575@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

This is the definition of kPrimaryNumeric

http://ftp.lanet.lv/ftp/mirror/unicode/5.0.0/ucd/Unihan.html#kPrimaryNumeric

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:29:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 15:29:23 +0000
Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does
	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1291044563.59.0.325763306932.issue10571@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thank you.  I?ll apply after #10578 is solved.

----------
dependencies: +Add mock PyPI server to test distutils

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10571>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:34:25 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Nov 2010 15:34:25 +0000
Subject: [issue10571] "setup.py upload --sign" broken: TypeError: 'str' does
	not support the buffer interface
In-Reply-To: <1290987539.61.0.7684972104.issue10571@psf.upfronthosting.co.za>
Message-ID: <1291044865.02.0.66879724359.issue10571@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Eric: #10578 will not happen in Distutils1.

You need to add a test in distutils2, apply the bugfix there, then apply Jakub's patch in distutils1

----------
components: +Distutils2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10571>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:34:39 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Nov 2010 15:34:39 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291044879.94.0.930142181336.issue10572@psf.upfronthosting.co.za>


Ezio Melotti <ezio.melotti at gmail.com> added the comment:

3.1 should also be considered if the tests are moved.  In theory this is not a bug fix so it shouldn't go in 3.1, but in practice it will make merging more difficult.  This might not be a strong argument though, considering that 3.1 will accept only security fixes soon and only the few developers that work on unittest will be affected.

----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:39:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 15:39:52 +0000
Subject: [issue10557] Malformed error message from float()
In-Reply-To: <4CF3754C.4080705@egenix.com>
Message-ID: <AANLkTi=Yfy=wpLDwrP2jTFCbsPWbXGjz0pG_mcg_1iL0@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Nov 29, 2010 at 4:41 AM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> It would be better to copy and iterate over the Unicode string first,
> replacing any decimal code points with ASCII ones and then call the
> UTF-8 encoder.
>

Good idea.

> The code as it stands is very inefficient, since it will most likely
> run the memcpy() part for every code point after the first non-ASCII
> decimal one.
>

I doubt there are measurable gains from this optimization, but doing
conversion in Unicode characters results in cleaner API.  The new
patch, issue10557a.diff, implements
_PyUnicode_NormalizeDecimal(Py_UNICODE *s, Py_ssize_t length) which is
defined as follows:

/* Strip leading and trailing space and convert code points that have
decimal
   digit property to the corresponding ASCII digit code point.

   Returns a new Unicode string on success, NULL on failure.
*/

Note that I used deprecated _PyUnicode_AsStringAndSize() in
floatobject.c not only because it is convenient, but also because I
believe that in the future numerical value parsers should be converted
to operate on unicode characters.  When this happens, the use of
_PyUnicode_AsStringAndSize() can be removed.

----------
Added file: http://bugs.python.org/file19872/issue10557a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10557>
_______________________________________
-------------- next part --------------
Index: Include/unicodeobject.h
===================================================================
--- Include/unicodeobject.h	(revision 86843)
+++ Include/unicodeobject.h	(working copy)
@@ -1173,6 +1173,17 @@
     const char *errors          /* error handling */
     );
 
+/* Strip leading and trailing space and convert code points that have decimal
+   digit property to the corresponding ASCII digit code point. 
+
+   Returns a new Unicode string on success, NULL on failure.
+*/
+
+PyAPI_FUNC(PyObject*) _PyUnicode_NormalizeDecimal(
+    Py_UNICODE *s,              /* Unicode buffer */
+    Py_ssize_t length           /* Number of Py_UNICODE chars to encode */
+    );
+
 /* --- File system encoding ---------------------------------------------- */
 
 /* ParseTuple converter: encode str objects to bytes using
Index: Objects/unicodeobject.c
===================================================================
--- Objects/unicodeobject.c	(revision 86843)
+++ Objects/unicodeobject.c	(working copy)
@@ -6207,6 +6207,40 @@
     return NULL;
 }
 
+PyObject *
+_PyUnicode_NormalizeDecimal(Py_UNICODE *s,
+                            Py_ssize_t length)
+{
+    PyObject *result;
+    Py_UNICODE *p; /* write pointer into result */
+    const Py_UNICODE *end = s + length;
+    Py_ssize_t i;
+    /* Strip whitespace */
+    while (s < end) {
+        if (Py_UNICODE_ISSPACE(*s))
+            s++;
+        else if (Py_UNICODE_ISSPACE(end[-1]))
+            end--;
+        else
+            break;
+    }
+    length = end - s;
+    /* Copy to a new string */
+    result = PyUnicode_FromUnicode(s, length);
+    if (result == NULL)
+        return result;
+    p = PyUnicode_AS_UNICODE(result);
+    /* Iterate over code points */
+    for (i = 0; i < length; i++) {
+        Py_UNICODE ch = p[i];
+        if (!Py_ISDIGIT(ch)) {
+            int decimal = Py_UNICODE_TODECIMAL(ch);
+            if (decimal >= 0)
+                p[i] = '0' + decimal;
+        }
+    }
+    return result;
+}
 /* --- Decimal Encoder ---------------------------------------------------- */
 
 int PyUnicode_EncodeDecimal(Py_UNICODE *s,
Index: Objects/floatobject.c
===================================================================
--- Objects/floatobject.c	(revision 86843)
+++ Objects/floatobject.c	(working copy)
@@ -175,52 +175,53 @@
 {
     const char *s, *last, *end;
     double x;
-    char buffer[256]; /* for errors */
-    char *s_buffer = NULL;
+    PyObject *s_buffer = NULL;
     Py_ssize_t len;
     PyObject *result = NULL;
 
     if (PyUnicode_Check(v)) {
-        s_buffer = (char *)PyMem_MALLOC(PyUnicode_GET_SIZE(v)+1);
+        s_buffer = _PyUnicode_NormalizeDecimal(PyUnicode_AS_UNICODE(v),
+                                               PyUnicode_GET_SIZE(v));
         if (s_buffer == NULL)
-            return PyErr_NoMemory();
-        if (PyUnicode_EncodeDecimal(PyUnicode_AS_UNICODE(v),
-                                    PyUnicode_GET_SIZE(v),
-                                    s_buffer,
-                                    NULL))
-            goto error;
-        s = s_buffer;
-        len = strlen(s);
+            return NULL;
+        s = _PyUnicode_AsStringAndSize(s_buffer, &len);
+        if (s == NULL)
+            return NULL;
+        last = s + len;
     }
     else if (PyObject_AsCharBuffer(v, &s, &len)) {
         PyErr_SetString(PyExc_TypeError,
             "float() argument must be a string or a number");
         return NULL;
     }
-    last = s + len;
-
-    while (Py_ISSPACE(*s))
-        s++;
+    else {
+        last = s + len;
+        /* strip space */
+        while (last - s > 0) { 
+            if (Py_ISSPACE(*s))
+                s++;
+            else if (Py_ISSPACE(last[- 1]))
+                last--;
+            else
+                break;
+        }
+    }
     /* We don't care about overflow or underflow.  If the platform
      * supports them, infinities and signed zeroes (on underflow) are
      * fine. */
     x = PyOS_string_to_double(s, (char **)&end, NULL);
-    if (x == -1.0 && PyErr_Occurred())
-        goto error;
-    while (Py_ISSPACE(*end))
-        end++;
-    if (end == last)
-        result = PyFloat_FromDouble(x);
-    else {
-        PyOS_snprintf(buffer, sizeof(buffer),
-                      "invalid literal for float(): %.200s", s);
-        PyErr_SetString(PyExc_ValueError, buffer);
+    if (end != last) {
+        PyErr_Format(PyExc_ValueError,
+                     "could not convert string to float: "
+                     "%.200s", s);
         result = NULL;
     }
-
-  error:
-    if (s_buffer)
-        PyMem_FREE(s_buffer);
+    else if (x == -1.0 && PyErr_Occurred())
+        result = NULL;
+    else
+        result = PyFloat_FromDouble(x);
+    
+    Py_XDECREF(s_buffer);
     return result;
 }
 

From report at bugs.python.org  Mon Nov 29 16:42:31 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 29 Nov 2010 15:42:31 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291045351.34.0.562278817468.issue10572@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

The same is true for 2.7 though, and that is getting bug fixes. svnmerge would no longer work (and to making the change would mean moving the tests in a point release).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:52:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 15:52:22 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291045942.14.0.234571040495.issue10572@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

+0, and I think we should hear from the maintainers of the affected packages first.  For packages that are also externally maintained moving tests out may cause inconvenience to the maintainer.

----------
nosy: +barry, belopolsky, brett.cannon, ghaering, r.david.murray, rhettinger, tarek, theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:53:48 2010
From: report at bugs.python.org (Xuanji Li)
Date: Mon, 29 Nov 2010 15:53:48 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291046028.01.0.353703845626.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

Changed according to Raymond's suggestion. I realized that there are some classes (str, bytes, array.array) that are iterable but should not be handled by the iteration logic provided by catlee. eg: if we iterate through b'a message' we'd get a bunch of ints and sending them is wrong. patch attached.

----------
Added file: http://bugs.python.org/file19873/issue_3243_py3k_2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:57:06 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 29 Nov 2010 15:57:06 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291046226.79.0.993414562865.issue10572@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

That list of examples was non-exhaustive, there is also tkinter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 16:58:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 15:58:04 +0000
Subject: [issue10578] Add mock PyPI server to test distutils
In-Reply-To: <1291039773.01.0.204662376507.issue10578@psf.upfronthosting.co.za>
Message-ID: <1291046284.27.0.161589484241.issue10578@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The more the codebases become different, the more difficult it will be to be sure some fix in d2 also fixes d1.  I?ll live with it or use pypi_server on my own machine :)

Thanks for the pronouncement.

----------
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10578>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:00:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Nov 2010 16:00:08 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291046408.91.0.922821752229.issue3243@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the patch.

First, you don't need to support str, since sockets only accept binary strings (not unicode).

Second, I think it's simpler and more generic to do something like:

  try:
      self.sock.sendall(data)
  except TypeError:
      try:
          it = iter(data)
      except TypeError:
          raise TypeError("data should be a bytes-like object or "
              "an iterable, got %r" % type(it))
      for d in t:
          self.sock.sendall(d)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:00:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 16:00:39 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291046439.17.0.162250985401.issue10572@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:17:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 16:17:30 +0000
Subject: [issue8260] When I use codecs.open(...) and f.readline() follow up by
	f.read() return bad result
In-Reply-To: <1269875395.81.0.132261115225.issue8260@psf.upfronthosting.co.za>
Message-ID: <1291047450.52.0.343362950497.issue8260@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I applied the diff to test_codecs in py3k, removed the u prefixes and ran: failure.  I applied the fix and the test passed.

----------
nosy: +eric.araujo
title: When I use codecs.open(...) and f.readline() follow up by	f.read() return bad result -> When I use codecs.open(...) and f.readline() follow up by f.read() return bad result
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8260>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:18:37 2010
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 29 Nov 2010 16:18:37 +0000
Subject: [issue10579] Is ``o[key]`` equivalent to PyMapping_HasKeyString?
In-Reply-To: <1291047517.36.0.54391686166.issue10579@psf.upfronthosting.co.za>
Message-ID: <1291047517.36.0.54391686166.issue10579@psf.upfronthosting.co.za>


New submission from INADA Naoki <songofacandy at gmail.com>:

http://docs.python.org/c-api/mapping.html#PyMapping_HasKeyString
and
http://docs.python.org/c-api/mapping.html#PyMapping_HasKey
says:
> This is equivalent to ``o[key]``

I think it should be ``key in o``.

----------
assignee: docs at python
components: Documentation
messages: 122824
nosy: docs at python, naoki
priority: normal
severity: normal
status: open
title: Is ``o[key]`` equivalent to PyMapping_HasKeyString?
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10579>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:19:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 16:19:24 +0000
Subject: [issue7885] test_distutils fails if Python built in separate directory
In-Reply-To: <1265647953.87.0.513905112062.issue7885@psf.upfronthosting.co.za>
Message-ID: <1291047564.44.0.967715533427.issue7885@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> eric.araujo
nosy: +dmalcolm, eric.araujo
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7885>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:22:41 2010
From: report at bugs.python.org (INADA Naoki)
Date: Mon, 29 Nov 2010 16:22:41 +0000
Subject: [issue10579] Is ``o[key]`` equivalent to PyMapping_HasKeyString?
In-Reply-To: <1291047517.36.0.54391686166.issue10579@psf.upfronthosting.co.za>
Message-ID: <1291047761.96.0.720817562202.issue10579@psf.upfronthosting.co.za>


INADA Naoki <songofacandy at gmail.com> added the comment:

I'm sorry, I've misreaded.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10579>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:24:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 16:24:49 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1291047889.01.0.416487382489.issue2876@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/issue2876>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:25:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 16:25:41 +0000
Subject: [issue2046] patch to fix_import: UserDict -> collections
In-Reply-To: <1202427848.74.0.973500196502.issue2046@psf.upfronthosting.co.za>
Message-ID: <1291047941.58.0.212422943551.issue2046@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
superseder:  -> Write UserDict fixer for 2to3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2046>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:25:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 16:25:48 +0000
Subject: [issue2876] Write UserDict fixer for 2to3
In-Reply-To: <1210913348.4.0.543107843307.issue2876@psf.upfronthosting.co.za>
Message-ID: <1291047948.97.0.834230139442.issue2876@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
superseder: patch to fix_import: UserDict -> collections -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2876>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:27:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 16:27:48 +0000
Subject: [issue6886] cgi.py runs python, not python3
In-Reply-To: <1252695717.33.0.0393751627357.issue6886@psf.upfronthosting.co.za>
Message-ID: <1291048068.61.0.50790265993.issue6886@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> "make altinstall" installs many files with incorrect shebangs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6886>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:35:10 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 29 Nov 2010 16:35:10 +0000
Subject: [issue10578] Add mock PyPI server to test distutils
In-Reply-To: <1291039773.01.0.204662376507.issue10578@psf.upfronthosting.co.za>
Message-ID: <1291048510.96.0.353025279604.issue10578@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I don't think this will be a huge problem, given the low amount of bugs we have for all code involving PyPI. Other bugfix can be backported w/ their tests most of the time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10578>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:45:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 16:45:35 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>
Message-ID: <1291049135.12.0.141498499562.issue10575@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am adding #10552 as a dependency because I think we should fix unicode data generation in 3.x before adding new features to the scripts.

I am also not sure whether this is a bug or a feature request. Martin?

----------
dependencies: +Tools/unicode/gencodec.py error
nosy: +belopolsky, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:49:02 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Mon, 29 Nov 2010 16:49:02 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>
Message-ID: <1291049342.42.0.854415473472.issue10575@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/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:54:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Nov 2010 16:54:39 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291049679.12.0.480542946681.issue10572@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For the email package I would be in favor of moving the tests to Lib/test.  I've always found it a bit inconvenient that they are in Lib/email.  After hearing of Michael's intent with unittest, and given the evolution of email5 into email5.1, I am also considering the possibility of packaging email6 (when I get to it!) as a patch set against email5, which would make this change less of an issue for email6 development.

The 2.7 sync issue is a concern, but there are certainly precedents for differing file layouts between 3.x and 2.7.  I'm willing myself to deal with this for email.

Barry may have a different opinion.

All of that said, this is a general enough issue that it may be appropriate to raise it on python-dev.  Even if exceptions are made for individual packages, it would be good to agree on a general "best practices" rule for this for the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 17:57:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 16:57:46 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za>
Message-ID: <1291049866.52.0.365729452675.issue10552@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Martin,

I believe you were the last to update the unicode database. (See r85371.)  Did you use python2.x to generate it or you have your own private copy of these tools?

I noticed that genwincodecs.bat refers to c:\python26\python in 2.7 branch and c:\python30\python in py3k.  Could this be an indication that these tools are out of date?

What is the plan for maintaining these tools?  Should fixes be done in 2.7 and 3.x be generated by 2to3? Or should fixes go to py3k and backported to 2.7 when they don't add new features?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Mon Nov 29 18:04:30 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 29 Nov 2010 17:04:30 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291050270.86.0.524596105346.issue10572@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

grepping the code without the tests doesn't seem that compelling a use case to me, given that grep and find both provide options to prune directories.  I do think that moving the tests out of the email package will make it harder to maintain and distribute as a separate package.  However, if RDM thinks the burden won't be too high, and the advantages of a split outweigh the disadvantages, then I defer to him.  I would still make a case for distributing email6 as a package available on Cheeseshop though, otherwise it just won't get much independent use until it's in the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 18:51:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Nov 2010 17:51:35 +0000
Subject: [issue10577] (Fancy) URL opener stuck when trying to open redirected
	url
In-Reply-To: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>
Message-ID: <1291053095.5.0.677648990799.issue10577@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can reproduce the issue with 3.2 here. Using Wireshark, I see that the request to http://www.ihnez.cz is satisfied, but the second request (to http://ihnez.cz) is never issued. Here is the Wireshark dump for the TCP session (request, then response):

"""GET / HTTP/1.1

Accept-Encoding: identity

Host: www.ihned.cz

User-Agent: Python-urllib/3.2



HTTP/1.1 302 Found

Server: nginx

Date: Mon, 29 Nov 2010 17:41:23 GMT

Content-Type: text/html; charset=WINDOWS-1250

Transfer-Encoding: chunked

Connection: keep-alive

Location: http://ihned.cz/



0

"""



Looking at the traceback when pressing Control-C, it seems the redirect handler in urllib expects the socket to be closed by the server, but it isn't; so it keeps waiting for more data (despite the "0" signifying the end of the chunked response):

>>> import urllib.request
>>> opener = urllib.request.FancyURLopener()
>>> f = opener.open("http://www.ihned.cz/")
^CTraceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/antoine/py3k/__svn__/Lib/urllib/request.py", line 1504, in open
    return getattr(self, name)(url)
  File "/home/antoine/py3k/__svn__/Lib/urllib/request.py", line 1676, in open_http
    return self._open_generic_http(http.client.HTTPConnection, url, data)
  File "/home/antoine/py3k/__svn__/Lib/urllib/request.py", line 1672, in _open_generic_http
    response.status, response.reason, response.msg, data)
  File "/home/antoine/py3k/__svn__/Lib/urllib/request.py", line 1688, in http_error
    result = method(url, fp, errcode, errmsg, headers)
  File "/home/antoine/py3k/__svn__/Lib/urllib/request.py", line 1876, in http_error_302
    data)
  File "/home/antoine/py3k/__svn__/Lib/urllib/request.py", line 1887, in redirect_internal
    void = fp.read()
  File "/home/antoine/py3k/__svn__/Lib/socket.py", line 267, in readinto
    return self._sock.recv_into(b)
KeyboardInterrupt


However, urllib.request.urlopen() works fine in this case, so perhaps this advocates for deprecating the old stuff? Senthil?

----------
assignee:  -> orsenthil
nosy: +orsenthil, pitrou
versions: +Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10577>
_______________________________________

From report at bugs.python.org  Mon Nov 29 18:51:55 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 29 Nov 2010 17:51:55 +0000
Subject: [issue10580] Installer sentence in bold
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

The installer of Python should have consistent sentences, the ones in bold.

There's one sentence that needs fixing. The sentence "Completing the Python x.x.x Installer" should be "Complete the Python x.x.x Installer", because other sentences are in the form of "Install xxx" and "Customize xxx" (they are not written as "Installing xxx" and "Customizing xxx"). Please fix this.

----------
components: Installation
messages: 122832
nosy: Retro
priority: normal
severity: normal
status: open
title: Installer sentence in bold
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10580>
_______________________________________

From report at bugs.python.org  Mon Nov 29 18:55:03 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 29 Nov 2010 17:55:03 +0000
Subject: [issue10580] Installer sentence in bold
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <1291053303.29.0.454196293003.issue10580@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

What installer?

Please provide a patch.

----------
nosy: +brian.curtin
priority: normal -> low
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10580>
_______________________________________

From report at bugs.python.org  Mon Nov 29 18:55:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 17:55:58 +0000
Subject: [issue10581] Review and document string format accepted in numeric
	data type constructors
In-Reply-To: <1291053358.57.0.165550567454.issue10581@psf.upfronthosting.co.za>
Message-ID: <1291053358.57.0.165550567454.issue10581@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

I am opening a new report to continue work on the issues raised in #10557 that are either feature requests or documentation bugs.

The rest is my reply to the relevant portions of Marc's comment at msg122785.

On Mon, Nov 29, 2010 at 4:41 AM, Marc-Andre Lemburg <report at bugs.python.org> wrote:
..
> Alexander Belopolsky wrote:
>>
>> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>>
>> After a bit of svn archeology, it does appear that Arabic-Indic
>> digits' support was deliberate at least in the sense that the
>> feature was tested for when the code was first committed. See r15000.
>
> As I mentioned on python-dev (http://mail.python.org/pipermail/python-dev/2010-November/106077.html)
> this support was added intentionally.
>
>> The test migrated from file to file over the last 10 years, but it
>> is still present in test_float.py:
>>
>> ? ? ? ? self.assertEqual(float(b" ?\u0663.\u0661\u0664 ?".decode('raw-unicode-escape')), 3.14)
>>
>> (It should probably be now rewritten using a string literal.)
>>
..
>> For the future, I note that starting with Unicode 6.0.0,
>> the Unicode Consortium promises that
>>
>> """
>> Characters with the property value Numeric_Type=de (Decimal) only
>> occur in contiguous ranges of 10 characters, with ascending numeric
>> values from 0 to 9 (Numeric_Value=0..9).
>> """
>>
>> This makes it very easy to check a numeric string does not contain
>> a mix of digits from different scripts.
>
> I'm not sure why you'd want to check for such ranges.
>

In order to disallow a mix of say Arabic-Indic and Bengali digits.  Such combinations cannot be defended as possibly valid numbers in any script.

>> I still believe that proper API should require explicit choice of
>> language or locale before allowing digits other than 0-9 just as
>> int() would not accept hexadecimal digits without explicit choice of
>> base >= 16. ?But this would be a subject of a feature request.
>
> Since when do we require a locale or language to be specified when
> using Unicode ?
>

This is a valid question.  I may be in minority, but I find it convenient to use int(), float() etc. for data validation.  If my program gets a CSV file with Arabic-Indic digits, I want to fire the guy who prepared it before it causes real issues. :-)  I may be too strict, but I don't think anyone would want to see columns with a mix of Bengali and Devanagari numerals.

On the other hand there is certain convenience in promiscuous parsers, but this is not an expectation that I have from int() and friends.  int('0xFF') requires me to specify base even though 0xFF is a perfectly valid notation.

There are pros and cons in any approach.  Let's figure out what is better before we fix the documentation.

> The codecs, Unicode methods and other Unicode support features
> happily work with all kinds of languages, mixed or not, without any
> such specification.

In my view int() and friends are only marginally related to Unicode and Unicode methods design is not directly relevant to their behavior.  If we were designing str.todigits(), by all means, I would argue that it must be consistent with str.isdigit().  For numeric data, however, I think we should follow the logic that rejected int('0xFF').

This is my opinion.  We can consider allowing int('0xFF') as well.  Let's discuss.

----------
assignee: belopolsky
components: Documentation, Interpreter Core
messages: 122834
nosy: belopolsky, eric.smith, ezio.melotti, haypo, lemburg, mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: Review and document string format accepted in numeric data type constructors
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10581>
_______________________________________

From report at bugs.python.org  Mon Nov 29 18:57:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 17:57:57 +0000
Subject: [issue10581] Review and document string format accepted in numeric
	data type constructors
In-Reply-To: <1291053358.57.0.165550567454.issue10581@psf.upfronthosting.co.za>
Message-ID: <1291053477.71.0.112719226616.issue10581@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

See also issue 9574 for a somewhat related discussion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10581>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:01:46 2010
From: report at bugs.python.org (SilentGhost)
Date: Mon, 29 Nov 2010 18:01:46 +0000
Subject: [issue10577] (Fancy) URL opener stuck when trying to open redirected
	url
In-Reply-To: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>
Message-ID: <1291053706.34.0.0946586084365.issue10577@psf.upfronthosting.co.za>


Changes by SilentGhost <michael.mischurow+bpo at gmail.com>:


----------
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10577>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:01:59 2010
From: report at bugs.python.org (SilentGhost)
Date: Mon, 29 Nov 2010 18:01:59 +0000
Subject: [issue10577] (Fancy) URL opener stuck when trying to open redirected
	url
In-Reply-To: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>
Message-ID: <1291053719.84.0.999379546317.issue10577@psf.upfronthosting.co.za>


Changes by SilentGhost <michael.mischurow+bpo at gmail.com>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10577>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:04:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Nov 2010 18:04:40 +0000
Subject: [issue10577] (Fancy) URL opener stuck when trying to open redirected
	url
In-Reply-To: <1291039199.23.0.655972335921.issue10577@psf.upfronthosting.co.za>
Message-ID: <1291053880.4.0.959323533669.issue10577@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

That line of code (`void = fp.read()`) dates back to a commit by Guido in 1995, and isn't motivated by any comment or message. HTTP servers probably have evolved till then :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10577>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:16:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Nov 2010 18:16:59 +0000
Subject: [issue10541] regrtest.py -T broken
In-Reply-To: <1290787334.28.0.0735858321707.issue10541@psf.upfronthosting.co.za>
Message-ID: <1291054619.77.0.0368412826808.issue10541@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: haypo -> 
resolution: invalid -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10541>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:21:57 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 29 Nov 2010 18:21:57 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <1291049866.52.0.365729452675.issue10552@psf.upfronthosting.co.za>
Message-ID: <4CF3EF41.5090808@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

gencodec.py is only rarely used, namely when adding new codecs based
on Unicode mapping files.

It is not run regularly on the files from ftp.unicode.org and only
updated on demand.

AFAIK, it was last used on Python2 and never on Python3, hence the
errors you find with it.

BTW: You appear to have a comma appended to the constant, that doesn't
belong there:

+# Placeholder for a missing codepoint
+MISSING_CODE = -1,
+

Perhaps that's causing the second error you are seeing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:24:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 29 Nov 2010 18:24:38 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291055078.6.0.0754228114617.issue10572@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, a cheeseshop package is definitely part of the plan, I didn't mean to imply otherwise.  It won't be hard to automate the packaging, and indeed I'll wind up doing that anyway even if the tests stay inside Lib/email.

I will say that that I'm probably only +0.5 on this change...I like it from a consistency standpoint (heading toward all stdlib tests being in Lib/test) and it seems like it would make the job of packagers who desire a 'no tests' option easier.  But things have been working fine as they are, which is why I'm not at a full +1 :).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:29:03 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 29 Nov 2010 18:29:03 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291049135.12.0.141498499562.issue10575@psf.upfronthosting.co.za>
Message-ID: <4CF3F0EA.3090308@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 adding #10552 as a dependency because I think we should fix unicode data generation in 3.x before adding new features to the scripts.
> 
> I am also not sure whether this is a bug or a feature request. Martin?

I consider this a bug (which is why I added Python 2.7 to the list
of versions), since those code points need to be mapped to decimal
and digit as well (see the references I posted; and compare ).

Both Chinese and Japanese use the 4E00 ff. code points as decimal
code points.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:32:50 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Mon, 29 Nov 2010 18:32:50 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291055570.94.0.280730588873.issue10576@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

These functions will be very useful for any long-running program.  Thank you for the patch.

Would you be willing to write tests and documentation?

Would it make more sense for the callback to take a boolean instead of an integer as the first argument?

----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:35:42 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 18:35:42 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291055742.46.0.795102326119.issue10572@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

For distutils tests, I?m ?0.  I don?t see any major drawback nor any major benefit.  Tarek will decide.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:36:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 18:36:47 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <4CF3EF41.5090808@egenix.com>
Message-ID: <AANLkTi=_3q3e-+XkuJx1WbuoZyOtuUuf4z+=bRj7ZVC2@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Nov 29, 2010 at 1:21 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> BTW: You appear to have a comma appended to the constant, that doesn't
> belong there:
>
> +# Placeholder for a missing codepoint
> +MISSING_CODE = -1,
> +
>
> Perhaps that's causing the second error you are seeing.

No, that comma was a left-over from the attempt to fix the
mac_chinsimp error.  The trace that I reported was generated with
MISSING_CODE = -1.   I am replacing the patch.

Is it ok to commit a partial fix?  It may take longer to fix the mac error.

----------
Added file: http://bugs.python.org/file19874/issue10552a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________
-------------- next part --------------
Index: Tools/unicode/gencodec.py
===================================================================
--- Tools/unicode/gencodec.py	(revision 86837)
+++ Tools/unicode/gencodec.py	(working copy)
@@ -34,6 +34,9 @@
 # Standard undefined Unicode code point
 UNI_UNDEFINED = chr(0xFFFE)
 
+# Placeholder for a missing codepoint
+MISSING_CODE = -1
+
 mapRE = re.compile('((?:0x[0-9a-fA-F]+\+?)+)'
                    '\s+'
                    '((?:(?:0x[0-9a-fA-Z]+|<[A-Za-z]+>)\+?)*)'
@@ -52,7 +55,7 @@
 
     """
     if not codes:
-        return None
+        return MISSING_CODE
     l = codes.split('+')
     if len(l) == 1:
         return int(l[0],16)
@@ -60,8 +63,8 @@
         try:
             l[i] = int(l[i],16)
         except ValueError:
-            l[i] = None
-    l = [x for x in l if x is not None]
+            l[i] = MISSING_CODE
+    l = [x for x in l if x != MISSING_CODE]
     if len(l) == 1:
         return l[0]
     else:
@@ -113,7 +116,7 @@
     # mappings to None for the rest
     if len(identity) >= len(unmapped):
         for enc in unmapped:
-            enc2uni[enc] = (None, "")
+            enc2uni[enc] = (MISSING_CODE, "")
         enc2uni['IDENTITY'] = 256
 
     return enc2uni
@@ -211,7 +214,7 @@
             (mapkey, mapcomment) = mapkey
         if isinstance(mapvalue, tuple):
             (mapvalue, mapcomment) = mapvalue
-        if mapkey is None:
+        if mapkey == MISSING_CODE:
             continue
         table[mapkey] = (mapvalue, mapcomment)
         if mapkey > maxkey:
@@ -223,11 +226,11 @@
     # Create table code
     for key in range(maxkey + 1):
         if key not in table:
-            mapvalue = None
+            mapvalue = MISSING_CODE
             mapcomment = 'UNDEFINED'
         else:
             mapvalue, mapcomment = table[key]
-        if mapvalue is None:
+        if mapvalue == MISSING_CODE:
             mapchar = UNI_UNDEFINED
         else:
             if isinstance(mapvalue, tuple):

From report at bugs.python.org  Mon Nov 29 19:36:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 18:36:58 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za>
Message-ID: <1291055818.36.0.212528975834.issue10552@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file19843/issue10552a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:38:00 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 29 Nov 2010 18:38:00 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <AANLkTi=_3q3e-+XkuJx1WbuoZyOtuUuf4z+=bRj7ZVC2@mail.gmail.com>
Message-ID: <4CF3F304.30303@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 Mon, Nov 29, 2010 at 1:21 PM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
> ..
>> BTW: You appear to have a comma appended to the constant, that doesn't
>> belong there:
>>
>> +# Placeholder for a missing codepoint
>> +MISSING_CODE = -1,
>> +
>>
>> Perhaps that's causing the second error you are seeing.
> 
> No, that comma was a left-over from the attempt to fix the
> mac_chinsimp error.  The trace that I reported was generated with
> MISSING_CODE = -1.   I am replacing the patch.
> 
> Is it ok to commit a partial fix?  It may take longer to fix the mac error.

Sure, we won't need that script anytime soon and if we do, we
can just as well use the Python2 version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:39:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 18:39:48 +0000
Subject: [issue10580] Installer sentence in bold
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <1291055988.45.0.549225458343.issue10580@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Windows
nosy: +eric.araujo
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10580>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:40:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Nov 2010 18:40:23 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291056023.39.0.405512146707.issue10576@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, as you point out, it would make more sense to have two separate callbacks. Also, PyErr_WriteUnraisable() is better than PyErr_Clear().

Finally, you accidentally recoded the file; it should be kept utf-8, not latin-whatever.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:40:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Nov 2010 18:40:56 +0000
Subject: [issue10580] Installer sentence in bold
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <1291056056.6.0.7482886612.issue10580@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10580>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:43:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Nov 2010 18:43:00 +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: <1291056180.27.0.344695113712.issue5863@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, this will need a comprehensive rewrite of bz2module, since it uses FILE pointers right now.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:46:33 2010
From: report at bugs.python.org (Marc Horowitz)
Date: Mon, 29 Nov 2010 18:46:33 +0000
Subject: [issue10582] PyErr_PrintEx exits silently when passed SystemExit
	exception
In-Reply-To: <1291056392.92.0.0604779345933.issue10582@psf.upfronthosting.co.za>
Message-ID: <1291056392.92.0.0604779345933.issue10582@psf.upfronthosting.co.za>


New submission from Marc Horowitz <mhorowitz at gmail.com>:

I discovered this bug working with panda3d.  I've attached a short
python script which demonstrates the problem.  After installing
panda3d, run the script, and then hit q in the window which appears.
You'll see that none of the cleanup code after the 'run()' main loop
runs.

The underlying cause is in how panda3d uses the C API.  It's got code
like this (in src/pipeline/thread.cxx):

    // Call the user's function.
    result = PyObject_Call(function, args, NULL);
    if (result == (PyObject *)NULL && PyErr_Occurred()) {
      // We got an exception.  Move the exception from the current
      // thread into the main thread, so it can be handled there.
      PyObject *exc, *val, *tb;
      PyErr_Fetch(&exc, &val, &tb);

      thread_cat.error()
        << "Exception occurred within " << *this << "\n";

      // Temporarily restore the exception state so we can print a
      // callback on-the-spot.
      Py_XINCREF(exc);
      Py_XINCREF(val);
      Py_XINCREF(tb);
      PyErr_Restore(exc, val, tb);
      PyErr_Print();

      ...

If the code being called (generally a panda3d task function or event
handler) calls sys.exit, the PyErr_Print() never returns.  This is
surprising, as the the documentation never mentions that a function
with an innocuous name like "Print" might never return.  

However, I don't think this is a panda3d bug; I think that the
function as documented is the way it should behave.  Otherwise, the
vast majority of calls to this method will need to look like

    if (!PyErr_ExceptionMatches(PyExc_SystemExit)) {
      PyErr_PrintEx(1);
    }

which seems like a poor abstraction.

Another unexpected side effect is when python is used with the -i
flag.  Because of the way this alters the normal exit behavior, the
code runs the way I'd expect, and the cleanup code in the test
application *does* run.  It seems rather strange to me that cleanup
code should run or not run based on the -i flag.

I believe the fix for all this is that PyErr_PrintEx be changed to
behave as documented, *not* call handle_system_exit() when passed
SystemExit, and instead in the places where the interpreter main loop
is run, followed by PyErr_PrintEx(), that SystemExit is special cased
in those specific locations as needed.

----------
components: Interpreter Core
files: exit_test.py
messages: 122846
nosy: Marc.Horowitz
priority: normal
severity: normal
status: open
title: PyErr_PrintEx exits silently when passed SystemExit exception
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19875/exit_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10582>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:49:44 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Nov 2010 18:49:44 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291056584.82.0.707067698873.issue10572@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Of those, it makes the most sense to move the json tests to Lib/tests.  Bob is not externally maintaining the 3.x version.  It's all our now.

Also, it looks like importlib is in a maintenance mode now.

There is merit to keeping 2to3, ctypes, sqlite tests separate.

Currently all of the documentation files are still under Doc so we should keep it that way and not move them under package directory trees.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:50:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 29 Nov 2010 18:50:40 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290994960.93.0.0578896129584.issue10478@psf.upfronthosting.co.za>
Message-ID: <1291056635.8671.38.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Would avoiding PyErr_CheckSignals() while the file object is in
> inconsistent state be a reasonable alternative?

No, because we'd like IO operations to be interruptible by the user
(e.g. pressing Ctrl-C) when they would otherwise block indefinitely.

> I am guessing that it's not that uncommon for a signal handler to need
> IO (e.g to log a signal).

In C, it is recommended that signal handlers be minimal. In Python,
there is no explicit recommendation but, given they execute
semi-asynchronously, I personally wouldn't put too much code in them :)

That said, there's no problem doing IO as long as you're not doing
reentrant calls to the *same* file object. I agree that for logging this
is not always practical...

> If making IO safer is not an option, then I think, this limitation
> needs to be documented (especially, given that this seems to be a
> behavior change from Python 2.x).

Perhaps the IO documentation needs an "advanced topics" section. I'll
see if I get some time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10478>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:52:00 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Nov 2010 18:52:00 +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: <1291056720.0.0.148133195975.issue5863@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Without a patch and compelling use cases, this has no chance.  Recommend closing.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:52:13 2010
From: report at bugs.python.org (Nadeem Vawda)
Date: Mon, 29 Nov 2010 18:52:13 +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: <1291056733.88.0.581001474647.issue5863@psf.upfronthosting.co.za>


Changes by Nadeem Vawda <nadeem.vawda at gmail.com>:


----------
nosy: +nvawda

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5863>
_______________________________________

From report at bugs.python.org  Mon Nov 29 19:52:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 18:52:35 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <4CF3F304.30303@egenix.com>
Message-ID: <AANLkTina_o7yahC9_70VeJfu=08NdUoJqZfyE1siH4YC@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Nov 29, 2010 at 1:38 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
> Sure, we won't need that script anytime soon and if we do, we
> can just as well use the Python2 version.

That may not be true.  I compared 2.7 and py3k versions and the later
has some new features:

* unidata_version  changed from 5.2.0 to 6.0.0
* Unihan data is read from zip file
* added processing of DerivedCoreProperties

These changes don't affect gencodec.py, but it may be inconvenient to
run makeunicodedata.py and gencodec.py using different versions of
Python.

I'll check that all non-mac encodings are correctly generated before committing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Mon Nov 29 20:04:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 19:04:56 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <4CF3F0EA.3090308@egenix.com>
Message-ID: <AANLkTi=SbWju7mAuCekMrA5uk5ey9YFQGYmv129eMGd1@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Nov 29, 2010 at 1:29 PM, Marc-Andre Lemburg
<report at bugs.python.org> wrote:
..
>
> I consider this a bug (which is why I added Python 2.7 to the list
> of versions), since those code points need to be mapped to decimal
> and digit as well (see the references I posted; and compare ).
>

I don't disagree.  However using Unicode 5.2.0 instead of the latest
6.0.0 may be considered a bug as well.  The practical issue is whether
to maintain two separate versions of Tools/unicode for 3.x and 2.7 or
merge 3.x changes back to 2.7 and support 3.x using 2to3.  Another
option is to simply use only 2.7 (or only 3.x) with Tools/unicode and
maintain control the differences between 2.7 and 3.x using a command
line switch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 20:11:40 2010
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 29 Nov 2010 19:11:40 +0000
Subject: [issue10572] Move unittest test package to Lib/test
In-Reply-To: <1290991979.58.0.262973706564.issue10572@psf.upfronthosting.co.za>
Message-ID: <1291057900.4.0.814745449026.issue10572@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have no issue with moving importlib into Lib/test as long as I can still run the tests with ``python3 -m test.importlib``. I actually only put the tests in importlib.tests because that was common practice amongst newer packages in the stdlib.

And just to prevent some rumour from perpetuating, importlib is not in maintenance mode. In fact the API was heavily reworked in 3.2 and I plan on exposing more of the API publicly in 3.3 and hopefully to bootstrap as well. The only thing you could think is in maintenance mode is importlib's Chesseshop package, but that's just for 2.x compatibility and for Django's benefit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10572>
_______________________________________

From report at bugs.python.org  Mon Nov 29 20:18:48 2010
From: report at bugs.python.org (Alex Rodriguez)
Date: Mon, 29 Nov 2010 19:18:48 +0000
Subject: [issue9620] Python 2.7 IDLE fails on OS X 10.6
In-Reply-To: <1281943669.49.0.305623127569.issue9620@psf.upfronthosting.co.za>
Message-ID: <1291058328.68.0.86192276335.issue9620@psf.upfronthosting.co.za>


Alex Rodriguez <alejmrm at gmail.com> added the comment:

I didn't see this issue resolved in the changelog for 2.7.1 release. Are we going to wait until 2.7.2 now??

----------
nosy: +Alex.Rodriguez

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9620>
_______________________________________

From report at bugs.python.org  Mon Nov 29 20:30:35 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 29 Nov 2010 19:30:35 +0000
Subject: [issue9620] Python 2.7 IDLE fails on OS X 10.6
In-Reply-To: <1281943669.49.0.305623127569.issue9620@psf.upfronthosting.co.za>
Message-ID: <1291059035.18.0.886908388543.issue9620@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This issue was closed as a duplicate of #9227.
Please direct further comments there.
In any case, all issues wait until a person with the requisite knowledge volunteers a fix and a core developer commits the fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9620>
_______________________________________

From report at bugs.python.org  Mon Nov 29 20:31:37 2010
From: report at bugs.python.org (Duncan Findlay)
Date: Mon, 29 Nov 2010 19:31:37 +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: <1291059097.53.0.232750674695.issue1975@psf.upfronthosting.co.za>


Changes by Duncan Findlay <duncan at duncf.ca>:


----------
nosy: +duncf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
_______________________________________

From report at bugs.python.org  Mon Nov 29 20:35:32 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Nov 2010 19:35:32 +0000
Subject: [issue4214] no extension debug info with msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <1291059332.23.0.611645450553.issue4214@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

/pdb:None initially did *not* mean "no debug information", but "no pdb file", see

http://msdn.microsoft.com/en-us/library/aa278542(VS.60).aspx

Debug information would be embedded to the DLL.

Later versions of the VS documentation fail to mention "None" as a special value. Assuming it still has its original semantics, I fail to see the bug in this report.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4214>
_______________________________________

From report at bugs.python.org  Mon Nov 29 20:43:49 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Nov 2010 19:43:49 +0000
Subject: [issue10580] Installer sentence in bold
In-Reply-To: <1291053115.29.0.21132112584.issue10580@psf.upfronthosting.co.za>
Message-ID: <1291059829.73.0.25265268206.issue10580@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd like a native speaker (of English) to confirm this request.

The report is about Tools/msi/msi.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10580>
_______________________________________

From report at bugs.python.org  Mon Nov 29 20:48:28 2010
From: report at bugs.python.org (flashk)
Date: Mon, 29 Nov 2010 19:48:28 +0000
Subject: [issue10583] Encoding issue with chm help in 2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>


New submission from flashk <flashk at gmail.com>:

I just updated to Python 2.7.1 and noticed a small issue with the chm help file.

The search results tab displays incorrect characters for various topic titles. It seems to be an encoding issue.

For example, searching for 'json' yields the following results:

 - 18.2 json ??? JSON encoder and decoder
 - What???s New in Python 2.6

I noticed this issue on Windows XP 32-bit and Windows 7 64-bit.

This issue does not exist with the 2.7 chm file.

----------
assignee: docs at python
components: Documentation, Windows
messages: 122857
nosy: docs at python, flashk
priority: normal
severity: normal
status: open
title: Encoding issue with chm help in 2.7.1
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10583>
_______________________________________

From report at bugs.python.org  Mon Nov 29 20:48:39 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Nov 2010 19:48:39 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <AANLkTina_o7yahC9_70VeJfu=08NdUoJqZfyE1siH4YC@mail.gmail.com>
Message-ID: <4CF40395.70000@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> These changes don't affect gencodec.py, but it may be inconvenient to
> run makeunicodedata.py and gencodec.py using different versions of
> Python.

As MAL explains: these are completely unrelated, independent tools,
and gencodec isn't run more than once per decade (or so). I only ever
run makeunicodedata, and I have been using Python 3 to run it.

The mappings are not supposed to ever change once produced. In
particular, new versions of Unicode cannot affect them, since the
existing characters all map fine to existing code points, which will
not change their meaning per Unicode stability criteria.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Mon Nov 29 20:52:16 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Nov 2010 19:52:16 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291049135.12.0.141498499562.issue10575@psf.upfronthosting.co.za>
Message-ID: <4CF4046E.3040003@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I am adding #10552 as a dependency because I think we should fix
> unicode data generation in 3.x before adding new features to the
> scripts.
> 
> I am also not sure whether this is a bug or a feature request.
> Martin?

I fail to see the relevance of gencodec to this issue (and, as
you see in my comment to #10552, I very much fail to see the relevance
of that issue, or of gencodec in the first place).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 20:53:09 2010
From: report at bugs.python.org (Robin Dunn)
Date: Mon, 29 Nov 2010 19:53:09 +0000
Subject: [issue4214] no extension debug info with msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <1291060389.72.0.783152432979.issue4214@psf.upfronthosting.co.za>


Robin Dunn <robin at alldunn.com> added the comment:

No, MSVC does not behave that way any longer.  Now it simply creates a file named "None", so I expect that the newer versions simply do not support writing the "old-style" debug info written to the DLL or EXE. If a setup script creates more than one extension module then they all overwrite that None file.

In order to get debug info in a useable form, distutils simply can not use /pdb:None.  By removing that option entirely then debug info is generated like normal into a *.pdb file and using the debugger to trace through the extension module's code will happily work correctly.

I've had to have this hack in wxPython's setup.py since Python 2.6 to work around this problem:


# Yet another distutils hack, this time for the msvc9compiler.  There
# is a bug in at least version distributed with Python 2.6 where it
# adds '/pdb:None' to the linker command-line, but that just results
# in a 'None' file being created instead of putting the debug info
# into the .pyd files as expected.  So we'll strip out that option via
# a monkey-patch of the msvc9compiler.MSVCCompiler.initialize method.

if os.name == 'nt' and  sys.version_info >= (2,6):
    import distutils.msvc9compiler
    _orig_initialize = distutils.msvc9compiler.MSVCCompiler.initialize

    def _initialize(self, *args, **kw):
        rv = _orig_initialize(self, *args, **kw)
        try:
            self.ldflags_shared_debug.remove('/pdb:None')
        except ValueError:
            pass
        return rv

    distutils.msvc9compiler.MSVCCompiler.initialize = _initialize

----------
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4214>
_______________________________________

From report at bugs.python.org  Mon Nov 29 21:03:13 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Nov 2010 20:03:13 +0000
Subject: [issue10565] isinstance(x, collections.Iterator) can return True,
	when x isn't iterable
In-Reply-To: <1290959907.04.0.171212908469.issue10565@psf.upfronthosting.co.za>
Message-ID: <1291060993.71.0.323482953119.issue10565@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Alexander, do you want to take care of the backport?

----------
assignee: rhettinger -> belopolsky
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10565>
_______________________________________

From report at bugs.python.org  Mon Nov 29 21:10:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Nov 2010 20:10:59 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>
Message-ID: <1291061459.3.0.34838576769.issue10575@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a bug, see

http://www.unicode.org/reports/tr44/#Numeric_Value

Characters have a Numeric_Type property of either null, Decimal, Digit, or Numeric. For non-Unihan characters, this is denoted by filling out either no column, or (6,7,and 8), or (7 and 8), or (8), respectively, as implemented by makeunicodedata.py. Unihan characters have only null or Numeric as their Numeric_Type property, never Decimal nor Digit, see

 http://www.unicode.org/reports/tr44/#Numeric_Type_Han

Therefore, it is correct that digit() raises a ValueError for U+4e09.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 21:12:52 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 29 Nov 2010 20:12:52 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <AANLkTi=SbWju7mAuCekMrA5uk5ey9YFQGYmv129eMGd1@mail.gmail.com>
Message-ID: <4CF40941.5030005@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 Mon, Nov 29, 2010 at 1:29 PM, Marc-Andre Lemburg
> <report at bugs.python.org> wrote:
> ..
>>
>> I consider this a bug (which is why I added Python 2.7 to the list
>> of versions), since those code points need to be mapped to decimal
>> and digit as well (see the references I posted; and compare ).
>>
> 
> I don't disagree.  However using Unicode 5.2.0 instead of the latest
> 6.0.0 may be considered a bug as well. 

No, since we only ever change the UCD version once per Python
release.

Note that those standard don't have a version number just for the
fun of it. Each version is a standard of its own and only
patch level updates will go into it.

It's not a bug to stick to an older UCD version.

> The practical issue is whether
> to maintain two separate versions of Tools/unicode for 3.x and 2.7 or
> merge 3.x changes back to 2.7 and support 3.x using 2to3.  Another
> option is to simply use only 2.7 (or only 3.x) with Tools/unicode and
> maintain control the differences between 2.7 and 3.x using a command
> line switch.

I'm not sure whether the effort is worth it. We don't run those
tools often enough to invest much time into keeping them in sync
between 2.x and 3.x.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 21:13:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Nov 2010 20:13:33 +0000
Subject: [issue4214] no extension debug info with msvc9compiler.py
In-Reply-To: <1225144462.62.0.9122976862.issue4214@psf.upfronthosting.co.za>
Message-ID: <1291061613.24.0.184827431058.issue4214@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ah ok, then removing the option sounds fine to me (not for 2.6, though).

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4214>
_______________________________________

From report at bugs.python.org  Mon Nov 29 21:15:16 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Nov 2010 20:15:16 +0000
Subject: [issue10583] Encoding issue with chm help in 2.7.1
In-Reply-To: <1291060108.22.0.631034667944.issue10583@psf.upfronthosting.co.za>
Message-ID: <1291061716.4.0.675000611168.issue10583@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10583>
_______________________________________

From report at bugs.python.org  Mon Nov 29 21:16:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 20:16:47 +0000
Subject: [issue10565] isinstance(x, collections.Iterator) can return True,
	when x isn't iterable
In-Reply-To: <1290959907.04.0.171212908469.issue10565@psf.upfronthosting.co.za>
Message-ID: <1291061807.2.0.109765571773.issue10565@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

ok

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10565>
_______________________________________

From report at bugs.python.org  Mon Nov 29 21:22:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 29 Nov 2010 20:22:32 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>
Message-ID: <1291062152.98.0.62261693713.issue10575@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> I fail to see the relevance of gencodec to this issue ...

Thanks for the explanation.  I wrongly assumed that "make all" is the way to regenerate both unicodedata and the encodings and that the two are interdependent.

----------
dependencies:  -Tools/unicode/gencodec.py error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 21:42:32 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 29 Nov 2010 20:42:32 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291061459.3.0.34838576769.issue10575@psf.upfronthosting.co.za>
Message-ID: <4CF41035.1010205@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> This is not a bug, see
> 
> http://www.unicode.org/reports/tr44/#Numeric_Value
> 
> Characters have a Numeric_Type property of either null, Decimal, Digit, or Numeric. For non-Unihan characters, this is denoted by filling out either no column, or (6,7,and 8), or (7 and 8), or (8), respectively, as implemented by makeunicodedata.py. Unihan characters have only null or Numeric as their Numeric_Type property, never Decimal nor Digit, see
> 
>  http://www.unicode.org/reports/tr44/#Numeric_Type_Han
> 
> Therefore, it is correct that digit() raises a ValueError for U+4e09.

You're right. I guess this is a bug in the UCD or TR44/TR38 itself.

It looks like the numeric properties are not separated in the
Unihan database in the same way they are for the standard UCD.

Unihan separates based on usage context, whereas UCS takes
a parsing approach.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 21:42:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Nov 2010 20:42:59 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291062152.98.0.62261693713.issue10575@psf.upfronthosting.co.za>
Message-ID: <4CF41051.7090701@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Thanks for the explanation.  I wrongly assumed that "make all" is the
> way to regenerate both unicodedata and the encodings and that the two
> are interdependent.

Ah. I never use the Makefile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 21:46:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 29 Nov 2010 20:46:24 +0000
Subject: [issue10575] makeunicodedata.py does not support Unihan digit data
In-Reply-To: <1291029056.3.0.883986671592.issue10575@psf.upfronthosting.co.za>
Message-ID: <1291063584.6.0.99212599291.issue10575@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10575>
_______________________________________

From report at bugs.python.org  Mon Nov 29 21:47:04 2010
From: report at bugs.python.org (Jim Jewett)
Date: Mon, 29 Nov 2010 20:47:04 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291063624.87.0.0433201188194.issue10576@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

I like the idea, but I do quibble with the signature.  As nearly as I can tell, you're assuming

(a)  Only one callback.  I would prefer a sequence of callbacks, to make cooperation easier.  (This does mean you would need a callback removal, instead of just setting it to None.)

(b)  The callback will be called once before collecting generations, and once after (with the number of objects that weren't collected).  Should these be separate callbacks, rather than the same one with a boolean?  And why does it need the number of uncollected objects?  (This might be a case where Practicality Beats Purity, but it is worth documenting.)

----------
nosy: +jimjjewett

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Mon Nov 29 22:00:32 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 29 Nov 2010 21:00: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: <1291064432.06.0.0242246113004.issue8743@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
Removed message: http://bugs.python.org/msg117005

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8743>
_______________________________________

From report at bugs.python.org  Mon Nov 29 22:04:37 2010
From: report at bugs.python.org (Vil)
Date: Mon, 29 Nov 2010 21:04:37 +0000
Subject: [issue10500] Palevo.DZ worm msix86 installer 3.x installer
In-Reply-To: <1291005128.96.0.865011980714.issue10500@psf.upfronthosting.co.za>
Message-ID: <AANLkTinxACnjc83nS6H4phUJZvPfvW7td4v7LXTq+GWV@mail.gmail.com>


Vil <vilignoble at gmail.com> added the comment:

I sent the file I downloaded to total virus and it say,
Result:
0/ 36 (0.0%)

I'm not sure what that means, but I am guessing a Result of "-" means it did
not find a virus, I have 2.7.1 installed and it scanned the installer and
was clean, so though I do not know what the Result says I am going to say it
shows clean on my side in the folder I downloaded to; I will send it in to
CA to see if they can recognize it as a false positive.
2010/11/28 Jes??s Cea Avi??n <report at bugs.python.org>

>
> Jes??s Cea Avi??n <jcea at jcea.es> added the comment:
>
> The virustotal (Note: I am associated to those guys) link I posted included
> HASHES you can verify in your side to know if it is a false positive or the
> file is actually altered by "something" in transit/in your site.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10500>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19876/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10500>
_______________________________________
-------------- next part --------------
I sent the file I downloaded to total virus and it say, <br><div style="width: 120px; float: left; display: inline;">Result: </div>
        <span class="blackthick"><span id="detected" style="color: red;">0</span>/
                                 <span id="status-total">36 (0.0%)<br><br>I&#39;m not sure what that means, but I am guessing a Result of &quot;-&quot; means it did not find a virus, I have 2.7.1 installed and it scanned the installer and was clean, so though I do not know what the Result says I am going to say it shows clean on my side in the folder I downloaded to; I will send it in to CA to see if they can recognize it as a false positive.<br>
</span></span><div class="gmail_quote">2010/11/28 Jes??s Cea Avi??n <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;">
<div class="im"><br>
Jes??s Cea Avi??n &lt;<a href="mailto:jcea at jcea.es">jcea at jcea.es</a>&gt; added the comment:<br>
<br>
</div>The virustotal (Note: I am associated to those guys) link I posted included HASHES you can verify in your side to know if it is a false positive or the file is actually altered by &quot;something&quot; in transit/in your site.<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/issue10500" target="_blank">http://bugs.python.org/issue10500</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Tue Nov 30 00:08:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 29 Nov 2010 23:08:05 +0000
Subject: [issue10584] Bad links in doc of zipfile.open
In-Reply-To: <1291072085.42.0.419401053582.issue10584@psf.upfronthosting.co.za>
Message-ID: <1291072085.42.0.419401053582.issue10584@psf.upfronthosting.co.za>


New submission from ?ric Araujo <merwok at netwok.org>:

There is this note in the doc of zipfile.open:

?The file-like object [ZipExtFile, internal class] is read-only and provides the following methods: read(), readline(), readlines(), __iter__(), __next__().?

The :meth: construct gives interesting results here: link to zipfile.ZipFile.read (wrong), link to readline module (what?), no link, link to object.__iter__ (not bad), no link.

----------
assignee: docs at python
components: Documentation
messages: 122871
nosy: docs at python, eric.araujo
priority: normal
severity: normal
status: open
title: Bad links in doc of zipfile.open
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10584>
_______________________________________

From report at bugs.python.org  Tue Nov 30 00:27:21 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 29 Nov 2010 23:27:21 +0000
Subject: [issue10585] 2.6 maintenance branch erroneously uses
	unittest.TestCase.assertListEqual (added in 2.7)
In-Reply-To: <1291073241.08.0.380163475863.issue10585@psf.upfronthosting.co.za>
Message-ID: <1291073241.08.0.380163475863.issue10585@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

2.6.6 has an erronenous use of a unittest method that was added in 2.7, but it's only seen when running as root.  More specificially, with this guard:
    if posix.getuid() == 0 and hasattr(posix, 'getgroups') and sys.platform != 'darwin':

[david at surprise 2.6-clean]$ sudo ./python -m test.test_posix
   (snip)
======================================================================
ERROR: test_setgroups (__main__.PosixGroupsTester)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/lib64/python2.6/test/test_posix.py", line 356, in test_setgroups
    self.assertListEqual(groups, posix.getgroups())
AttributeError: 'PosixGroupsTester' object has no attribute 'assertListEqual'

----------------------------------------------------------------------
Ran 29 tests in 0.020s

FAILED (errors=1)

Seems to have come from r83126.  Fix would seem to be to replace the assertListEqual with AssertEqual.  Am attaching a patch.

----------
components: Tests
files: 2.6-fix-test_setgroups.patch
keywords: easy, patch
messages: 122872
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: 2.6 maintenance branch erroneously uses unittest.TestCase.assertListEqual (added in 2.7)
versions: Python 2.6
Added file: http://bugs.python.org/file19877/2.6-fix-test_setgroups.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10585>
_______________________________________

From report at bugs.python.org  Tue Nov 30 01:16:39 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Nov 2010 00:16:39 +0000
Subject: [issue10262] Add --soabi option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1291076199.98.0.203160862485.issue10262@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a first patch that adds the "--with-soabi" option.
    --with-soabi=yes or --with-soabi  sets SOABI to the computed value (cpython-32m when I tried it). This is the default behavior on Linux.
    --with-soabi=no or --without-soabi  sets SOABI to the empty string, and removes the additional searched extensions from imp.get_suffixes().  This is the default behavior on all other platforms.
    --with-soabi=<tag>  sets SOABI to the given string.  Then imp.get_suffixes() contains the following extensions: [".tag.so", "module.tag.so", ".so", "module.so"]

The patch is not yet complete, it does not modify the suffixes in the dynload_* files for platforms other than Linux.
Windows support will come after. It requires more thoughts because there is no Makefile to read at runtime.

But it's the first time I change the ./configure script, so please comment on this first patch.

----------
Added file: http://bugs.python.org/file19878/with-soabi.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Tue Nov 30 01:22:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Nov 2010 00:22:13 +0000
Subject: [issue10585] 2.6 maintenance branch erroneously uses
	unittest.TestCase.assertListEqual (added in 2.7)
In-Reply-To: <1291073241.08.0.380163475863.issue10585@psf.upfronthosting.co.za>
Message-ID: <1291076533.35.0.610317327032.issue10585@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m afraid tests are no exception to the rule ?only security fixes in stable branches?.

----------
nosy: +barry, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10585>
_______________________________________

From report at bugs.python.org  Tue Nov 30 02:15:33 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 30 Nov 2010 01:15:33 +0000
Subject: [issue10585] 2.6 maintenance branch erroneously uses
	unittest.TestCase.assertListEqual (added in 2.7)
In-Reply-To: <1291073241.08.0.380163475863.issue10585@psf.upfronthosting.co.za>
Message-ID: <1291079733.99.0.56729773486.issue10585@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

TBH, the fact that this test only runs under sudo is more troublesome.  It's clearly a test that doesn't get run much.  E.g. it sneaked through pre-release testing and doesn't affect the buildbots.

But I agree that this shouldn't be applied to the 2.6 tree.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10585>
_______________________________________

From report at bugs.python.org  Tue Nov 30 02:20:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 30 Nov 2010 01:20:04 +0000
Subject: [issue10565] isinstance(x, collections.Iterator) can return True,
	when x isn't iterable
In-Reply-To: <1290959907.04.0.171212908469.issue10565@psf.upfronthosting.co.za>
Message-ID: <1291080004.01.0.811455551329.issue10565@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r86872 (3.1) and r86873 (2.7).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10565>
_______________________________________

From report at bugs.python.org  Tue Nov 30 03:50:41 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Nov 2010 02:50:41 +0000
Subject: [issue10323] Final state of underlying sequence in islice
In-Reply-To: <1288952019.84.0.665724422308.issue10323@psf.upfronthosting.co.za>
Message-ID: <1291085441.1.0.486135464553.issue10323@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r86874.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10323>
_______________________________________

From report at bugs.python.org  Tue Nov 30 04:20:19 2010
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 30 Nov 2010 03:20:19 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291087219.03.0.318177887367.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

pitrou: that sounds good. I attached another patch.

----------
Added file: http://bugs.python.org/file19879/issue_3243_py3k_3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 05:12:09 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Nov 2010 04:12:09 +0000
Subject: [issue10586] Enhanced cache access API for functools.lru_cache
In-Reply-To: <1291090329.24.0.356278659224.issue10586@psf.upfronthosting.co.za>
Message-ID: <1291090329.24.0.356278659224.issue10586@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

As per private email to Raymond, I would like to move the lru_cache access attributes and methods into a CacheInfo class, exposed as a "cache" attribute with several methods and read-only properties.

Read-only properties: hits, misses, maxsize
Methods: clear(), __len__()

As an implementation detail, cache_misses and cache_hits become nonlocal variables rather than attributes of the wrapper function.

Priority set to high, since the current API will be locked in as soon the first beta goes out.

----------
assignee: rhettinger
files: functools_lru_cache_introspection.diff
keywords: patch
messages: 122879
nosy: georg.brandl, ncoghlan, rhettinger
priority: high
severity: normal
status: open
title: Enhanced cache access API for functools.lru_cache
versions: Python 3.2
Added file: http://bugs.python.org/file19880/functools_lru_cache_introspection.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10586>
_______________________________________

From report at bugs.python.org  Tue Nov 30 05:37:40 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Tue, 30 Nov 2010 04:37: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: <1291091860.96.0.222279902328.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101130.zip is a new version of the regex module.

Added 'special_only' keyword parameter (default False) to regex.escape. When True, regex.escape escapes only 'special' characters, such as '?'.

----------
Added file: http://bugs.python.org/file19881/issue2636-20101130.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Tue Nov 30 05:55:33 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Nov 2010 04:55:33 +0000
Subject: [issue10586] Enhanced cache access API for functools.lru_cache
In-Reply-To: <1291090329.24.0.356278659224.issue10586@psf.upfronthosting.co.za>
Message-ID: <1291092933.79.0.468038330909.issue10586@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Raymond suggested a simple cache_info() method that returns a named tuple as a possible alternative.

I like that idea, as it makes displaying debugging information (the intended use case for these attributes) absolutely trivial:

>>> import functools
>>> @functools.lru_cache()
... def f(x):
...   return x
... 
>>> f.cache_info()
lru_cache_info(maxsize=100, currsize=0, hits=0, misses=0)

(Alternative patch attached)

----------
Added file: http://bugs.python.org/file19882/functools_lru_cache_info_method.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10586>
_______________________________________

From report at bugs.python.org  Tue Nov 30 06:17:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Nov 2010 05:17:53 +0000
Subject: [issue10586] Enhanced cache access API for functools.lru_cache
In-Reply-To: <1291090329.24.0.356278659224.issue10586@psf.upfronthosting.co.za>
Message-ID: <1291094273.17.0.28303259645.issue10586@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Okay, go ahead with the second patch.
With the following changes:

_CacheInfo = namedtuple("CacheInfo", "maxsize size hits misses")

Change the variable names:  
         cache_hits --> hits
         cache_misses --> misses

Add a "with lock:" to the cache_info() function.

Update the docs.

Thanks.

----------
assignee: rhettinger -> ncoghlan
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10586>
_______________________________________

From report at bugs.python.org  Tue Nov 30 06:24:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Nov 2010 05:24:15 +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: <1291094655.98.0.885038142076.issue9709@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The policy for distutils is: no changes, only bug fixes.  We cannot remove a function, even useless.  Deprecating does not seem useful if we aren?t going to remove.  Changing the docstring, the docs or the output of the code is okay.  Therefore, initfunc2.patch is the way to go.  Can you add a test for its behavior?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9709>
_______________________________________

From report at bugs.python.org  Tue Nov 30 06:33:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Nov 2010 05:33:51 +0000
Subject: [issue6703] cross platform failure and silly test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1291095231.9.0.426843763409.issue6703@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Patch looks good.  One error and style suggestions on rietveld.

----------
components: +Library (Lib)
nosy: +eric.araujo
stage:  -> patch review
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6703>
_______________________________________

From report at bugs.python.org  Tue Nov 30 06:42:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Nov 2010 05:42:21 +0000
Subject: [issue6598] calling email.utils.make_msgid frequently has a
	non-trivial probability of generating colliding ids
In-Reply-To: <1248913936.65.0.487457323949.issue6598@psf.upfronthosting.co.za>
Message-ID: <1291095741.75.0.315332186619.issue6598@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +r.david.murray
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6598>
_______________________________________

From report at bugs.python.org  Tue Nov 30 06:42:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Nov 2010 05:42:52 +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: <1291095772.58.0.530457255762.issue7183@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7183>
_______________________________________

From report at bugs.python.org  Tue Nov 30 06:46:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 30 Nov 2010 05:46:46 +0000
Subject: [issue10587] Document the meaning of str methods
In-Reply-To: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>
Message-ID: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

On Mon, Nov 29, 2010 at 4:13 PM, "Martin v. L?wis" <martin at v.loewis.de> wrote:
>> - How specific should library reference manual be in defining methods
>> affected by UCD such as str.upper()?
>
> It should specify what this actually does in Unicode terminology
> (probably in addition to a layman's rephrase of that)
>

http://mail.python.org/pipermail/python-dev/2010-November/106155.html

Some of the clarifications may actually lead to a conclusion that current behavior is wrong.  For example, Unicode defines Alphabetic property as Lu + Ll + Lt + Lm + Lo + Nl + Other_Alphabetic

http://www.unicode.org/reports/tr44/tr44-6.html#Alphabetic

However, str.isalpha() is defined as just Lu + Ll + Lt + Lm + Lo.  For example,

>>> import unicodedata as ud
>>> ud.category('?')
'Nl'
>>> '?'.isalpha()
False
>>> ud.name('?')
'ROMAN NUMERAL FIVE'

As far a I can tell, the source of Other_Alphabetic property data,
http://unicode.org/Public/UNIDATA/PropList.txt, is not even included in the unicodedata module and neither is SpecialCasing.txt which is necessary for implementing a compliant case mapping algorithm.

----------
assignee: docs at python
components: Documentation
messages: 122885
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: Document the meaning of str methods
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10587>
_______________________________________

From report at bugs.python.org  Tue Nov 30 06:48:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 30 Nov 2010 05:48:11 +0000
Subject: [issue10587] Document the meaning of str methods
In-Reply-To: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>
Message-ID: <1291096091.19.0.747350399638.issue10587@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/issue10587>
_______________________________________

From report at bugs.python.org  Tue Nov 30 07:21:03 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Nov 2010 06:21:03 +0000
Subject: [issue10586] Enhanced cache access API for functools.lru_cache
In-Reply-To: <1291090329.24.0.356278659224.issue10586@psf.upfronthosting.co.za>
Message-ID: <1291098063.92.0.50852753452.issue10586@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Committed in r86878.

I put a XXX note in the relevant part of the 3.2 What's New rather than updating it directly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10586>
_______________________________________

From report at bugs.python.org  Tue Nov 30 07:21:52 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Nov 2010 06:21:52 +0000
Subject: [issue10586] Enhanced cache access API for functools.lru_cache
In-Reply-To: <1291090329.24.0.356278659224.issue10586@psf.upfronthosting.co.za>
Message-ID: <1291098112.94.0.306111838874.issue10586@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
stage:  -> committed/rejected
status: open -> closed
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10586>
_______________________________________

From report at bugs.python.org  Tue Nov 30 07:32:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Nov 2010 06:32:04 +0000
Subject: [issue9508] python3.2 reversal of distutils reintrocud macos9 support
In-Reply-To: <1280927222.45.0.841645452377.issue9508@psf.upfronthosting.co.za>
Message-ID: <1291098724.76.0.486113130637.issue9508@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

On python-dev, Martin commented that if it was unnecessary to remove an unused function in 2.7, then I shouldn?t have done it.  I agreed, planned to revert that removal, however unlikely it was that someone depended on it, and then I couldn?t make up my mind in the middle of diverging opinions that followed.  I missed the 3.1.3 release deadline, so the change is out there now.  I?m going to leave 2.7 as it is, and at the first complaint about broken third-party code I?ll revert the removal.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9508>
_______________________________________

From report at bugs.python.org  Tue Nov 30 07:35:40 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Nov 2010 06:35:40 +0000
Subject: [issue10586] Enhanced cache access API for functools.lru_cache
In-Reply-To: <1291090329.24.0.356278659224.issue10586@psf.upfronthosting.co.za>
Message-ID: <1291098940.58.0.827009053457.issue10586@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10586>
_______________________________________

From report at bugs.python.org  Tue Nov 30 07:36:52 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Nov 2010 06:36:52 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1291099012.93.0.193692716777.issue10220@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Switched to strings in r86879.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Tue Nov 30 08:27:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Nov 2010 07:27:07 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1291102027.77.0.154666472486.issue5088@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5088>
_______________________________________

From report at bugs.python.org  Tue Nov 30 08:32:11 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Nov 2010 07:32:11 +0000
Subject: [issue9873] urllib.parse: Allow bytes in some APIs that use string
	literals internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1291102331.33.0.61112255076.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

New patch which addresses my last two comments (i.e. some basic explicit tests of the encode/decode methods on result objects, and urldefrag returns a named tuple like urlsplit and urlparse already did).

A natural consequence of this patch is that mixed arguments (as in the message above) will be rejected with TypeError.

Once I figure out what the docs changes are going to look like, I'll wrap this all up and commit it.

----------
Added file: http://bugs.python.org/file19883/issue9873_just_needs_docs.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Tue Nov 30 08:45:42 2010
From: report at bugs.python.org (Chris Withers)
Date: Tue, 30 Nov 2010 07:45:42 +0000
Subject: [issue6703] cross platform failure and silly test in doctest
In-Reply-To: <1250266697.36.0.481264395332.issue6703@psf.upfronthosting.co.za>
Message-ID: <1291103142.34.0.38363585173.issue6703@psf.upfronthosting.co.za>


Chris Withers <chris at simplistix.co.uk> added the comment:

What this patch doesn't appear to address is that there doesn't appear to be any point to module_relative. Can anyone clarify what the intention of this option is? (it doesn't appear to have any meaningful point from my experience...)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6703>
_______________________________________

From report at bugs.python.org  Tue Nov 30 08:56:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Nov 2010 07:56:21 +0000
Subject: [issue10584] Bad links in doc of zipfile.open
In-Reply-To: <1291072085.42.0.419401053582.issue10584@psf.upfronthosting.co.za>
Message-ID: <1291103781.1.0.188881419946.issue10584@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in 86881.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10584>
_______________________________________

From report at bugs.python.org  Tue Nov 30 09:41:42 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 30 Nov 2010 08:41:42 +0000
Subject: [issue9639] urllib2's AbstractBasicAuthHandler is limited to 6
	requests
In-Reply-To: <1282209110.27.0.244600135673.issue9639@psf.upfronthosting.co.za>
Message-ID: <1291106502.11.0.891257206013.issue9639@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Grr.  Why wasn't this fix backported to the release maintenance branch before 2.6.6 was released?  I've just had an application break as a result of upgrading from 2.6.5 to 2.6.6.

Oh well, too late now. :-(

</grumble>

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9639>
_______________________________________

From report at bugs.python.org  Tue Nov 30 10:09:39 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 30 Nov 2010 09:09:39 +0000
Subject: [issue9639] urllib2's AbstractBasicAuthHandler is limited to 6
	requests
In-Reply-To: <1282209110.27.0.244600135673.issue9639@psf.upfronthosting.co.za>
Message-ID: <1291108179.34.0.212988011873.issue9639@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Ouch. My mistake. Had not realize then, that code that actually broke things was merged in 2.6.x and it had to be fixed too. :(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9639>
_______________________________________

From report at bugs.python.org  Tue Nov 30 10:17:22 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 30 Nov 2010 09:17:22 +0000
Subject: [issue9639] urllib2's AbstractBasicAuthHandler is limited to 6
	requests
In-Reply-To: <1282209110.27.0.244600135673.issue9639@psf.upfronthosting.co.za>
Message-ID: <1291108642.44.0.661659407529.issue9639@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Ah well, it turned out to be fairly easy to work around, at least. :-)

Just in case any other urllib2 users have to deal with this in 2.6.6 (and also manage to find their way to this bug report :-):  it's easy to monkeypatch your way around the problem.  E.g.:

import sys
import urllib2

if sys.version_info[:2] == (2, 6) and sys.version_info[2] >= 6:
    def fixed_http_error_401(self, req, fp, code, msg, headers):
        url = req.get_full_url()
        response = self.http_error_auth_reqed('www-authenticate',
                                          url, req, headers)
        self.retried = 0
        return response

    urllib2.HTTPBasicAuthHandler.http_error_401 = fixed_http_error_401

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9639>
_______________________________________

From report at bugs.python.org  Tue Nov 30 10:35:52 2010
From: report at bugs.python.org (Emile Anclin)
Date: Tue, 30 Nov 2010 09:35:52 +0000
Subject: [issue10588] imp.find_module raises unexpected SyntaxError
In-Reply-To: <1291109752.1.0.382539471745.issue10588@psf.upfronthosting.co.za>
Message-ID: <1291109752.1.0.382539471745.issue10588@psf.upfronthosting.co.za>


New submission from Emile Anclin <emile.anclin at logilab.fr>:

Considering following file: 
$ cat pylint/test/input/func_unknown_encoding.py 
# -*- coding: IBO-8859-1 -*-
""" check correct unknown encoding declaration
"""

__revision__ = '????'
$

When we try to find that module, imp.find_module raises SyntaxError:

>>> from imp import find_module
>>> find_module('func_unknown_encoding', None)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
SyntaxError: encoding problem: with BOM

It should be considered as a bug, as stated by  Brett Cannon:

> Considering these semantics changed between Python 2 and 3 w/o a
> discernable benefit (I would consider it a negative as finding a
> module should not be impacted by syntactic correctness; the full act
> of importing should be the only thing that cares about that), I would
> consider it a bug that should be filed.

----------
messages: 122896
nosy: emile.anclin
priority: normal
severity: normal
status: open
title: imp.find_module raises unexpected SyntaxError
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10588>
_______________________________________

From report at bugs.python.org  Tue Nov 30 11:20:46 2010
From: report at bugs.python.org (Stefan Krah)
Date: Tue, 30 Nov 2010 10:20:46 +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: <1291112446.6.0.384600396399.issue9709@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Without the patch, you see the warning if test_build_ext is run in
verbose mode. With the patch, the warning disappears.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9709>
_______________________________________

From report at bugs.python.org  Tue Nov 30 12:00:06 2010
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 30 Nov 2010 11:00:06 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291114806.49.0.579131105202.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

pitrou: actually that seems a bit suspect now... you need to handle 'data' differently depending on its type, and while you can determine the type by finding out when 'data' throws certain exceptions, it doesn't seem like what exceptions were meant for.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 12:07:01 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Nov 2010 11:07:01 +0000
Subject: [issue10537] OS X IDLE 2.7rc1 from 64-bit installer hangs when you
	paste something.
In-Reply-To: <1290750067.88.0.576950559061.issue10537@psf.upfronthosting.co.za>
Message-ID: <1291115221.56.0.818904505994.issue10537@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

More data points: using the 2.7.1 release source tarball, the problem is reproducible on 10.6 when dynamically linked to the Apple Tcl/Tk 8.5 and executing in either 64-bit or 32-bit mode.  It is not reproducible when using ActiveState Tcl/Tk 8.5.9, AS Tcl/Tk 8.4.19, or Apple Tcl/Tk 8.4 (none of which, of course, is available in 64-bit mode).

Unfortunately, the obvious workaround for the 64-bit/32-bit variant - building with one of the working 32-bit versions - does not result in a working IDLE.app or bin/idle since IDLE and its subprocesses are all launched in 64-bit mode (where possible) on 10.6.  For testing, it is possible to demonstrate 32-bit mode in a 64-/32- build with a properly built _tkinter.so by using the -n parameter, which causes IDLE to run with no subprocesses:
   arch -i386 /usr/local/bin/idle2.7 -n

Next step: see if the Issue6075 patches help with the Apple 8.5 Tk and, if not, add stuff to force both IDLE.app and bin/idle and their subprocesses to run only in 32-bit mode: probably either some more lipo-ing and/or adding posix_spawns.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10537>
_______________________________________

From report at bugs.python.org  Tue Nov 30 12:10:31 2010
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 30 Nov 2010 11:10:31 +0000
Subject: [issue10464] netrc module not parsing passwords containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1291115431.15.0.068821017781.issue10464@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

bumping...can someone review this? The reported bug seems valid enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10464>
_______________________________________

From report at bugs.python.org  Tue Nov 30 14:16:24 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 30 Nov 2010 13:16:24 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291122984.71.0.138896746302.issue10576@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Hi, as I stated, the original patch was simply our original implementation.
Here is a new patch.  It is simpler:
1) it exposes a gc.callbacks list where users can register themselves, in the spirit of sys.meta_path
2) One can have multiple callbacks
3) Improve error handling
4) The callback is called with a "phase" argument, currently 0 for start, and 1 for the end.

Let's start bikeshedding the calling signature.  I like having a single callback, since multiple callables are a nuisance to manage.

Once we agree, I'll post a patch for the documentation, and unittests.

----------
Added file: http://bugs.python.org/file19884/gccallback2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Tue Nov 30 14:24:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 13:24:21 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291122984.71.0.138896746302.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291123456.3538.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Let's start bikeshedding the calling signature.  I like having a
> single callback, since multiple callables are a nuisance to manage.

IMO the callback should have a second argument as a dict containing
various statistics that we can expand over time. The generation number,
for example, should be present.

As for the phase number, if 0 means start and 1 means end, you can't
decently add another phase anyway (having 2 mean "somewhere between 0
and 1" would be completely confusing).

PS : please don't use C++-style comments in your patch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Tue Nov 30 14:27:42 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Tue, 30 Nov 2010 13:27:42 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291123662.5.0.838701092194.issue10576@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

You are right, Antoine.
How about a string and a dict?  the string can be "start" and "stop" and we can add interesting information to the dict as you suggest.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Tue Nov 30 14:27:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 13:27:50 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291114806.49.0.579131105202.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291123665.3538.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> pitrou: actually that seems a bit suspect now... you need to handle
> 'data' differently depending on its type,

Yes, but you can't know all appropriate types in advance, so it's better
to try and catch the TypeError.

I don't understand your changes in Lib/urllib/request.py. len(data) will
raise anyway.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 15:53:51 2010
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 30 Nov 2010 14:53:51 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291128831.51.0.350043740266.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

I don't fully understand Lib/urllib/request.py either, I just ported it and ran the unittests... it seems like what it does is that if you send an iterator through as 'data' you can't know the length in advance, and rather than let the len(data) raise an exception catlee thought it's better to raise an exception to tell the user exactly why the code failed (ie, because the user sent an iterator and there's no way to meaningfully find the Content-Length of that).

As for the catching exceptions vs using isinstance: I thought about it for a while, I think something like this feels right to me:

  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))


anyway, calling iter(data) is equivalent to calling data.__iter__(), so catching the exception is equivalent to hasattr(data, '__iter__'), which is roughly the same as isinstance(data, collections.Iterable). so we try the most straightforward method (sending everything) then if that fails, data is either an iterator or a wrong type.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 16:33:30 2010
From: report at bugs.python.org (Ron Adam)
Date: Tue, 30 Nov 2010 15:33:30 +0000
Subject: [issue10588] imp.find_module raises unexpected SyntaxError
In-Reply-To: <1291109752.1.0.382539471745.issue10588@psf.upfronthosting.co.za>
Message-ID: <1291131210.71.0.454482595534.issue10588@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/issue10588>
_______________________________________

From report at bugs.python.org  Tue Nov 30 16:35:37 2010
From: report at bugs.python.org (Davide Rizzo)
Date: Tue, 30 Nov 2010 15:35:37 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291131337.78.0.341827077103.issue3243@psf.upfronthosting.co.za>


Davide Rizzo <sorcio at gmail.com> added the comment:

> len(data) will raise anyway.

No, it won't, if the iterable happens to be a sequence.

----------
nosy: +davide.rizzo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 16:43:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 15:43:51 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291131337.78.0.341827077103.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291131827.3538.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > len(data) will raise anyway.
> 
> No, it won't, if the iterable happens to be a sequence.

Well, it seems the patch is confused between iterable and iterator. Only
iterators have a __next__, but they usually don't have a __len__.

The patch should really check for iterables, so it should use:

    if isinstance(data, collections.Iterable)
        raise ValueError#etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 16:53:41 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 30 Nov 2010 15:53:41 +0000
Subject: [issue9873] urllib.parse: Allow bytes in some APIs that use string
	literals internally
In-Reply-To: <1284643512.64.0.708677047597.issue9873@psf.upfronthosting.co.za>
Message-ID: <1291132421.71.0.99945823855.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Committed in r86889

The docs changes should soon be live at:
http://docs.python.org/dev/library/urllib.parse.html

If anyone would like to suggest changes to the wording of the docs for post beta1, or finds additional corner cases that the new bytes handling can't cope with, feel free to create a new issue.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Tue Nov 30 16:55:45 2010
From: report at bugs.python.org (Xuanji Li)
Date: Tue, 30 Nov 2010 15:55:45 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291132545.06.0.604337160417.issue3243@psf.upfronthosting.co.za>


Xuanji Li <xuanji at gmail.com> added the comment:

davide: yeah, hasattr("lol", '__next__') == False, even though strings are Iterable; so for strings and other such sequences the len(data) line will be executed. So technically we shouldn't say "No Content-Length specified for iterable body" but we should say "No Content-Length specified for iterable body that is not a sequence". 

Basically, this whole patch (both parts of it) will be much better off iif there is a clean way to say "a is an iterable but a is not a sequence", because even though b'this is a message' is Iterable, we want to treat it differently compared to, say, a generator object; we do NOT want to use the Iterator features (iter, next) of it, we want to use the sequencey features (by sending the whole chunk of it, by calling len)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 17:03:09 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 30 Nov 2010 16:03:09 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291132989.44.0.872118555807.issue3243@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Xuanji, a wording which does convey the approximate meaning is fine. I think, the Exception error messages will help the people based on the Context.

- Lets have the ValueError raised from the urllib/request.py. Changing it to isinstance(data,collections.Iterable) as Antoine suggested is okay here too.
- Same change for http.client code checking for an Iterable as specified in msg122905

tests are fine. Docs and NEWS should be updated.

Georg: Is it okay, if we push this feature in before Dec 4th, beta1 release?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 17:07:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 16:07:37 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291133257.53.0.702262751372.issue3243@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

One way to check that it's bytes-compatible is to take a memoryview of it:

>>> memoryview(b"abc")
<memory at 0x1cf5120>
>>> memoryview(bytearray(b"abc"))
<memory at 0x1cf55a0>
>>> memoryview(array.array('b', b"abc"))
<memory at 0x1cf52a0>

>>> memoryview([b"abc"])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot make memory view because object does not have the buffer interface
>>> memoryview("abc")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: cannot make memory view because object does not have the buffer interface

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 17:10:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 16:10:27 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1291132989.44.0.872118555807.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291133423.3538.27.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> - Lets have the ValueError raised from the urllib/request.py. Changing
> it to isinstance(data,collections.Iterable) as Antoine suggested is
> okay here too.

Xuanji is right: it's not. We want bytes to be accepted, and it's an
iterable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 17:10:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 16:10:47 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291123662.5.0.838701092194.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291133443.3538.28.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> You are right, Antoine.
> How about a string and a dict?  the string can be "start" and "stop"
> and we can add interesting information to the dict as you suggest.

Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Tue Nov 30 17:32:56 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 30 Nov 2010 16:32:56 +0000
Subject: [issue10576] Add a progress callback to gcmodule
In-Reply-To: <1291033990.01.0.373880351287.issue10576@psf.upfronthosting.co.za>
Message-ID: <1291134776.17.0.592547520989.issue10576@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

> How about a string and a dict?  the string can be "start" and "stop"
> and we can add interesting information to the dict as you suggest.

I like where this is headed.  How about putting the string in the dict, too?

d['phase'] = 'start'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10576>
_______________________________________

From report at bugs.python.org  Tue Nov 30 17:37:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 16:37:47 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291135067.89.0.39569474795.issue3243@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Answering to myself, sorry. memoryview() does return the right answer of whether the object supports the buffer interface, *however* it doesn't mean the len() will be right. For example, take an array.array of ints:

>>> memoryview(array.array("I", [1,2,3]))
<memory at 0x1cf5720>
>>> len(array.array("I", [1,2,3]))
3
>>> len(memoryview(array.array("I", [1,2,3])))
3
>>> len(bytes(array.array("I", [1,2,3])))
12

len() returns 3 but the number of bytes written out by sendall() will really be 12...

*However*, the right len can be calculated using the memoryview:

>>> m = memoryview(array.array("I", [1,2,3]))
>>> len(m) * m.itemsize
12

(without actually converting to a bytes object, so all this is cheap even for very large buffers)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 17:50:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Nov 2010 16:50:46 +0000
Subject: [issue1079] decode_header does not follow RFC 2047
In-Reply-To: <1188637019.25.0.0476259625696.issue1079@psf.upfronthosting.co.za>
Message-ID: <1291135846.82.0.688681879045.issue1079@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1079>
_______________________________________

From report at bugs.python.org  Tue Nov 30 17:57:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 30 Nov 2010 16:57:51 +0000
Subject: [issue10552] Tools/unicode/gencodec.py error
In-Reply-To: <1290889753.14.0.0688566147025.issue10552@psf.upfronthosting.co.za>
Message-ID: <1291136271.48.0.939675433357.issue10552@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 86891.  Keeping open to address Mac issue.

----------
assignee:  -> belopolsky
components: +Macintosh
priority: normal -> low
stage: commit review -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10552>
_______________________________________

From report at bugs.python.org  Tue Nov 30 18:05:44 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 30 Nov 2010 17:05:44 +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: <1291136744.09.0.721095037279.issue6280@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am going to close this as "rejected" unless someone objects.  The benefit is too small to make users suffer through the deprecation process.

----------
resolution:  -> rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6280>
_______________________________________

From report at bugs.python.org  Tue Nov 30 18:05:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Nov 2010 17:05:57 +0000
Subject: [issue10574] email.header.decode_header fails if the string contains
	multiple directives
In-Reply-To: <1291006742.3.0.976657796626.issue10574@psf.upfronthosting.co.za>
Message-ID: <1291136757.37.0.0353161103665.issue10574@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Note that none of your examples are valid encoded words, so given that email currently does strict parsing, the fact that it is not attempting to decode those words is technically correct.  

However, I agree that it would be better for it to do a "best guess" decoding of the invalid encoded words.

It should be possible to "fix" this case by simply replacing '?==?' with '?= =?' before decoding (blanks between encoded words are ignored when decoding, per the RFC, which the author of the package producing these invalid headers probably didn't realize).

See also #1079 and #8132.

I have to think about whether or not all of these can be considered fixes (based on Postel's law) or if tolerant parsing should be considered a feature request.  I'll probably combine these into a single issue at some point.

Out of curiosity, which email program is it that is producing these invalid headers?

----------
assignee:  -> r.david.murray
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10574>
_______________________________________

From report at bugs.python.org  Tue Nov 30 18:09:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 30 Nov 2010 17:09:06 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1291136946.53.0.664288173462.issue1170@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Adding #10587 because we need to figure out the exact meaning of str.isspace() etc. first.  It is possible that for proper operation shlex should consult unicodedata directly.

----------
dependencies: +Document the meaning of str methods

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Tue Nov 30 18:13:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 30 Nov 2010 17:13:02 +0000
Subject: [issue1706039] Added clearerr() to clear EOF state
Message-ID: <1291137182.99.0.294175143871.issue1706039@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I don't know how to reproduce the issue and without unit tests this patch cannot be committed.

----------
assignee: belopolsky -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706039>
_______________________________________

From report at bugs.python.org  Tue Nov 30 18:23:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 30 Nov 2010 17:23:53 +0000
Subject: [issue3243] Support iterable bodies in httplib
In-Reply-To: <1214848938.76.0.928668674728.issue3243@psf.upfronthosting.co.za>
Message-ID: <1291137833.88.0.26231625532.issue3243@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> hasattr("lol", '__next__') == False, even though strings are Iterable

FYI, magic methods are looked up on the class, not on the instance.  That?s why ABCs are the right thing to use here.  http://docs.python.org/dev/reference/datamodel#special-method-names

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3243>
_______________________________________

From report at bugs.python.org  Tue Nov 30 18:26:08 2010
From: report at bugs.python.org (Scott Dial)
Date: Tue, 30 Nov 2010 17:26:08 +0000
Subject: [issue1706039] Added clearerr() to clear EOF state
Message-ID: <1291137968.93.0.15335536149.issue1706039@psf.upfronthosting.co.za>


Scott Dial <scott at scottdial.com> added the comment:

The patch includes unittests; the issue is that the tests pass without the changes. That is an entirely different state to be in. The tests should be committed unless somebody wants to object to the behavior that they are testing (although I believe this behavior is already codified in documentation). If the tests start failing on someone's platform, then you have a patch already waiting to be applied. Nevertheless, I don't see the harm in the patch as-is, because it is a quite innocuous change to Py_UniversalNewlineFgets(), unless (again) you want to argue about the correctness of that change despite no test failing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706039>
_______________________________________

From report at bugs.python.org  Tue Nov 30 18:32:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 30 Nov 2010 17:32:24 +0000
Subject: [issue9598] untabify.py fails on files that contain non-ascii
	characters
In-Reply-To: <1281740774.41.0.842761146652.issue9598@psf.upfronthosting.co.za>
Message-ID: <1291138344.67.0.403442489357.issue9598@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed revision 86893 that makes untabify.py respect encoding cookie in the files it processes.  I don't think there is anything else that needs to be done here.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9598>
_______________________________________

From report at bugs.python.org  Tue Nov 30 18:33:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Nov 2010 17:33:57 +0000
Subject: [issue10551] mimetypes read from the registry should not overwrite
	standard mime mappings
In-Reply-To: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>
Message-ID: <1291138437.85.0.622218338799.issue10551@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Kovid: so essentially what you are saying is that the windows platform is broken with respect to MIME types and with respect to its security model.  Why am I not surprised? :)

You would have the same problem if software installation altered the /etc/mimetypes file on a unix box and created weird entries.  Perhaps unix programmers are just better disciplined?

Reading the registry first and having the built in settings override would IMO defeat the purpose of reading the values from the registry: those are (theoretically!!) the settings the user chose to change.

However, working around it in your program should be simple: just call mimetypes.init with an empty file list.  The windows registry is only read if the files parameter is None.  This will also give you consistent behavior on windows and unix: only the default mime types in the mimetypes module will be used.  If, on the other hand, you want to retain the Unix behavior, you can pass init mimetypes.knownfiles instead of the empty list.

(By they way, thanks very much for calibre, I have used the CLI tools to great benefit, and love the fact that the CLI is the basis of the program.)

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10551>
_______________________________________

From report at bugs.python.org  Tue Nov 30 19:07:51 2010
From: report at bugs.python.org (Kovid Goyal)
Date: Tue, 30 Nov 2010 18:07:51 +0000
Subject: [issue10551] mimetypes read from the registry should not overwrite
	standard mime mappings
In-Reply-To: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>
Message-ID: <1291140471.35.0.353656057225.issue10551@psf.upfronthosting.co.za>


Kovid Goyal <kovid at kovidgoyal.net> added the comment:

It is, of course, your decision, but IMO, since the mimetypes database in windows appears to be always broken, the default behavior of the mimetypes module in python 2.7 on windows is broken for most (all?) windows installs. For me personally, it doesn't matter anymore, as I have already fixed calibre, but it would be surprising/unexpected behavior for someone new to using mimetypes.py on windows. Certainly, my expectation (perhaps naively) was that guess_type('image.jpg') would always return 'image/jpeg'. 

Users on windows rarely (ever?) modify the registry to change mimetypes. The only thing that does change mimetypes is installed software, without the users' knowledge/consent. So treating the registry as a reliable store of mime information, is not a good idea. 

On unix, the knownfiles are system files. I dont know about OS X, but on linux, since most software is installed by package managers, the package managers usually have policies that prevent application installs from clobbering system files. And of course, running userland applications dont have the necessary privileges to modify the files. 

Out of curiosity, what is the upside of reading mimetypes from the registry, given that it's information cannot be trusted?

And you're most welcome, for calibre :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10551>
_______________________________________

From report at bugs.python.org  Tue Nov 30 19:42:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 30 Nov 2010 18:42:40 +0000
Subject: [issue10551] mimetypes read from the registry should not overwrite
	standard mime mappings
In-Reply-To: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>
Message-ID: <1291142560.39.0.6899656759.issue10551@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I would expect that it would not be people new to mimetypes that would have the issues, but people like you for whom the behavior on Windows has changed.  And this is indeed a concern.

The people involved in making the windows mimetypes enhancement are nosy on this ticket, perhaps they will have thoughts on the issue of the (in)validity of the windows mime data.

----------
status: closed -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10551>
_______________________________________

From report at bugs.python.org  Tue Nov 30 19:53:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 30 Nov 2010 18:53:57 +0000
Subject: [issue10587] Document the meaning of str methods
In-Reply-To: <1291096006.2.0.0136231958849.issue10587@psf.upfronthosting.co.za>
Message-ID: <1291143237.56.0.478012941258.issue10587@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What is the issue that you are reporting? that the status quo should be documented, or that isalpha is wrong? These are independent - don't mix them.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10587>
_______________________________________

From report at bugs.python.org  Tue Nov 30 19:56:43 2010
From: report at bugs.python.org (Kovid Goyal)
Date: Tue, 30 Nov 2010 18:56:43 +0000
Subject: [issue10551] mimetypes read from the registry should not overwrite
	standard mime mappings
In-Reply-To: <1290885326.33.0.141249546234.issue10551@psf.upfronthosting.co.za>
Message-ID: <1291143403.69.0.517571028387.issue10551@psf.upfronthosting.co.za>


Kovid Goyal <kovid at kovidgoyal.net> added the comment:

I actually had in mind people that (like me) develop primarily on unix and assume that mimetypes works the same way on both windows and unix. Of course, the changed behavior is also a concern.

At the very least, I would encourage the addition of a warning to the documentation of the mimetypes module.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10551>
_______________________________________

From report at bugs.python.org  Tue Nov 30 20:00:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 30 Nov 2010 19:00:34 +0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1291143634.3.0.188661019685.issue1170@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The key requirement to consider for in POSIX compatible mode is, well, POSIX compatibility, which is defined in

http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_03

Now, POSIX declares that what <blank> is depends on LC_CTYPE (character class blank). I'd argue that if the objective is to behave exactly like the shell, it really should be doing that (i.e. work in a locale-aware manner).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
_______________________________________

From report at bugs.python.org  Tue Nov 30 20:05:53 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 30 Nov 2010 19:05:53 +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: <1291143953.85.0.0204032538698.issue10589@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <stutzbach at google.com>:

The I/O ABC documentation has a blanket disclaimer at the top:

    "The abstract base classes also provide default implementations of some methods in order to help implementation of concrete stream classes. For example, BufferedIOBase provides unoptimized implementations of readinto() and readline()."

Which effectively means that to subclass one of them requires digging into Lib/_pyio.py to figure out which methods provide useful implementations.

It would be handy to have a table, similar to the one for the collections ABCs [1], that spells out which methods are provided.

[1]: http://docs.python.org/py3k/library/collections.html#abcs-abstract-base-classes

I hope to have a patch ready sometime within the next week.

----------
assignee: stutzbach
components: Documentation
messages: 122930
nosy: stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: I/O ABC docs should specify which methods have implementations
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10589>
_______________________________________

From report at bugs.python.org  Tue Nov 30 20:08:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 19:08:02 +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: <1291144082.58.0.893937181375.issue10589@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/issue10589>
_______________________________________

From report at bugs.python.org  Tue Nov 30 20:10:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 30 Nov 2010 19:10:51 +0000
Subject: [issue10587] Document the meaning of str methods
In-Reply-To: <1291143237.56.0.478012941258.issue10587@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=FthoSgHv7_JLVxD7=HezDOZDKQm-7KBowhqDK@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Nov 30, 2010 at 1:53 PM, Martin v. L?wis <report at bugs.python.org> wrote:
..
> What is the issue that you are reporting? that the status quo should be documented, or that isalpha is wrong?
> These are independent - don't mix them.

This is a documentation issue.  I don't say that str.isalpha() is
necessarily wrong.  (If unicodedata had an isAlphabetic() menthod
defined as Lu + Ll + Lt + Lm + Lo, I would file a bug report for
that.)   Here, I just want to mention that proper str.isalpha()
definition is subject to debate and it being defined as Lu + Ll + Lt +
Lm + Lo may need to be marked as CPython implementation detail.  Note
that the Unicode book (sorry, don't have the page reference) advises
not to rely on catch-all APIs such as isAlphabetic(), but consult the
underlying properties directly.  I tend to agree with that because
some programs may want to treat say Roman numerals as letters and some
as numbers, so whether isAlphabetic() should include Nl category is
better left to the application.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10587>
_______________________________________

From report at bugs.python.org  Tue Nov 30 20:32:08 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Nov 2010 19:32:08 +0000
Subject: [issue7830] Flatten nested functools.partial
In-Reply-To: <1265051251.66.0.305258896073.issue7830@psf.upfronthosting.co.za>
Message-ID: <1291145528.85.0.484601741099.issue7830@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Alexander, I don't see anything wrong with patch, nor anything compelling about it either.   It's your choice whether or not to apply.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7830>
_______________________________________

From report at bugs.python.org  Tue Nov 30 20:37:41 2010
From: report at bugs.python.org (Thomas Ryan)
Date: Tue, 30 Nov 2010 19:37:41 +0000
Subject: [issue10590] Parameter type error for xml.sax.parseString(string, ...)
In-Reply-To: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za>
Message-ID: <1291145861.74.0.873169501029.issue10590@psf.upfronthosting.co.za>


New submission from Thomas Ryan <tom.a.ryan at gmail.com>:

In 3.1.3, 3.1.2, maybe earlier...

xml.sax.parseString(string, handler, error_handler=handler.ErrorHandler())

Source code requires bytes, not a string as implied by function name and by the documentation.

Exception thrown for strings.

Since the name includes "string" the source should probably be fixed.
Or at least update the documentation.

Someday replace/augment parseString() with parseBytes()?

----------
components: XML
messages: 122933
nosy: Thomas.Ryan
priority: normal
severity: normal
status: open
title: Parameter type error for xml.sax.parseString(string, ...)
type: behavior
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10590>
_______________________________________

From report at bugs.python.org  Tue Nov 30 20:51:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 30 Nov 2010 19:51:15 +0000
Subject: [issue7830] Flatten nested functools.partial
In-Reply-To: <1265051251.66.0.305258896073.issue7830@psf.upfronthosting.co.za>
Message-ID: <1291146675.16.0.172173318452.issue7830@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The original motivation for the patch was that if partial() objects are guaranteed to be flat, it would simplify code that deals with them.  See issue4331 for one example.

With a "conservative" patch, however, it will still be possible to create nested partials and the code consuming partials should be ready for that.

----------
keywords:  -needs review
resolution:  -> rejected
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7830>
_______________________________________

From report at bugs.python.org  Tue Nov 30 22:09:19 2010
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Tue, 30 Nov 2010 21:09:19 +0000
Subject: [issue8084] pep-0370 on osx duplicates existing functionality
In-Reply-To: <1267964951.32.0.7992829434.issue8084@psf.upfronthosting.co.za>
Message-ID: <1291151359.13.0.507161852604.issue8084@psf.upfronthosting.co.za>


Glyph Lefkowitz <glyph at twistedmatrix.com> added the comment:

Would it be possible to have this reverted for 2.7.2 / 3.2.1, and restore ~/.local _and_ ~/Library as equally valid locations for python code?

As I tried to explain on the mailing list, this change basically introduces a regression, and nothing else.  Sorry I did not comment on the ticket at the time.

Previously it was possible to maintain a single "~/.pydistutils.cfg" for UNIX-like OSes, which would allow 'python setup.py install', 'pip install' and 'easy_install' to function without adding a 'sudo' in front of them, or any command-line options.  This is important since easy_install doesn't expose a '--user'.  Now, there needs to be a specific, separate config file for OS X installs.

Also, it was previously possible to pass a sane value for '--prefix', but now there is no such value.  This makes it much more difficult to, for example:

  cd my-c-dependency
  ./configure --prefix ~/.local
  cd my-python-project
  python setup.py install --prefix ~/.local

since Python code with C dependencies will sometimes attempt to discover the location of include files and the like via the install prefix.

'setup.py install --user' (the only remaining installation mechanism which actually works out of the box on a mac) will now place scripts into ~/Library/Python/x.y/bin, which seems a singularly unhelpful location.  Again, if there are C and Python programs which interact, I now need 2 locations on my $PATH instead of one.

I don't understand what this change buys anyone.  If you're treating the Mac python as a UNIX-like environment, it just spuriously breaks things.  But if you're treating it as a Mac-like environment (i.e. not using a terminal), the right place to put your Python code is _inside a (framework or application) bundle_, not lying around your home directory.

Also, if there is interest in properly honoring Mac filesystem conventions, there are APIs for doing that, as documented here: <http://developer.apple.com/library/mac/#documentation/MacOSX/Conceptual/BPFileSystem/Articles/Domains.html>.  Manually enumerating the user domain while ignoring, for example, the network domain, seems half-hearted and arbitrary.

----------
nosy: +glyph

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8084>
_______________________________________

From report at bugs.python.org  Tue Nov 30 22:47:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 21:47:04 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1291153624.13.0.254164841752.issue8685@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Raymond, unless you object, I'd like to commit this before beta1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Tue Nov 30 22:54:58 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 30 Nov 2010 21:54:58 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1291154098.83.0.894651933498.issue8685@psf.upfronthosting.co.za>


Changes by Philip Jenvey <pjenvey at underboss.org>:


----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Tue Nov 30 22:56:24 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Nov 2010 21:56:24 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1291154184.18.0.268301854579.issue8685@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thx.

----------
assignee: rhettinger -> pitrou
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:03:39 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 30 Nov 2010 22:03:39 +0000
Subject: [issue10262] Add --soabi option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1291154619.99.0.841894331111.issue10262@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Of course, you don't change configure directly, you change configure.in and let autoconf update the configure (but you already know that I'm sure :).

The patch looks fairly reasonable, though I haven't tried it.  One question: does $SO have the same value after your patch as before?  That's a variable available via sysconfig and it looks like you're removing a block of code that sets it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:12:27 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Nov 2010 22:12:27 +0000
Subject: [issue10262] Add --soabi option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1291155147.7.0.235345382289.issue10262@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The value of get_config_var("SO") is the same as before, something like ".cpython-32.so" by default on Linux. (see, I just moved the line SO=.$SOABI$SO at the bottom of the patch).

In the C file dynload_shlib.c, I chose the names SO_BASE for the "simple" extension (.so) and SO_EXTRA for the "decorated" extension (.cpython-32.so)

Is there a way to write unit tests for all this? This would prove that the default behavior is the same as before.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:15:37 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 30 Nov 2010 22:15:37 +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: <1291155337.84.0.431997193184.issue10589@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

+io and doc people

Attached is a simple patch to add a table to the documentation summarizing the I/O ABCs.

----------
keywords: +patch
nosy: +benjamin.peterson, ezio.melotti, georg.brandl
Added file: http://bugs.python.org/file19885/io-abc.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10589>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:22:08 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 30 Nov 2010 22:22:08 +0000
Subject: [issue9915] speeding up sorting with a key
In-Reply-To: <1285099412.4.0.33526475148.issue9915@psf.upfronthosting.co.za>
Message-ID: <1291155728.19.0.316022899953.issue9915@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

+1 on the basic idea of moving elements in the keys and values arrays at the same time thereby eliminating the fragmented memory overhead of the sortwrapper indirection.

I would like the patch to be restricted to just that change.  The other tweaks are not convincing (relying on compiler and processor specific optimizations that vary across platforms).  Instead, try to minimize the patch, making as few changes as possible to manipulation both arrays.  Also, try to follow the C style of the other code in the standard library -- the current patch has a different flavor to say the least ;-)

Ideally, the code will have the same look and feel as it does now (so that the Timsort remains recognizable to Tim ;-).  This code doesn't just need to run fast, it needs to serve as a readable model for anyone else trying to implement the algorithm.

If you still want the other tweaks, I recommend putting them in a separate patch afterwards and consider deferring them to 3.3.  It's a little late in the dev cycle to make lots of microscopic changes that may introduce a bug or unexpected behavior or perform weirdly on one of the less used platforms.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9915>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:24:33 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Tue, 30 Nov 2010 22:24:33 +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: <1291155873.04.0.646281813133.issue10589@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
nosy: +docs at python, fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10589>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:24:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 22:24:56 +0000
Subject: [issue8685] set(range(100000)).difference(set()) is slow
In-Reply-To: <1273568659.49.0.865922101958.issue8685@psf.upfronthosting.co.za>
Message-ID: <1291155896.66.0.635335581616.issue8685@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Modified patch committed in r86905. Thanks!

----------
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8685>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:26:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 22:26:19 +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: <1291155979.76.0.451202385905.issue10589@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What does "unsupported" mean? "Abstract" would look more exact.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10589>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:28:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 30 Nov 2010 22:28:02 +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: <1291156082.63.0.601748273025.issue10589@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not sure what "unsupported methods" means.  E.g. "readinto" is listed as provided by RawIOBase in the doc text.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10589>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:28:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 22:28:46 +0000
Subject: [issue10591] test_os failure in refleak runs
In-Reply-To: <1291156126.42.0.381106886748.issue10591@psf.upfronthosting.co.za>
Message-ID: <1291156126.42.0.381106886748.issue10591@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

$ ./python -m test.regrtest -R 3:2 test_os
[1/1] test_os
[35351 refs]
[35351 refs]
[35352 refs]
beginning 5 repetitions
12345
[35351 refs]
[35351 refs]
[35352 refs]
test test_os failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_os.py", line 898, in test_unicode_name
    self._test_link(self.file1, self.file2)
  File "/home/antoine/py3k/__svn__/Lib/test/test_os.py", line 879, in _test_link
    os.link(file1, file2)
OSError: [Errno 17] File exists

----------
assignee: brian.curtin
components: Tests
messages: 122945
nosy: brian.curtin, pitrou
priority: normal
severity: normal
status: open
title: test_os failure in refleak runs
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10591>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:29:20 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Tue, 30 Nov 2010 22:29:20 +0000
Subject: [issue10262] Add --soabi option to `configure`
In-Reply-To: <1291155147.7.0.235345382289.issue10262@psf.upfronthosting.co.za>
Message-ID: <20101130172911.463b2226@mission>


Barry A. Warsaw <barry at python.org> added the comment:

On Nov 30, 2010, at 10:12 PM, Amaury Forgeot d'Arc wrote:

>The value of get_config_var("SO") is the same as before, something like
>".cpython-32.so" by default on Linux. (see, I just moved the line
>SO=.$SOABI$SO at the bottom of the patch).

Cool, thanks.

>In the C file dynload_shlib.c, I chose the names SO_BASE for the "simple"
>extension (.so) and SO_EXTRA for the "decorated" extension (.cpython-32.so)

Since I used SOABI earlier, what do you think about SOBASE and SOEXTRA for
consistency?

>Is there a way to write unit tests for all this? This would prove that the
>default behavior is the same as before.

It would, but I couldn't think of a way to do that reliably across platform.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:31:11 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 30 Nov 2010 22:31:11 +0000
Subject: [issue10262] Add --soabi option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1291156271.56.0.117105485894.issue10262@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Let's test Linux at least, then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:36:26 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 30 Nov 2010 22:36:26 +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: <1291156586.97.0.696738327069.issue10589@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

> What does "unsupported" mean? "Abstract" would look more exact.

It means they raise io.UnsupportedOperation when called (unless the subclass overrides them to do something else).  

They are not marked with @abstractmethod, so "Abstract" would be wrong.

It should be a bit more clear in context.  Here's a link to the point in the documentation where the table would fit:
http://docs.python.org/dev/py3k/library/io.html#class-hierarchy

The most relevant bit is: "implementations are allowed to raise UnsupportedOperation if they do not support a given operation."

> E.g. "readinto" is listed as provided by RawIOBase in the doc text.

The doc text describes the API.  That is, it describes what the readinto method should do if a subclass of RawIOBase decides to implement it.  The existing text doesn't contain any clues as to which methods contain useful implementations versus which will raise io.UnsupportedOperation if not overridden.  Hence the need for the table.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10589>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:40:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 22:40:05 +0000
Subject: [issue10589] I/O ABC docs should specify which methods have
	implementations
In-Reply-To: <1291156586.97.0.696738327069.issue10589@psf.upfronthosting.co.za>
Message-ID: <1291156801.8628.16.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > What does "unsupported" mean? "Abstract" would look more exact.
> 
> It means they raise io.UnsupportedOperation when called (unless the
> subclass overrides them to do something else).  
> 
> They are not marked with @abstractmethod, so "Abstract" would be
> wrong.

Except that "unsupported" is even more wrong, because it makes it look
like that these methods are not supported by the respective ABCs.
Actually, what happens is that the default implementations are stubs. If
those methods weren't "supported" at all they wouldn't be defined in the
first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10589>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:41:27 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Nov 2010 22:41:27 +0000
Subject: [issue10464] netrc module not parsing passwords containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1291156887.87.0.544346523401.issue10464@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Patch looks good to me. Supplied test fails before and works after fix applied.

----------
nosy: +ned.deily
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10464>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:41:36 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 30 Nov 2010 22:41:36 +0000
Subject: [issue10464] netrc module not parsing passwords containing #s.
In-Reply-To: <1290245320.19.0.887419717263.issue10464@psf.upfronthosting.co.za>
Message-ID: <1291156896.77.0.106503635309.issue10464@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Removed file: http://bugs.python.org/file19666/issue_10231_testcase.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10464>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:44:27 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 30 Nov 2010 22:44:27 +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: <1291157067.6.0.0211042165825.issue10589@psf.upfronthosting.co.za>


Daniel Stutzbach <stutzbach at google.com> added the comment:

Other suggestions for a better name for that column are certainly welcome. :-)

"Stub Methods"?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10589>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:45:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 22:45:13 +0000
Subject: [issue10589] I/O ABC docs should specify which methods have
	implementations
In-Reply-To: <1291157067.6.0.0211042165825.issue10589@psf.upfronthosting.co.za>
Message-ID: <1291157108.8628.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Other suggestions for a better name for that column are certainly welcome. :-)
> 
> "Stub Methods"?

Fine with me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10589>
_______________________________________

From report at bugs.python.org  Tue Nov 30 23:45:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 30 Nov 2010 22:45:28 +0000
Subject: [issue10478] Ctrl-C locks up the interpreter
In-Reply-To: <1290312472.5.0.0808563549791.issue10478@psf.upfronthosting.co.za>
Message-ID: <1291157128.37.0.64975022233.issue10478@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10478>
_______________________________________