From report at bugs.python.org  Fri Oct  1 00:17:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 30 Sep 2010 22:17:18 +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: <1285885038.5.0.631481574752.issue10002@psf.upfronthosting.co.za>


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

Please run "msiexec /i python-2.7.msi /l*v python.log", and compress and attach the resulting log file.

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

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

From report at bugs.python.org  Fri Oct  1 00:26:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Sep 2010 22:26:03 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285885563.17.0.331688436565.issue9962@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Fri Oct  1 00:37:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 30 Sep 2010 22:37:03 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285886223.75.0.765817890428.issue9962@psf.upfronthosting.co.za>


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

Here is a patch fixing these issues.

----------
Added file: http://bugs.python.org/file19074/gzipfixup.patch

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

From report at bugs.python.org  Fri Oct  1 00:43:06 2010
From: report at bugs.python.org (joblack)
Date: Thu, 30 Sep 2010 22:43:06 +0000
Subject: [issue10002] requested log file
In-Reply-To: <1285882629.62.0.145594356076.issue10002@psf.upfronthosting.co.za>
Message-ID: <1285886586.48.0.885855327901.issue10002@psf.upfronthosting.co.za>


joblack <johannes.black at gmail.com> added the comment:

requested log file

----------
title: Installer doesn't install on Windows Server 2008 DataCenter R2 -> requested log file
Added file: http://bugs.python.org/file19075/python.zip

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

From report at bugs.python.org  Fri Oct  1 01:33:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 30 Sep 2010 23:33:29 +0000
Subject: [issue10002] requested log file
In-Reply-To: <1285882629.62.0.145594356076.issue10002@psf.upfronthosting.co.za>
Message-ID: <1285889609.02.0.947938580602.issue10002@psf.upfronthosting.co.za>


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

In this specific run, the critical error was this:

MSI (s) (38:74) [00:36:38:068]: Assembly Error:Der angeforderte Vorgang war nicht erfolgreich. Es ist ein Systemneustart erforderlich, um die durchgef?hrten ?nderungen r?ckg?ngig zu machen.

So please do reboot the system, and try again (generating a new log file). It also says

 Assembly Error (sxs): Please look into Component Based Servicing Log located at -89201544ndir\logs\cbs\cbs.log to get more diagnostic information.

So on the chance that this contains additional information, please also put this log file into the next zip file (you might want to screen it for any security-relevant information that you don't want to release).

----------

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

From report at bugs.python.org  Fri Oct  1 01:34:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 30 Sep 2010 23:34:02 +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: <1285889642.01.0.594342512157.issue10002@psf.upfronthosting.co.za>


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


----------
title: requested log file -> Installer doesn't install on Windows Server 2008 DataCenter R2

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

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


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

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

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

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

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

From report at bugs.python.org  Fri Oct  1 03:10:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Oct 2010 01:10:24 +0000
Subject: [issue10001] ~Py_buffer.obj field is undocumented, though not hidden
In-Reply-To: <1285868807.58.0.617972550499.issue10001@psf.upfronthosting.co.za>
Message-ID: <1285895424.84.0.760711862577.issue10001@psf.upfronthosting.co.za>


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

The recommended way is to use PyBuffer_FillInfo() (and then fill in any additional data if necessary), which will set the pointer and incref it itself.

I agree all this is a bit poorly documented.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python, pitrou
stage:  -> needs patch
versions: +Python 2.7, Python 3.1

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

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


Martin <gzlist at googlemail.com> added the comment:

Also, the test seems to set signal handlers and never unset them, which I've also corrected.

----------
keywords: +patch
Added file: http://bugs.python.org/file19076/sigbreak_windows_10003.patch

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

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


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


----------
assignee:  -> brian.curtin
resolution:  -> accepted
stage:  -> patch review
type:  -> behavior
versions:  -Python 3.3

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

From report at bugs.python.org  Fri Oct  1 03:45:48 2010
From: report at bugs.python.org (joblack)
Date: Fri, 01 Oct 2010 01:45:48 +0000
Subject: [issue10002] cbs.log
In-Reply-To: <1285882629.62.0.145594356076.issue10002@psf.upfronthosting.co.za>
Message-ID: <1285897548.13.0.358763160454.issue10002@psf.upfronthosting.co.za>


joblack <johannes.black at gmail.com> added the comment:

cbs.log

----------
title: Installer doesn't install on Windows Server 2008 DataCenter R2 -> cbs.log
Added file: http://bugs.python.org/file19077/CBS.zip

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

From report at bugs.python.org  Fri Oct  1 03:53:17 2010
From: report at bugs.python.org (Steve Holden)
Date: Fri, 01 Oct 2010 01:53:17 +0000
Subject: [issue10000] mark more tests as CPython specific
In-Reply-To: <1285861695.5.0.301447830736.issue10000@psf.upfronthosting.co.za>
Message-ID: <1285897997.25.0.225463846242.issue10000@psf.upfronthosting.co.za>


Steve Holden <steve at holdenweb.com> added the comment:

Of course, but better some record than none due to the overwhelming nature of the task. At least someone else can carry the torch from here.

----------
nosy: +holdenweb

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

From report at bugs.python.org  Fri Oct  1 04:36:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 02:36:24 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1285900584.94.0.420123837791.issue4661@psf.upfronthosting.co.za>


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

New version of the patch that adds many more tests, and handles non-ASCII bytes in header values by changing them to '?'s when the header value is retrieved as a string.  I think I'm half done.  Still to do: generate_bytes, and the doc updates.

By the way, another important reason to use surrogateescape rather than latin1 is that if I miss something and the byte-containing-strings escape, it will be obvious that that is what happened.  Otherwise we're back in Python2 bytes/string conflation land.

I of course make no promises about performance.  And there is an issue there in that every header value access is now wrapped in an additional function call and a regex test, at a minimum, whether there are bytes present in the input or not :(

----------
Added file: http://bugs.python.org/file19078/email_parse_bytes2.diff

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

From report at bugs.python.org  Fri Oct  1 04:41:49 2010
From: report at bugs.python.org (Alexis Metaireau)
Date: Fri, 01 Oct 2010 02:41:49 +0000
Subject: [issue8190] Add a PyPI XML-RPC client module
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1285900909.24.0.793367864662.issue8190@psf.upfronthosting.co.za>


Alexis Metaireau <ametaireau at gmail.com> added the comment:

Please, can you be a bit more precise about the missing features ? I'll be glad to cover them.

----------

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

From report at bugs.python.org  Fri Oct  1 04:48:36 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Fri, 01 Oct 2010 02:48:36 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285901316.51.0.44688788498.issue6608@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

belopolsky
 
I am little worried about my words. I made patch against 2.7-maint branch. But I recognized that patch is not following rules, because of your guidance. Then I uploaded another patch against py3k branch again. and issue6608-p3k.patch could be applied to py3k branch cleanly. If there were any boldness in my words, I'm sorry.

and I'm ready to address any thing left in this issue. :)

----------

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

From report at bugs.python.org  Fri Oct  1 04:50:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 02:50:06 +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: <1285901406.51.0.811186597241.issue10002@psf.upfronthosting.co.za>


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

Please don't change the subject, it changes the bug title, which makes the bug report less useful :)

----------
nosy: +r.david.murray
title: cbs.log -> Installer doesn't install on Windows Server 2008 DataCenter R2

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

From report at bugs.python.org  Fri Oct  1 07:41:33 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Fri, 01 Oct 2010 05:41:33 +0000
Subject: [issue1050268] rfc822.parseaddr is broken,
	breaks sendmail call in smtplib
Message-ID: <1285911693.79.0.53726392251.issue1050268@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

I can confirm this bug. Attached is the test case.

----------
keywords: +patch
nosy: +jfinkels
Added file: http://bugs.python.org/file19079/issue1050268.testcase.patch

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

From report at bugs.python.org  Fri Oct  1 07:49:07 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Fri, 01 Oct 2010 05:49:07 +0000
Subject: [issue1481347] parse_makefile doesn't handle $$  correctly
Message-ID: <1285912147.04.0.198272941582.issue1481347@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

There seems to be a test case for this:

http://svn.python.org/view/python/trunk/Lib/distutils/tests/test_sysconfig.py?view=diff&r1=73340&r2=73341

----------
nosy: +jfinkels

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

From report at bugs.python.org  Fri Oct  1 09:26:14 2010
From: report at bugs.python.org (Lenard Lindstrom)
Date: Fri, 01 Oct 2010 07:26:14 +0000
Subject: [issue10001] ~Py_buffer.obj field is undocumented, though not hidden
In-Reply-To: <1285895424.84.0.760711862577.issue10001@psf.upfronthosting.co.za>
Message-ID: <4CA58D10.1070008@telus.net>


Lenard Lindstrom <len-l at telus.net> added the comment:

This will work for bf_getbuffer, though having PyObject_GetBuffer set 
the obj field before passing it to the callback might be safer. Also, 
this does not address the case with wrapper types like memoryview. What 
happens if ~Py_buffer.obj is not visited in tp_traverse? Should this be 
documented?

----------

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

From report at bugs.python.org  Fri Oct  1 10:59:06 2010
From: report at bugs.python.org (Nick Craig-Wood)
Date: Fri, 01 Oct 2010 08:59:06 +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: <1285923546.22.0.250220088773.issue5131@psf.upfronthosting.co.za>


Nick Craig-Wood <nick at craig-wood.com> added the comment:

Terry J. Reedy (terry.reedy) wrote:
> > IMHO pprint should be able to make a decent job of all the built in types 
>
> Agreed, already true as far as I know, and irrelevant. This issue is not about built-in types in the builtins module, as documented Lib Ref chapter 5 *Built-in Types*. Collections is an Python-coded stdlib  module that happens to import a couple of its classes from _collections, written in C for speed. 

My bad - not precise enough!  I meant all the stdlib types rather than the builtin types.

----------

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

From report at bugs.python.org  Fri Oct  1 12:01:55 2010
From: report at bugs.python.org (Nir Aides)
Date: Fri, 01 Oct 2010 10:01:55 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285927315.72.0.131138059316.issue9962@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Should be min(n, 1024) instead of max(...)

----------

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

From report at bugs.python.org  Fri Oct  1 12:52:33 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 Oct 2010 10:52:33 +0000
Subject: [issue10000] mark more tests as CPython specific
In-Reply-To: <1285861695.5.0.301447830736.issue10000@psf.upfronthosting.co.za>
Message-ID: <1285930353.05.0.456016711101.issue10000@psf.upfronthosting.co.za>


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

Do you want to volunteer, Steve? ;)

----------
nosy: +georg.brandl

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

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


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

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

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

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

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

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


Changes by Thomas Guettler <guettli at thomas-guettler.de>:


Added file: http://bugs.python.org/file19081/broken-subject.msg

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

From report at bugs.python.org  Fri Oct  1 13:16:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Oct 2010 11:16:00 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285927315.72.0.131138059316.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285931755.3188.0.camel@localhost.localdomain>


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

> Should be min(n, 1024) instead of max(...)

Well, no, because we want to buffer a non-trivial amount of bytes for
the next accesses. So, if n < 1024, buffer at least 1024 bytes.

----------

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

From report at bugs.python.org  Fri Oct  1 13:39:27 2010
From: report at bugs.python.org (Nir Aides)
Date: Fri, 01 Oct 2010 11:39:27 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285933167.12.0.802819268956.issue9962@psf.upfronthosting.co.za>


Nir Aides <nir at winpdb.org> added the comment:

Right, I missed the change from self.max_read_chunk to 1024 (read_size). Should not peek() limit to self.max_read_chunk as read() does?

----------

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

From report at bugs.python.org  Fri Oct  1 13:53:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Oct 2010 11:53:27 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285934007.16.0.95659102718.issue8670@psf.upfronthosting.co.za>


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

Update the patch for the new PyUnicode_AsWideCharString() function:
 - use Py_UNICODE_SIZE and SIZEOF_WCHAR_T in the preprocessor tests
 - faster loop: don't use a counter + pointer, but only use pointers (for the stop condition)

The patch is not finished: I have to implement "#elif Py_UNICODE_SIZE == 4 && SIZEOF_WCHAR_T == 2" case.

----------
Added file: http://bugs.python.org/file19082/aswidechar_nonbmp-2.patch

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

From report at bugs.python.org  Fri Oct  1 13:53:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Oct 2010 11:53:40 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285934020.14.0.825569009553.issue8670@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file17322/pyunicode_aswidechar_surrogates-py3k.patch

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

From report at bugs.python.org  Fri Oct  1 13:58:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Oct 2010 11:58:02 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285933167.12.0.802819268956.issue9962@psf.upfronthosting.co.za>
Message-ID: <1285934278.3188.3.camel@localhost.localdomain>


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

> Right, I missed the change from self.max_read_chunk to 1024
> (read_size). Should not peek() limit to self.max_read_chunk as read()
> does?

This is used for the chunking of huge reads, but for peek():
1) there is no chunking (peek() should do at most one raw read)
2) huge reads are not really the use case peek() is intended for

----------

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

From report at bugs.python.org  Fri Oct  1 14:24:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Oct 2010 12:24:59 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285935899.53.0.00828992111431.issue8670@psf.upfronthosting.co.za>


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

Patch version 3:
 - fix unicode_aswidechar if Py_UNICODE_SIZE == SIZEOF_WCHAR_T and w == NULL (return the number of characters, don't write into w!)
 - improve unicode_aswidechar() comment

----------
Added file: http://bugs.python.org/file19083/aswidechar_nonbmp-3.patch

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

From report at bugs.python.org  Fri Oct  1 14:28:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Oct 2010 12:28:36 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285936116.56.0.618887322547.issue8670@psf.upfronthosting.co.za>


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

I don't know how to test "if Py_UNICODE_SIZE == 4 && SIZEOF_WCHAR_T == 2". On Windows, sizeof(wchar_t) is 2, but it looks like Python is not prepared to have Py_UNICODE != wchar_t for is Windows implementation.

wchar_t is 32 bits long on Linux and Mac OS X. So how can I test it? Or should we just drop support of "Py_UNICODE_SIZE == 4 && SIZEOF_WCHAR_T == 2"?

----------

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

From report at bugs.python.org  Fri Oct  1 14:45:01 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 01 Oct 2010 12:45:01 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t) ==
	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285937101.38.0.698684643544.issue8670@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I, too, can't think of any platforms where Py_UNICODE_SIZE == 4 && SIZEOF_WCHAR_T == 2 and I'm not sure what the previous policy has been.  Have you noticed any other code that would set a precedent?

If no one else chimes in, perhaps ask on IRC or python-dev?

----------

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

From report at bugs.python.org  Fri Oct  1 14:46:54 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 01 Oct 2010 12:46:54 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1285936116.56.0.618887322547.issue8670@psf.upfronthosting.co.za>
Message-ID: <4CA5D83B.1020707@egenix.com>


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

STINNER Victor wrote:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
> I don't know how to test "if Py_UNICODE_SIZE == 4 && SIZEOF_WCHAR_T == 2". On Windows, sizeof(wchar_t) is 2, but it looks like Python is not prepared to have Py_UNICODE != wchar_t for is Windows implementation.
>
> wchar_t is 32 bits long on Linux and Mac OS X. So how can I test it? Or should we just drop support of "Py_UNICODE_SIZE == 4 && SIZEOF_WCHAR_T == 2"?

You can tweak the Windows pyconfig.h to use UCS4, AFAIK, if you want to
test drive this case.

But it's probably easier to configure with "gcc -fshort-wchar" on
Linux :-)

Dropping support for this is not a good idea.

----------
title: c_types.c_wchar should not assume that sizeof(wchar_t) == sizeof(Py_UNICODE) -> c_types.c_wchar should not assume that sizeof(wchar_t) ==	sizeof(Py_UNICODE)

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

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


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

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

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

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

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

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


Popa Claudiu <pcmanticore at gmail.com> added the comment:

I meant "Connection class calls the.."

----------

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

From report at bugs.python.org  Fri Oct  1 15:01:42 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 01 Oct 2010 13:01:42 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285938102.22.0.237782334505.issue8670@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> You can tweak the Windows pyconfig.h to use UCS4, AFAIK, if you want to
> test drive this case.

I seem to recall seeing some other code that assumed Windows implied UCS2.  Proceed with caution. ;-)

> But it's probably easier to configure with "gcc -fshort-wchar" on
> Linux :-)

libc will still be using sizeof(wchar_t) == 4, though.  Won't that cause Bad Things to happen when calling libc wide-character functions?

----------

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

From report at bugs.python.org  Fri Oct  1 15:06:05 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 01 Oct 2010 13:06:05 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1285938102.22.0.237782334505.issue8670@psf.upfronthosting.co.za>
Message-ID: <4CA5DCB5.1080407@egenix.com>


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

Daniel Stutzbach wrote:
> 
> Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:
> 
>> You can tweak the Windows pyconfig.h to use UCS4, AFAIK, if you want to
>> test drive this case.
> 
> I seem to recall seeing some other code that assumed Windows implied UCS2.  Proceed with caution. ;-)

Probably, yes. I've never tried it myself.

>> But it's probably easier to configure with "gcc -fshort-wchar" on
>> Linux :-)
> 
> libc will still be using sizeof(wchar_t) == 4, though.  Won't that cause Bad Things to happen when calling libc wide-character functions?

Sure, but this is just about testing an interface, not running
applications :-)

Here's what the GCC man-page has to say:

       -fshort-wchar
           Override the underlying type for wchar_t to be short unsigned int instead
           of the default for the target.  This option is useful for building
           programs to run under WINE.

           Warning: the -fshort-wchar switch causes GCC to generate code that is not
           binary compatible with code generated without that switch.  Use it to
           conform to a non-default application binary interface.

----------

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

From report at bugs.python.org  Fri Oct  1 15:23:54 2010
From: report at bugs.python.org (Anand B Pillai)
Date: Fri, 01 Oct 2010 13:23:54 +0000
Subject: [issue3488] Provide compress/uncompress functions on the gzip module
In-Reply-To: <1217613416.28.0.352724086622.issue3488@psf.upfronthosting.co.za>
Message-ID: <1285939434.03.0.0371351424732.issue3488@psf.upfronthosting.co.za>


Anand B Pillai <abpillai at gmail.com> added the comment:

Okay. Verified as working. Thank you!

----------

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

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


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

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

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

class type3(type):
    pass

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


results in output:

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


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


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

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

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

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

From report at bugs.python.org  Fri Oct  1 15:48:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 13:48:25 +0000
Subject: [issue10005] Postgresql calls undefined method in __str__
In-Reply-To: <1285937921.5.0.29820555696.issue10005@psf.upfronthosting.co.za>
Message-ID: <1285940905.34.0.928582124219.issue10005@psf.upfronthosting.co.za>


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

There is no postgresql client in the Python standard library, you'll need to report this bug on the appropriate project's tracker.

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

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

From report at bugs.python.org  Fri Oct  1 16:06:43 2010
From: report at bugs.python.org (Christoph Burgmer)
Date: Fri, 01 Oct 2010 14:06:43 +0000
Subject: [issue9985] difflib.SequenceMatcher has slightly buggy and
	undocumented caching behavior
In-Reply-To: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za>
Message-ID: <1285942003.01.0.00602073400419.issue9985@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

Here's a test case and a fix for get_matching_blocks() to return the same content on subsequent calls.

----------
keywords: +patch
nosy: +christoph
Added file: http://bugs.python.org/file19084/get_matching_blocks.diff

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

From report at bugs.python.org  Fri Oct  1 16:07:45 2010
From: report at bugs.python.org (Christoph Burgmer)
Date: Fri, 01 Oct 2010 14:07:45 +0000
Subject: [issue9985] difflib.SequenceMatcher has slightly buggy and
	undocumented caching behavior
In-Reply-To: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za>
Message-ID: <1285942065.84.0.518967331039.issue9985@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

BTW, here's the commit that broke the behavior in the first place: http://svn.python.org/view/python/trunk/Lib/difflib.py?r1=54230&r2=59907

----------

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

From report at bugs.python.org  Fri Oct  1 16:09:58 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Fri, 01 Oct 2010 14:09:58 +0000
Subject: [issue10006] non-Pythonic fate of __abstractmethods__
In-Reply-To: <1285940853.14.0.546762707016.issue10006@psf.upfronthosting.co.za>
Message-ID: <1285942198.44.0.174664482512.issue10006@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/issue10006>
_______________________________________

From report at bugs.python.org  Fri Oct  1 16:10:06 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 01 Oct 2010 14:10:06 +0000
Subject: [issue9533] metaclass can't derive from ABC
In-Reply-To: <1281090819.15.0.255356922996.issue9533@psf.upfronthosting.co.za>
Message-ID: <1285942206.67.0.494564639664.issue9533@psf.upfronthosting.co.za>


Daniel Urban <urban.dani+py at gmail.com> added the comment:

If we create a new class, which is a metaclass, and also inherits an ABC, we create a new instance of ABCMeta.

When ABCMeta.__new__ creates the __abstractmethods__ attribute of the new class, it iterates over the __abstractmethods__ attribute of every base class (and checks every name in it, if it's abstract in the new class). One of the base classes of a metaclass is of course type. The type.__abstractmethods__ object is a getset descriptor (its __set__ switches some flags in tp_flags), which isn't iterable, so it raises the exception. 

Ideas for possible solutions:
1. In ABCMeta.__new__ special case type (do not check its __abstractmethods__attribute). 
2. In ABCMeta.__new__ check if the __abstractmethods__ attribute is in fact an iterable, before we try to iterate over it. (I don't think this would be a very good solution, because if a base class' __abstractmethods__ isn't iterable, it should be an error, except if the base class is type itself. So we should special case type anyway.)

I can't come up with a use case for this right now, but I don't see why it shouldn't work.

----------
components: +Library (Lib)

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

From report at bugs.python.org  Fri Oct  1 16:13:10 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 01 Oct 2010 14:13:10 +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: <1285942390.23.0.839471743764.issue10002@psf.upfronthosting.co.za>


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

> Have you tried your Python 2.7 on a Windows Server 2008 R2?

It works on my 2008 R2 Enterprise Edition.

----------
components: +Windows
nosy: +brian.curtin

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

From report at bugs.python.org  Fri Oct  1 16:23:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 01 Oct 2010 14:23:57 +0000
Subject: [issue6608] asctime does not check its input
In-Reply-To: <1248998208.56.0.3155599029.issue6608@psf.upfronthosting.co.za>
Message-ID: <1285943037.27.0.186476843583.issue6608@psf.upfronthosting.co.za>


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

Committed with minor changes in r85137.   Thanks for the patch!

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

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

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


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

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

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

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

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

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

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

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

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


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> Python3.1 cannot build _ssl and _hashlib.

And Python2.7 cannot.

----------

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

From report at bugs.python.org  Fri Oct  1 16:54:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 14:54:02 +0000
Subject: [issue10006] non-Pythonic fate of __abstractmethods__
In-Reply-To: <1285940853.14.0.546762707016.issue10006@psf.upfronthosting.co.za>
Message-ID: <1285944842.08.0.217424515615.issue10006@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/issue10006>
_______________________________________

From report at bugs.python.org  Fri Oct  1 17:03:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 15:03:34 +0000
Subject: [issue10004] irhe
In-Reply-To: <1285931148.27.0.357018449582.issue10004@psf.upfronthosting.co.za>
Message-ID: <1285945414.72.0.733268695253.issue10004@psf.upfronthosting.co.za>


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


----------
title: email/quoprimime.py Exception (with patch) -> irhe

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

From report at bugs.python.org  Fri Oct  1 17:04:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 15:04:04 +0000
Subject: [issue10004] email/quoprimime.py Exception (with patch)
In-Reply-To: <1285931148.27.0.357018449582.issue10004@psf.upfronthosting.co.za>
Message-ID: <1285945444.06.0.707859806959.issue10004@psf.upfronthosting.co.za>


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


----------
title: irhe -> email/quoprimime.py Exception (with patch)

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

From report at bugs.python.org  Fri Oct  1 17:04:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 15:04:48 +0000
Subject: [issue10004] email/quoprimime.py Exception (with patch)
In-Reply-To: <1285931148.27.0.357018449582.issue10004@psf.upfronthosting.co.za>
Message-ID: <1285945488.82.0.0197407286684.issue10004@psf.upfronthosting.co.za>


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

Heh, cut and paste gone mad, sorry about that title change/change back.

I can reproduce this in 3.2, so adding 3.1 and 3.2 to versions.

----------
nosy: +r.david.murray
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Oct  1 17:05:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 15:05:26 +0000
Subject: [issue10004] email/quoprimime.py Exception (with patch)
In-Reply-To: <1285931148.27.0.357018449582.issue10004@psf.upfronthosting.co.za>
Message-ID: <1285945526.8.0.196143166713.issue10004@psf.upfronthosting.co.za>


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


----------
stage:  -> unit test needed
type:  -> behavior

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

From report at bugs.python.org  Fri Oct  1 17:09:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 15:09:44 +0000
Subject: [issue10004] email/quoprimime.py Exception (with patch)
In-Reply-To: <1285931148.27.0.357018449582.issue10004@psf.upfronthosting.co.za>
Message-ID: <1285945784.85.0.00384093747692.issue10004@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/issue10004>
_______________________________________

From report at bugs.python.org  Fri Oct  1 17:28:01 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 15:28:01 +0000
Subject: [issue10004] email/quoprimime.py Exception (with patch)
In-Reply-To: <1285931148.27.0.357018449582.issue10004@psf.upfronthosting.co.za>
Message-ID: <1285946881.96.0.995428227603.issue10004@psf.upfronthosting.co.za>


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

Here is Thomas's patch with a (simpler) unit test included.

----------
Added file: http://bugs.python.org/file19085/quoprime_chars.patch

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

From report at bugs.python.org  Fri Oct  1 17:49:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 15:49:43 +0000
Subject: [issue10004] email/quoprimime.py Exception (with patch)
In-Reply-To: <1285931148.27.0.357018449582.issue10004@psf.upfronthosting.co.za>
Message-ID: <1285948183.18.0.374956105641.issue10004@psf.upfronthosting.co.za>


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

Committed in r85142 for 3.2, r85143 for 3.1, and r85144 for 2.7.

Thanks, Thomas.

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

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

From report at bugs.python.org  Fri Oct  1 17:53:27 2010
From: report at bugs.python.org (Radu Grigore)
Date: Fri, 01 Oct 2010 15:53:27 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1285948407.25.0.673369734917.issue9921@psf.upfronthosting.co.za>


Radu Grigore <radugrigore at gmail.com> added the comment:

I would say something like the following.

The function join(path1, path2) is almost like os.sep.join(path1, path2), but (1) trailing path separators in path1 are ignored and (2) the result is simply path2 when path2 is an absolute path. The call join(path1, path2, path3) is equivalent to join(join(path1, path2), path3), and similarly for more than three paths.

----------

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

From report at bugs.python.org  Fri Oct  1 18:09:23 2010
From: report at bugs.python.org (=?utf-8?q?Brian_Boss=C3=A9?=)
Date: Fri, 01 Oct 2010 16:09:23 +0000
Subject: [issue9974] tokenizer.untokenize not invariant with line continuations
In-Reply-To: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>
Message-ID: <1285949363.72.0.308652516013.issue9974@psf.upfronthosting.co.za>


Brian Boss? <penrif at gmail.com> added the comment:

No idea if I'm getting the patch format right here, but tally ho!

This is keyed from release27-maint

Index: Lib/tokenize.py
===================================================================
--- Lib/tokenize.py	(revision 85136)
+++ Lib/tokenize.py	(working copy)
@@ -184,8 +184,13 @@
 
     def add_whitespace(self, start):
         row, col = start
-        assert row <= self.prev_row
         col_offset = col - self.prev_col
+        # Nearly all newlines are handled by the NL and NEWLINE tokens,
+        # but explicit line continuations are not, so they're handled here.
+        if row > self.prev_row:  
+            row_offset = row - self.prev_row
+            self.tokens.append("\\\n" * row_offset)
+            col_offset = col  # Recalculate the column offset from the start of our new line
         if col_offset:
             self.tokens.append(" " * col_offset)

Two issues remain with this fix, both of which replace the assert with something functional but not exactly what the original text is:
1)  Whitespace leading up to a line continuation is not recreated.  The information required to do this is not present in the tokenized data.
2)  If EOF happens at the end of a line, the untokenized version will have a line continuation on the end, as the ENDMARKER token is represented on a line which does not exist in the original.

I spent some time trying to get a unit test written that demonstrates the original bug, but it would seem that doctest (which test_tokenize uses) cannot represent a '\' character properly.  The existing unit tests involving line continuations pass due to the '\' characters being interpreted as ERRORTOKEN, which is not as they're done when read from file or interactive prompt.

----------

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

From report at bugs.python.org  Fri Oct  1 18:20:58 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Fri, 01 Oct 2010 16:20:58 +0000
Subject: [issue6664] readlines should understand Line Separator and Paragraph
	Separator characters
In-Reply-To: <1249636455.06.0.336549280075.issue6664@psf.upfronthosting.co.za>
Message-ID: <1285950058.75.0.118512183578.issue6664@psf.upfronthosting.co.za>


Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com> added the comment:

This seems to be because codecs.StreamReader.readlines() function does this:

    def readlines(self, sizehint=None, keepends=True):
        data = self.read()
        return data.splitlines(keepends)

But the io readlines() functions make multiple calls to readline() instead.

Here is the test case which passes on the codecs readlines() but fails on the io readlines().

----------
keywords: +patch
nosy: +jfinkels
Added file: http://bugs.python.org/file19086/issue6664.testcase.patch

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

From report at bugs.python.org  Fri Oct  1 18:21:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 16:21:02 +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: <1285950062.54.0.619656019604.issue9286@psf.upfronthosting.co.za>


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

In the first of your examples, parseaddr is correct (a lone token is considered a 'local' address per RFC).

The second one is prossibly wrong, but if so the correct way to interpret it is not clear.  If you read the RFC carefully (http://tools.ietf.org/html/rfc5322#section-4.4), spaces are allowed between the 'local part' and the domain in obsolete syntax (which must be accepted).  However, the space being elided here is between pieces of the local part.  Note that because the address is not in '<>', the whole string is the address, there's no name field.  The "correct" parse could be:

('', '"merwok wok"@rusty')

That is, we apply a 'be generous in what you accept' rule and assume the "s were forgotten.  However, perhaps a more sensible 'generous' rule would be to assume the '<>' were forgotten and return

('merwok', 'wok at rusty')

However, it is quite possible that the reason the space is being elided here has to do with handling the obsolete 'route' syntax.  If that is the case then parseaddr is probably correct.  It may be a while before I get around to understanding that part of the spec well enough to render a judgement, so in the meantime I'll assume parseaddr is correct.  Feel free to read the spec and render your own opinion :)

----------

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

From report at bugs.python.org  Fri Oct  1 18:24:00 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Oct 2010 16:24:00 +0000
Subject: [issue10006] non-Pythonic fate of __abstractmethods__
In-Reply-To: <1285940853.14.0.546762707016.issue10006@psf.upfronthosting.co.za>
Message-ID: <1285950238.79.0.285691120988.issue10006@psf.upfronthosting.co.za>


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

I see the problem; will consider/fix later today hopefully.

----------
assignee:  -> benjamin.peterson

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

From report at bugs.python.org  Fri Oct  1 18:31:18 2010
From: report at bugs.python.org (Amber Jain)
Date: Fri, 01 Oct 2010 16:31:18 +0000
Subject: [issue9986] PDF files of python docs have text missing
In-Reply-To: <1285772054.59.0.857308007062.issue9986@psf.upfronthosting.co.za>
Message-ID: <1285950678.27.0.781339899194.issue9986@psf.upfronthosting.co.za>


Amber Jain <i.amber.jain at gmail.com> added the comment:

Reported to sphinx tracker at bitbucket:
http://bitbucket.org/birkenfeld/sphinx/issue/531/pdf-files-of-python-docs-have-text-missing

----------

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

From report at bugs.python.org  Fri Oct  1 18:45:08 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 01 Oct 2010 16:45:08 +0000
Subject: [issue10003] signal.SIGBREAK regression on windows
In-Reply-To: <1285895278.8.0.672270997961.issue10003@psf.upfronthosting.co.za>
Message-ID: <1285951508.94.0.213764519625.issue10003@psf.upfronthosting.co.za>


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

Fixed in r85140 (py3k), r85141 (release31-maint), and r85145 (release27-maint).

Thanks for the report!

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

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

From report at bugs.python.org  Fri Oct  1 19:00:38 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 01 Oct 2010 17:00:38 +0000
Subject: [issue10006] non-Pythonic fate of __abstractmethods__
In-Reply-To: <1285940853.14.0.546762707016.issue10006@psf.upfronthosting.co.za>
Message-ID: <1285952438.92.0.907054045912.issue10006@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/issue10006>
_______________________________________

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


Martin <gzlist at googlemail.com> added the comment:

Thanks for the quick resolution Brian, head now works as expected.

----------

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

From report at bugs.python.org  Fri Oct  1 19:31:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 17:31:56 +0000
Subject: [issue1050268] rfc822.parseaddr is broken,
	breaks sendmail call in smtplib
Message-ID: <1285954316.74.0.728181005549.issue1050268@psf.upfronthosting.co.za>


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

It does appear as though parseaddr is dropping quoting information from the returned parsed address.  Fixing this is likely to create backward compatibility issues, and I'm very curious to know why parseaddr drops the quoting info.

Note that I do not observe the change from test\com to test.com, so I'm assuming that was a typo and ignoring that part (or it represents a bug that is already fixed).

The "weird" example is actually consistent with the rest of parseaddr's behavior, if you understand that behavior as turning quoted pairs inside quoted strings into their literal value, but leaving the quotes around the quoted string(s) in place.

Consider the example:

  parseaddr('"\\\\"test\\\\" test"@test.com')

If we remove the Python quoting from this input string we have:

  "\\"test\\" test"@test.com

Interpreting this according to RFC rules we have a quoted string "\\" containing a quoted pair (\\).  The quoted pair resolves to a single \.  Then we have the unquoted text
 
   test\\

This parseaddr copies literally (I'm not sure if that is strictly RFC compliant, but given that we are supposed to be liberal in what we except it is as reasonable a thing to do as any.)  Finally we have another quoted string

   " test"

So putting those pieces together according to the rules above, we end up with:

   "\"test\\" test"@test.com

which is the observed output once you remove the Python quoting.  So, parseaddr is working as designed.  The question is, what is the design decision behind resolving the quoted pairs but leaving the quotes?

----------

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

From report at bugs.python.org  Fri Oct  1 19:41:27 2010
From: report at bugs.python.org (Marien Zwart)
Date: Fri, 01 Oct 2010 17:41:27 +0000
Subject: [issue9985] difflib.SequenceMatcher has slightly buggy and
	undocumented caching behavior
In-Reply-To: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za>
Message-ID: <1285954887.97.0.0656059691652.issue9985@psf.upfronthosting.co.za>


Marien Zwart <m_zwart at 123mail.org> added the comment:

That fixes the first problem in python 2. It should do:

self.matching_blocks = [Match._make(t) for t in non_adjacent]

in python 3 though, or it will return an already-exhausted map object if it is called again.

This leaves the problem of other code mutating the cached list (not realizing it is cached). I think it would make sense for these functions to just return a shallow copy of their cached list, but I have not thought that through much.

----------

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

From report at bugs.python.org  Fri Oct  1 20:09:33 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Oct 2010 18:09:33 +0000
Subject: [issue9943] TypeError message became less helpful in Python 2.7
In-Reply-To: <1285357459.53.0.518722150406.issue9943@psf.upfronthosting.co.za>
Message-ID: <1285956573.11.0.786084030874.issue9943@psf.upfronthosting.co.za>


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

FWIW 3.1 gives same message as 2.6. I have not installed 3.2a yet to check that.

Reporting of argument count mismatch has always been problematical, especially for methods. I almost think the message should be simplified to "Arguments passed do not match function signature." Programmers who do not immediately immediately see the problem (because they know the signature but made an inadvertent mistake) will have to check the signature anyway.

The alternative should be a clearer and more complete report than currently, which will take more than one line.

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

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

From report at bugs.python.org  Fri Oct  1 20:18:37 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 01 Oct 2010 18:18:37 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1285957117.68.0.174473368599.issue5088@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
attached a patch to add documentation about action=append and a default value.

Regards,
Sandro

----------
keywords: +patch
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19087/issue5088-py3k.patch

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

From report at bugs.python.org  Fri Oct  1 20:24:06 2010
From: report at bugs.python.org (Jeremy Thurgood)
Date: Fri, 01 Oct 2010 18:24:06 +0000
Subject: [issue9997] function named 'top' gets unexpected namespace/scope
	behaviour
In-Reply-To: <1285849061.79.0.383989167237.issue9997@psf.upfronthosting.co.za>
Message-ID: <1285957446.47.0.133064463473.issue9997@psf.upfronthosting.co.za>


Changes by Jeremy Thurgood <firxen at gmail.com>:


----------
nosy: +jerith

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

From report at bugs.python.org  Fri Oct  1 20:39:29 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 01 Oct 2010 18:39:29 +0000
Subject: [issue9977] TestCase.assertItemsEqual's description of differences
In-Reply-To: <1285704922.32.0.659854668668.issue9977@psf.upfronthosting.co.za>
Message-ID: <1285958369.6.0.776611869699.issue9977@psf.upfronthosting.co.za>


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

If I understand correctly, you are requesting that .assertItemsEqual only use the 2nd (multiset comparison) method, so that if one want the first method, one should directly call .assertSequenceEqual(sorted(a), sorted(b)).

This seems reasonable to me, but I do not use the unittest module, and I suspect others want the implicit call.

----------
nosy: +terry.reedy
stage:  -> unit test needed

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

From report at bugs.python.org  Fri Oct  1 20:44:34 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 01 Oct 2010 18:44:34 +0000
Subject: [issue5501] Update multiprocessing docs re: freeze_support
In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>
Message-ID: <1285958674.81.0.989959778375.issue5501@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
well it's just 3 words that can clarify the situation, so maybe just add them would be nice

Regards,
Sandro

----------
nosy: +sandro.tosi

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

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


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

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

  Thread (class in threading), [1]

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

# Latter doesn't have perma link.

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

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

From report at bugs.python.org  Fri Oct  1 20:46:50 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Fri, 01 Oct 2010 18:46:50 +0000
Subject: [issue9977] TestCase.assertItemsEqual's description of differences
In-Reply-To: <1285958369.6.0.776611869699.issue9977@psf.upfronthosting.co.za>
Message-ID: <20101001184645.GA10972@golux.woodcraft.me.uk>


Matthew Woodcraft <matthew at woodcraft.me.uk> added the comment:

Terry J. Reedy wrote:
> If I understand correctly, you are requesting that .assertItemsEqual
> only use the 2nd (multiset comparison) method, so that if one want the
> first method, one should directly call .assertSequenceEqual(sorted(a),
> sorted(b)).

Yes, that would make me happy. So would a new assertXXXEqual method that
always did the multiset comparison.

----------

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

From report at bugs.python.org  Fri Oct  1 20:53:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Oct 2010 18:53:43 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1285959223.2.0.126242848304.issue9990@psf.upfronthosting.co.za>


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

Here is a patch that fixes the issue. Can you try it?

Unfortunately, more advanced uses such a slicing the memoryview are still crashing. That's because the new buffer protocol doesn't define ownership of Py_buffer structs. As a result, nothing can be assumed at to which piece of code is responsible for allocation and deallocation of related memory areas (such as shapes and strides arrays).

----------
keywords: +patch
nosy: +ncoghlan, teoliphant
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19088/memview.patch

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

From report at bugs.python.org  Fri Oct  1 20:57:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Oct 2010 18:57:21 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1285959441.24.0.913012087855.issue9990@psf.upfronthosting.co.za>


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

Of course, a patch is always better without the debugging prints :)

----------
Added file: http://bugs.python.org/file19089/memview.patch

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

From report at bugs.python.org  Fri Oct  1 20:57:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Oct 2010 18:57:26 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1285959446.23.0.773987151711.issue9990@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file19088/memview.patch

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

From report at bugs.python.org  Fri Oct  1 20:58:40 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 01 Oct 2010 18:58:40 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1285959520.77.0.210631483216.issue8879@psf.upfronthosting.co.za>


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

test_tarfile fails with this patch.

----------

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

From report at bugs.python.org  Fri Oct  1 21:02:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 01 Oct 2010 19:02:35 +0000
Subject: [issue9996] binascii should convert unicode strings
In-Reply-To: <1285848203.41.0.985893389249.issue9996@psf.upfronthosting.co.za>
Message-ID: <1285959755.69.0.0879146362655.issue9996@psf.upfronthosting.co.za>


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

Since the issue/patch is about binascii, and I agree with Martin that binascii should continue to do bytes-to-bytes transforms (especially since that is its most common use case, IMO), I'm going to close this issue.  Please open the discussion on python-dev or python-ideas if you wish to proceed with some sort of feature request.

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

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

From report at bugs.python.org  Fri Oct  1 22:09:31 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 01 Oct 2010 20:09:31 +0000
Subject: [issue9985] difflib.SequenceMatcher has slightly buggy and
	undocumented caching behavior
In-Reply-To: <1285770739.15.0.805040100323.issue9985@psf.upfronthosting.co.za>
Message-ID: <1285963771.44.0.523784595081.issue9985@psf.upfronthosting.co.za>


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

(+nosy Raymond as committer of r59907 and removing python2.6 since this is not a security issue)

----------
nosy: +ned.deily, rhettinger
stage:  -> needs patch
versions:  -Python 2.6

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

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


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

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

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

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

From report at bugs.python.org  Fri Oct  1 22:26:11 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Oct 2010 20:26:11 +0000
Subject: [issue9974] tokenizer.untokenize not invariant with line continuations
In-Reply-To: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>
Message-ID: <1285964771.15.0.759616350909.issue9974@psf.upfronthosting.co.za>


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


----------
assignee:  -> rhettinger
nosy: +rhettinger

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

From report at bugs.python.org  Fri Oct  1 22:48:56 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Oct 2010 20:48:56 +0000
Subject: [issue8190] Add a PyPI XML-RPC client module
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1285966136.03.0.834958716344.issue8190@psf.upfronthosting.co.za>


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

My bad, I took Tarek?s line about ?implementing all functions? literally.  Your client classes don?t have methods with the same exact names and signatures, but what matters is that they provide the functionality.  If you can review the functions listed on the XML-RPC wiki page and confirm they have an equivalent in d2.index, this bug will be closed :)  Bonus points if you create a wiki page explaining how to do operations listed on the XML-RPC page in distutils2.

----------

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

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


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

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

With attached patch, I am happy.

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

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

From report at bugs.python.org  Fri Oct  1 23:00:38 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 01 Oct 2010 21:00:38 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1285966838.04.0.332618700017.issue8879@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I think this is because os.stat and os.lstat doesn't set st_nlink.
It is only set via os.fstat. I'll attach quick hack patch. (Again,
this is just quick hack patch)

I confirmed this passes test_os and test_tarfile.

----------
Added file: http://bugs.python.org/file19091/py3k_quick_hack_for_issue8879.patch

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

From report at bugs.python.org  Fri Oct  1 23:04:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Oct 2010 21:04:36 +0000
Subject: [issue10010] ".. index::" position
In-Reply-To: <1285966504.08.0.573086754525.issue10010@psf.upfronthosting.co.za>
Message-ID: <1285967076.25.0.302901639904.issue10010@psf.upfronthosting.co.za>


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

+1 on the patch.  I suspect there is the same problem for other links.

----------
nosy: +eric.araujo
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Fri Oct  1 23:14:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Oct 2010 21:14:37 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1285967677.34.0.756996376336.issue5088@psf.upfronthosting.co.za>


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

Thanks for the patch.  Some remarks:

>  :attr:`~Option.dest` variable, that already contains the default value
I would have used ?which? here, but I?m not a native speaker.

> not replaced (contrary to what one can think)
I?d have used a comma, not parens.

> This behaviour is clear
?makes sense? sounds better to me.

> think that with a default value :attr:`~Option.dest` is a list
I suggest a comma after ?value?.

> any additional option is appended to that list
s/option/value/

Let me use this reply to welcome you in the bug tracker.  I hope you get warn fuzzy feelings when your patches are accepted or your comments acted upon.  I?m also looking forward for a better Python-Debian relationship.  (Cultural note: It?s not usual to say hello and regards in messages on this tracker.  I did it too at first but was told it was unnecessary.)  :)

----------
assignee: georg.brandl -> docs at python
nosy: +docs at python, eric.araujo
stage:  -> patch review
versions:  -Python 2.6

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

From report at bugs.python.org  Fri Oct  1 23:16:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Oct 2010 21:16:26 +0000
Subject: [issue5501] Update multiprocessing docs re: freeze_support
In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>
Message-ID: <1285967786.56.0.637346055162.issue5501@psf.upfronthosting.co.za>


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

I?m assuming this is a feature new in 2.7 and 3.2, please add 3.1 if this is wrong.

----------
nosy: +docs at python, eric.araujo

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

From report at bugs.python.org  Fri Oct  1 23:37:16 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 01 Oct 2010 21:37:16 +0000
Subject: [issue9841] sysconfig and distutils.sysconfig differ in subtle ways
In-Reply-To: <1284333988.17.0.109581594915.issue9841@psf.upfronthosting.co.za>
Message-ID: <1285969036.78.0.190779482469.issue9841@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
nosy: +barry

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

From report at bugs.python.org  Fri Oct  1 23:42:21 2010
From: report at bugs.python.org (Alexis Metaireau)
Date: Fri, 01 Oct 2010 21:42:21 +0000
Subject: [issue8190] Add a PyPI XML-RPC client module
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1285969341.22.0.6490560196.issue8190@psf.upfronthosting.co.za>


Alexis Metaireau <ametaireau at gmail.com> added the comment:

Yes, all the functions are covered. By the way, I've covered all the functions based on the pypi source code, not on the wiki.

I'll update the wiki page with some examples soon :)

----------

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

From report at bugs.python.org  Fri Oct  1 23:44:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Oct 2010 21:44:35 +0000
Subject: [issue8190] Add a PyPI XML-RPC client module
In-Reply-To: <1269141957.53.0.288648605609.issue8190@psf.upfronthosting.co.za>
Message-ID: <1285969475.27.0.0883828851537.issue8190@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sat Oct  2 00:00:41 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Oct 2010 22:00:41 +0000
Subject: [issue1195571] simple callback system for Py_FatalError
Message-ID: <1285970441.7.0.0556028511011.issue1195571@psf.upfronthosting.co.za>


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

Here is a new patch; I lifted the pre-Py_Initialize() restriction, because it seems to me that a wxPython application, for example, could use it.
A wxPython application is not embedded, but it already often redirects stdout and even installs a segfault handler.

I also made Py_SetFatalHook() return the previous hook; it could be useful to set a function temporarily, even if this is not thread safe.

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

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

From report at bugs.python.org  Sat Oct  2 00:08:13 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Oct 2010 22:08:13 +0000
Subject: [issue1195571] simple callback system for Py_FatalError
Message-ID: <1285970893.45.0.361227483496.issue1195571@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Added file: http://bugs.python.org/file19096/fatalhook-2.patch

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

From report at bugs.python.org  Sat Oct  2 00:09:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 01 Oct 2010 22:09:33 +0000
Subject: [issue2771] test issue
In-Reply-To: <1210005645.74.0.283923986194.issue2771@psf.upfronthosting.co.za>
Message-ID: <1285970973.27.0.755188398621.issue2771@psf.upfronthosting.co.za>


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

Attach some file

----------
keywords: +patch
Added file: http://bugs.python.org/file19097/README.diff

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

From report at bugs.python.org  Sat Oct  2 00:16:35 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Oct 2010 22:16:35 +0000
Subject: [issue1195571] simple callback system for Py_FatalError
Message-ID: <1285971395.09.0.988189825769.issue1195571@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Removed file: http://bugs.python.org/file19096/fatalhook-2.patch

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

From report at bugs.python.org  Sat Oct  2 00:17:12 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Oct 2010 22:17:12 +0000
Subject: [issue1195571] simple callback system for Py_FatalError
Message-ID: <1285971432.57.0.758163923768.issue1195571@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


Added file: http://bugs.python.org/file19098/fatalhook-2.patch

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

From report at bugs.python.org  Sat Oct  2 00:33:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Oct 2010 22:33:36 +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: <1285972416.06.0.120640826037.issue9807@psf.upfronthosting.co.za>


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

I see nothing obviously wrong in the patch.

----------

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

From report at bugs.python.org  Sat Oct  2 00:41:35 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 01 Oct 2010 22:41: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: <1285972895.43.0.398951713898.issue9807@psf.upfronthosting.co.za>


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

?ric: which patch: file18807, or http://codereview.appspot.com/2340041/?

----------

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

From report at bugs.python.org  Sat Oct  2 00:45:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Oct 2010 22:45:33 +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: <1285973133.85.0.22416886068.issue9807@psf.upfronthosting.co.za>


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

Sorry, I was replying to this:
?I'm still investigating that, but in the meantime, please go to codereview and let me know what you think so far.?

I meant that for the distutils part, I?ve seen nothing bad.  I have no idea about the import bug.

----------

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

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


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

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

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

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

From report at bugs.python.org  Sat Oct  2 00:56:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Oct 2010 22:56:18 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285973778.51.0.298783207562.issue8670@psf.upfronthosting.co.za>


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

Patch version 4:
 - implement unicode_aswidechar() for 16 bits wchar_t and 32 bits Py_UNICODE
 - PyUnicode_AsWideWcharString() returns the number of wide characters excluding the nul character as does PyUnicode_AsWideChar()

For 16 bits wchar_t and 32 bits Py_UNICODE, I extracted the "as wide char" unicode functions into a small C file and compiled it with -fshort-wchar on Linux.

----------
Added file: http://bugs.python.org/file19099/aswidechar_nonbmp-4.patch

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

From report at bugs.python.org  Sat Oct  2 00:56:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Oct 2010 22:56:25 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285973785.37.0.905529942087.issue8670@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file19082/aswidechar_nonbmp-2.patch

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

From report at bugs.python.org  Sat Oct  2 00:56:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Oct 2010 22:56:28 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285973788.01.0.591141852366.issue8670@psf.upfronthosting.co.za>


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


Removed file: http://bugs.python.org/file19083/aswidechar_nonbmp-3.patch

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

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


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

Mainly to protect against potential infinite recursion with isinstance checks. Also, performance is probably better.

Here are the relevant code and comments in PyErr_GivenExceptionMatches() (in Python/errors.c):

        /* PyObject_IsSubclass() can recurse and therefore is
           not safe (see test_bad_getattr in test.pickletester). */
        res = PyType_IsSubtype((PyTypeObject *)err, (PyTypeObject *)exc);

----------
nosy: +pitrou
versions:  -Python 2.5, Python 2.6, Python 2.7, Python 3.3

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

From report at bugs.python.org  Sat Oct  2 01:02:02 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Oct 2010 23:02:02 +0000
Subject: [issue6691] Support for nested classes and function for pyclbr
In-Reply-To: <1250117262.14.0.353515413158.issue6691@psf.upfronthosting.co.za>
Message-ID: <1285974122.61.0.800565543364.issue6691@psf.upfronthosting.co.za>


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

Too late for version 2. I updated patch for 3.2, and tried to improve the documentation a little bit.

----------
nosy: +amaury.forgeotdarc
versions:  -Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19100/pyclbr_nested_objects-py3k.patch

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

From report at bugs.python.org  Sat Oct  2 01:02:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Oct 2010 23:02:43 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1285974161.44.0.76876041716.issue8670@psf.upfronthosting.co.za>


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

Ooops, I lost my patch to fix the initial (ctypes) issue. Here is an updated patch: ctypes_nonbmp.patch (which needs aswidechar_nonbmp-4.patch).

----------
Added file: http://bugs.python.org/file19101/ctypes_nonbmp.patch

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

From report at bugs.python.org  Sat Oct  2 01:04:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 01 Oct 2010 23:04:26 +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: <1285974266.59.0.987489631735.issue9873@psf.upfronthosting.co.za>


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


----------
title: Allow bytes in some APIs that use string literals internally -> urllib.parse: Allow bytes in some APIs that use string literals internally

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

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


Ram Rachum <cool-rr at cool-rr.com> added the comment:

I don't understand the infinite recursion argument. If there's such an infinite recursion, wouldn't it be due to a bug in the user's implementation of __instancecheck__?

----------

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

From report at bugs.python.org  Sat Oct  2 01:28:07 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 01 Oct 2010 23:28:07 +0000
Subject: [issue9841] sysconfig and distutils.sysconfig differ in subtle ways
In-Reply-To: <1284333988.17.0.109581594915.issue9841@psf.upfronthosting.co.za>
Message-ID: <1285975687.49.0.665497072651.issue9841@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Not in distutils2 because we want to get rid of it, thats the whole point.
distutils2 will use the sysconfig module I've extracted from distutils.

----------

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

From report at bugs.python.org  Sat Oct  2 01:33:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 01 Oct 2010 23:33:52 +0000
Subject: [issue9841] sysconfig and distutils.sysconfig differ in subtle ways
In-Reply-To: <1284333988.17.0.109581594915.issue9841@psf.upfronthosting.co.za>
Message-ID: <1285976032.35.0.0861468617388.issue9841@psf.upfronthosting.co.za>


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

By ?d2/sysconfig? I meant d2._backport.sysconfig.

----------

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

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


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

httplib.py ~Line 924

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


should be changed to something like:


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

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

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

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

From report at bugs.python.org  Sat Oct  2 02:05:25 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Oct 2010 00:05:25 +0000
Subject: [issue10006] non-Pythonic fate of __abstractmethods__
In-Reply-To: <1285940853.14.0.546762707016.issue10006@psf.upfronthosting.co.za>
Message-ID: <1285977925.1.0.530829516046.issue10006@psf.upfronthosting.co.za>


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

As of r85154, type.__abstractmethods__ now raises an AttributeError, too.

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

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

From report at bugs.python.org  Sat Oct  2 02:06:40 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 02 Oct 2010 00:06: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: <1285978000.28.0.977442332105.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

bzr branch lp:~barry/python/issue9807

https://code.edge.launchpad.net/~barry/python/issue9807

----------

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

From report at bugs.python.org  Sat Oct  2 02:12:21 2010
From: report at bugs.python.org (Lenard Lindstrom)
Date: Sat, 02 Oct 2010 00:12:21 +0000
Subject: [issue9990] PyMemoryView_FromObject alters the Py_buffer after
	calling PyObject_GetBuffer when ndim 1
In-Reply-To: <1285787018.03.0.476755592717.issue9990@psf.upfronthosting.co.za>
Message-ID: <1285978341.11.0.379332534222.issue9990@psf.upfronthosting.co.za>


Lenard Lindstrom <len-l at telus.net> added the comment:

Applied patch to:
Python 3.2a2+ (py3k:85150M, Oct  1 2010, 14:40:33) 
[GCC 4.4.5 20100728 (prerelease)] on linux2

Python unit test test_capi.py crashes:

internal test_broken_memoryview
* ob
object  : <refcnt 0 at 0xb7171178>
type    : str
refcount: 0
address : 0xb7171178
* op->_ob_prev->_ob_next
object  : <refcnt 0 at 0xb7171178>
type    : str
refcount: 0
address : 0xb7171178
* op->_ob_next->_ob_prev
object  : Segmentation fault

Pygame unit tests pass (segfaults without the patch).

bufrel.c test passes.

numpy 1.5.0 unit tests not run since they rely on a package that needs porting to Python 3.x. A memory view is used to manage an object whose buffer a numpy array exposes. This was where the Pygame unit test seqfault occurred.

The patch fixes the problem with Pygame.

Thanks.

----------

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

From report at bugs.python.org  Sat Oct  2 04:25:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 02:25:05 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1285986305.27.0.967456934773.issue4661@psf.upfronthosting.co.za>


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

New version of patch including a BytesGenerator.

----------
Added file: http://bugs.python.org/file19102/email_parse_bytes3.diff

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

From report at bugs.python.org  Sat Oct  2 04:37:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 02:37:31 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1285987051.38.0.71481025789.issue4661@psf.upfronthosting.co.za>


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

In case it isn't clear, the code patch is now complete, so anyone who wants to give it a review, please do.  I'll add the docs soon, but the basic idea is you can put bytes in by either using message_from_bytes or by using the 'ascii' codec and the 'surrogateescape' error handler on a file passed to msg_from_file, and you can get bytes out by using BytesGenerator and passing it a file-like object that accepts bytes.  As a side benefit, Generator will correctly render (as unicode) the content of a section with a ContentTransferEncoding of '8bit'.

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

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

From report at bugs.python.org  Sat Oct  2 04:57:47 2010
From: report at bugs.python.org (Alex Quinn)
Date: Sat, 02 Oct 2010 02:57:47 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1285988267.97.0.794030683487.issue4661@psf.upfronthosting.co.za>


Changes by Alex Quinn <aq2009 at alexquinn.org>:


----------
nosy:  -Alex Quinn

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

From report at bugs.python.org  Sat Oct  2 04:59:40 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 02 Oct 2010 02:59:40 +0000
Subject: [issue10012] httplib shadows builtin, assumes strings
In-Reply-To: <1285976648.58.0.0752019030242.issue10012@psf.upfronthosting.co.za>
Message-ID: <1285988380.25.0.428596191905.issue10012@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/issue10012>
_______________________________________

From report at bugs.python.org  Sat Oct  2 05:31:02 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 02 Oct 2010 03:31:02 +0000
Subject: [issue10010] ".. index::" position
In-Reply-To: <1285966504.08.0.573086754525.issue10010@psf.upfronthosting.co.za>
Message-ID: <1285990262.73.0.63696127669.issue10010@psf.upfronthosting.co.za>


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

Fixed in py3k(r85156), release31-maint(r85157) and release27-maint(r85158).

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

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

From report at bugs.python.org  Sat Oct  2 06:00:10 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 02 Oct 2010 04:00:10 +0000
Subject: [issue9974] tokenizer.untokenize not invariant with line continuations
In-Reply-To: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>
Message-ID: <1285992010.13.0.199731769347.issue9974@psf.upfronthosting.co.za>


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

Interesting, is that a separate defect of doctest?

----------

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

From report at bugs.python.org  Sat Oct  2 06:06:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 04:06:35 +0000
Subject: [issue1050268] rfc822.parseaddr is broken,
	breaks sendmail call in smtplib
Message-ID: <1285992395.58.0.607747098769.issue1050268@psf.upfronthosting.co.za>


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

After working my way through the code I no longer think that parseaddr is working as designed.  I think that this is a bug, and that there is a missing call to quote in getaddrspec.  Attached is a revised set of unit tests and a fix.  The full python test suite passes with this fix in place, but note that initially I made a mistake in the patch and running test_email passed...that is, before the attached tests there were no tests of parseaddr in the email test suite.

I don't know if this patch is safe for backport, but I'm inclined that way.  It is hard to see how 3rd party code could be compensating for this bug, since it looses quoting information that doesn't appear to be algorithmically recoverable.

----------
Added file: http://bugs.python.org/file19103/parseaddr_quote.diff

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

From report at bugs.python.org  Sat Oct  2 06:45:24 2010
From: report at bugs.python.org (Yaroslav Halchenko)
Date: Sat, 02 Oct 2010 04:45:24 +0000
Subject: [issue10006] non-Pythonic fate of __abstractmethods__
In-Reply-To: <1285940853.14.0.546762707016.issue10006@psf.upfronthosting.co.za>
Message-ID: <1285994724.21.0.1084942895.issue10006@psf.upfronthosting.co.za>


Yaroslav Halchenko <yarikoptic at gmail.com> added the comment:

yikes... surprising resolution -- I expected that fix would either makes __abstractmethods__ accessible in derived "type"s or becomes absent from output of dir() -- but none of those has happened.  Now we ended up with a consistent non-Pythonic fate of __abstractmethods__ listed in output of dir() but not accessible.  is that a feature?

----------

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

From report at bugs.python.org  Sat Oct  2 08:14:53 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 02 Oct 2010 06:14:53 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1286000093.8.0.744666343391.issue9951@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/issue9951>
_______________________________________

From report at bugs.python.org  Sat Oct  2 08:35:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 02 Oct 2010 06:35:10 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1286001310.29.0.589967761158.issue9951@psf.upfronthosting.co.za>


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

Patch generally looks good, but the type of retbuf is incorrect (should be Py_UNICODE* rather than wchar_t*).

----------

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

From report at bugs.python.org  Sat Oct  2 10:36:20 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 02 Oct 2010 08:36:20 +0000
Subject: [issue6612] 'import site' fails when called from an unlinked directory
In-Reply-To: <1249034007.06.0.695800326888.issue6612@psf.upfronthosting.co.za>
Message-ID: <1286008580.39.0.936097964442.issue6612@psf.upfronthosting.co.za>


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

A unit test is needed. Not to check the code, but to ensure that we don't break it in the future.

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

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

From report at bugs.python.org  Sat Oct  2 11:56:31 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 02 Oct 2010 09:56:31 +0000
Subject: [issue1767933] Badly formed XML using etree and utf-16
Message-ID: <1286013391.41.0.658493601343.issue1767933@psf.upfronthosting.co.za>


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

Python 3.1 improves the situation, the file looks more like utf-16, except that the BOM ("\xff\xfe") is repeated all the time, probably on every internal call to file.write().

Here is a test script that should work on both 2.7 and 3.1.

from io import BytesIO
from xml.etree.ElementTree import ElementTree
content = "<?xml version='1.0' encoding='UTF-16'?><html></html>"
input = BytesIO(content.encode('utf-16'))
tree = ElementTree()
tree.parse(input)
# Write content
output = BytesIO()
tree.write(output, encoding="utf-16")
assert output.getvalue().decode('utf-16') == content

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

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

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


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

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

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

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

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

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


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

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

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

From report at bugs.python.org  Sat Oct  2 13:17:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Oct 2010 11:17:34 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1286018254.24.0.588979019791.issue8670@psf.upfronthosting.co.za>


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

r85172 changes PyUnicode_AsWideCharString() (don't count the trailing nul character in the output size) and add unit tests.

r85173 patches unicode_aswidechar() to supports non-BMP characters for all known wchar_t/Py_UNICODE size combinaisons (2/2, 2/4 and 4/2).

I noticed that PyUnicode_AsWideChar() and PyUnicode_AsWideCharString() accept embeded nul characters. I don't know if it is a bug or an expected behaviour. Anyway, there is now a test for this case.

----------

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

From report at bugs.python.org  Sat Oct  2 13:54:31 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 02 Oct 2010 11:54:31 +0000
Subject: =?utf-8?q?=5Bissue10013=5D_fix_=60=2E/libpython2=2E6=2Eso=3A_undefined_re?=
	=?utf-8?q?ference_to_=60=5FPyParser=5FGrammar=C2=B4=60_in_parallel_builds?=
In-Reply-To: <1286018023.44.0.511102577172.issue10013@psf.upfronthosting.co.za>
Message-ID: <1286020471.57.0.81705362047.issue10013@psf.upfronthosting.co.za>


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

2.6 is closed for bug fixes, so this cannot be applied anymore.

Notice that py3k has this fixed in r84068; I'll backport the fix to 2.7.

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

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

From report at bugs.python.org  Sat Oct  2 13:55:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Oct 2010 11:55:59 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1286020559.37.0.182942023015.issue8670@psf.upfronthosting.co.za>


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

r85174+r85177: ctypes.c_wchar supports non-BMP characters with 32 bits wchar_t => fix this issue

(I commited also an unwanted change on _testcapi to fix r85172 in r85174: r85175 reverts this change, and r85176 fixes the _testcapi bug again)

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

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

From report at bugs.python.org  Sat Oct  2 13:59:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Oct 2010 11:59:29 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1286020769.59.0.232464689034.issue8670@psf.upfronthosting.co.za>


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

> r85173 patches unicode_aswidechar() to supports non-BMP characters 
> for all known wchar_t/Py_UNICODE size combinaisons (2/2, 2/4 and 4/2).

Oh, and 4/4 ;-)

----------

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

From report at bugs.python.org  Sat Oct  2 14:11:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 12:11:07 +0000
Subject: =?utf-8?q?=5Bissue10013=5D_fix_=60=2E/libpython2=2E6=2Eso=3A_undefined_re?=
	=?utf-8?q?ference_to_=60=5FPyParser=5FGrammar=C2=B4=60_in_parallel_builds?=
In-Reply-To: <1286018023.44.0.511102577172.issue10013@psf.upfronthosting.co.za>
Message-ID: <1286021467.7.0.486018927147.issue10013@psf.upfronthosting.co.za>


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


----------
nosy: +dmalcolm

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

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


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

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

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

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

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

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

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

From report at bugs.python.org  Sat Oct  2 14:14:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Oct 2010 12:14:57 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif
	locale	and fileystem encodings aredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286021697.75.0.37449699574.issue9992@psf.upfronthosting.co.za>


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

See also #10014: sys.path[0] is decoded from the locale encoding instead of the fileystem encoding.

----------

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

From report at bugs.python.org  Sat Oct  2 14:23:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 02 Oct 2010 12:23:01 +0000
Subject: [issue9533] metaclass can't derive from ABC
In-Reply-To: <1281090819.15.0.255356922996.issue9533@psf.upfronthosting.co.za>
Message-ID: <1286022181.62.0.49181962777.issue9533@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/issue9533>
_______________________________________

From report at bugs.python.org  Sat Oct  2 15:15:33 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 02 Oct 2010 13:15:33 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1286025333.32.0.61029729696.issue8670@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Thanks for working on this!

Since this was a bugfix, it should be merged back into 2.7, yes?

----------
stage: unit test needed -> committed/rejected

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

From report at bugs.python.org  Sat Oct  2 15:18:24 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 02 Oct 2010 13:18:24 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1286025504.86.0.346197238478.issue6706@psf.upfronthosting.co.za>


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

Patch in attachment adds a handled_accepted() method to dispatcher class as recommended by Antoine.

----------
Added file: http://bugs.python.org/file19104/accept.patch

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

From report at bugs.python.org  Sat Oct  2 15:53:01 2010
From: report at bugs.python.org (Ram Rachum)
Date: Sat, 02 Oct 2010 13:53:01 +0000
Subject: [issue10011] `except` doesn't use `isinstance`
In-Reply-To: <1285973470.62.0.723186105709.issue10011@psf.upfronthosting.co.za>
Message-ID: <1286027581.48.0.113677211125.issue10011@psf.upfronthosting.co.za>


Ram Rachum <cool-rr at cool-rr.com> added the comment:

Also, how important is the performance of exception checking *after* an exception was raised? I mean, wouldn't it matter only for programs that raise and catch hundreds of exceptions a second?

----------

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

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


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

Using Python 2.7 x32 on Windows XP

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


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


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


def f(x):
    return x*x


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


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

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

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

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

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


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

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

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

From report at bugs.python.org  Sat Oct  2 16:10:28 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 02 Oct 2010 14:10:28 +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: <1286028628.59.0.590256067864.issue9807@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

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

From report at bugs.python.org  Sat Oct  2 16:10:42 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 02 Oct 2010 14:10:42 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1286028642.63.0.203388944291.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

In py3k, ntpath is almost fixed. but posixpath is not fixed yet.
ntpath has another problem about case sensitivity. I'll attach
the patch to fix ntpath's case issue and posixpath.

In Py27, ntpath has whole issue still there.

----------
Added file: http://bugs.python.org/file19106/py3k_fix_relpath.patch

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

From report at bugs.python.org  Sat Oct  2 16:11:51 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 02 Oct 2010 14:11:51 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1286028711.68.0.00960583969389.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I'll create the patch for it.

----------
versions:  -Python 2.6

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

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


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

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

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

Tom

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

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

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

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


Tom Potts <karaken12 at gmail.com> added the comment:

(see opening message)

----------
Added file: http://bugs.python.org/file19108/shutil-2.7.patch

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

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


Changes by Tom Potts <karaken12 at gmail.com>:


Added file: http://bugs.python.org/file19109/shutil-3.2.1.patch

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

From report at bugs.python.org  Sat Oct  2 16:18:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 14:18:11 +0000
Subject: [issue9533] metaclass can't derive from ABC
In-Reply-To: <1281090819.15.0.255356922996.issue9533@psf.upfronthosting.co.za>
Message-ID: <1286029091.01.0.252796374677.issue9533@psf.upfronthosting.co.za>


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

Does the "fix" for issue 10006 affect this?  (I imagine that question is why Antoine made Benjamin nosy on this issue).

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

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

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


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


----------
nosy: +asksol, jnoller
type: crash -> behavior

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

From report at bugs.python.org  Sat Oct  2 17:21:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 15:21:10 +0000
Subject: [issue10016] shutil.copyfile -- allow sparse copying
In-Reply-To: <1286029015.57.0.815158740908.issue10016@psf.upfronthosting.co.za>
Message-ID: <1286032870.35.0.83985001568.issue10016@psf.upfronthosting.co.za>


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

You are right that this needs to be tested on other platforms.  In order to so test it (and in any case!), the patch will need unit tests.  It also needs doc updates.

In general patch itself looks good to me, modulo the concern you raise about truncate.  You could move the '\0'*buflen constant outside the loop.  Also, the py3k IO module doesn't define constants for 'seek', the docs just refer to the integers, so it might be best not to use the os constants even though they are equivalent (the new io module is not a wrapper around os functions the way the old file implementation was).

FYI, patches should (currently, pending the hg migration) be against the py3k trunk, and whoever commits it would backport it if appropriate.  In this case, however, it is a new feature and so can only go into py3k trunk.

----------
nosy: +r.david.murray, tarek
versions:  -Python 2.6, Python 2.7

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

From report at bugs.python.org  Sat Oct  2 17:29:11 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 02 Oct 2010 15:29:11 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1286033351.28.0.899090291534.issue8670@psf.upfronthosting.co.za>


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

> Since this was a bugfix, it should be merged back into 2.7, yes?

Mmmh, the fix requires to change PyUnicode_AsWideChar() function (support non-BMP characters and surrogate pairs) (and maybe also to create PyUnicode_AsWideCharString()). I don't really want to change such important function in a stable branch (Python2).

Is it really important to support non-BMP characters for ctypes.c_wchar in Python2? I would like to say: if you want better unicode support, use Python 3. And Python 3.2 if it's possible :-)

----------

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

From report at bugs.python.org  Sat Oct  2 17:33:49 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sat, 02 Oct 2010 15:33:49 +0000
Subject: [issue8670] c_types.c_wchar should not assume that sizeof(wchar_t)
	==	sizeof(Py_UNICODE)
In-Reply-To: <1273387114.89.0.416578803449.issue8670@psf.upfronthosting.co.za>
Message-ID: <1286033629.77.0.455753941594.issue8670@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Since I noticed the bug through source code inspection and no one has reported it occurring in practice, that sounds reasonable to me.

----------
versions:  -Python 2.7

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

From report at bugs.python.org  Sat Oct  2 18:28:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 16:28:28 +0000
Subject: [issue1050268] rfc822.parseaddr is broken,
	breaks sendmail call in smtplib
Message-ID: <1286036908.14.0.883479624532.issue1050268@psf.upfronthosting.co.za>


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

Fix committed to py3k in r85179, 3.1 in r85170, and 2.7 in r85181.  I modified the unit tests, deleting the ones that were redundant because they were just two different python spellings of the same input string, and adding a comment about the third test case's quoting pattern.

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

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

From report at bugs.python.org  Sat Oct  2 18:53:42 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 02 Oct 2010 16:53:42 +0000
Subject: [issue7511] msvc9compiler.py: ValueError: [u'path']
In-Reply-To: <1260858478.84.0.495655867168.issue7511@psf.upfronthosting.co.za>
Message-ID: <1286038422.56.0.0999029136119.issue7511@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/issue7511>
_______________________________________

From report at bugs.python.org  Sat Oct  2 18:56:25 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Oct 2010 16:56:25 +0000
Subject: [issue10006] non-Pythonic fate of __abstractmethods__
In-Reply-To: <1285994724.21.0.1084942895.issue10006@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=EbkDEE6gDk7MK1L6v3YW74Jcj4zOQk0KMm_4P@mail.gmail.com>


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

2010/10/1 Yaroslav Halchenko <report at bugs.python.org>:
>
> Yaroslav Halchenko <yarikoptic at gmail.com> added the comment:
>
> yikes... surprising resolution -- I expected that fix would either makes __abstractmethods__ accessible in derived "type"s or becomes absent from output of dir() -- but none of those has happened. ?Now we ended up with a consistent non-Pythonic fate of __abstractmethods__ listed in output of dir() but not accessible. ?is that a feature?

type has no __abstractmethods__, so it should raise an AttributeError.
Note descriptors are allowed to raise AttributeError even if they're
in dir().

----------

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

From report at bugs.python.org  Sat Oct  2 18:58:16 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 02 Oct 2010 16:58:16 +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: <1286038696.96.0.282287891723.issue8792@psf.upfronthosting.co.za>


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

It's easy enough to subclass the Transport type and add custom types to the dispatcher object, see the script below.
Attila, Bhargav, is this solution acceptable to you?


from xmlrpclib import Transport, ServerProxy

class MyTransport(Transport):
    def getparser(self):
        parser, unmarshaller = Transport.getparser(self)

        # Get the class attribute, clone it
        dispatch = unmarshaller.dispatch.copy()
        # and store it on the instance
        unmarshaller.dispatch = dispatch

        # Now we can add custom types
        dispatch["ex:i8"] = dispatch["int"]

        return parser, unmarshaller

uri = "http://time.xmlrpc.com/RPC2"
server = ServerProxy(uri, transport=MyTransport(use_datetime=True))
print server.currentTime.getCurrentTime()

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

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

From report at bugs.python.org  Sat Oct  2 19:05:08 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 02 Oct 2010 17:05:08 +0000
Subject: [issue9369] const char* for PyObject_CallMethod and
	PyObject_CallFunction
In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za>
Message-ID: <1286039108.44.0.688003845615.issue9369@psf.upfronthosting.co.za>


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

Martin, what do you think about this kind of changes? Are there possible regressions or incompatibilities?

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

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

From report at bugs.python.org  Sat Oct  2 19:09:36 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 02 Oct 2010 17:09:36 +0000
Subject: [issue9369] const char* for PyObject_CallMethod and
	PyObject_CallFunction
In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za>
Message-ID: <1286039376.97.0.849075034324.issue9369@psf.upfronthosting.co.za>


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

AFAICT, they are compatible, so +1.

The typical proposition of an incompatible change either proposes to use const char* as the return type, or has multi-level pointers that are proposed to be constified.

----------

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

From report at bugs.python.org  Sat Oct  2 19:14:37 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 02 Oct 2010 17:14:37 +0000
Subject: [issue9369] const char* for PyObject_CallMethod and
	PyObject_CallFunction
In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za>
Message-ID: <1286039677.6.0.947847735674.issue9369@psf.upfronthosting.co.za>


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

Thanks for the confirmation!

----------
resolution:  -> accepted

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

From report at bugs.python.org  Sat Oct  2 19:15:16 2010
From: report at bugs.python.org (Jesse Noller)
Date: Sat, 02 Oct 2010 17:15:16 +0000
Subject: [issue10015] Creating a multiproccess.pool.ThreadPool from a child
	thread blows up.
In-Reply-To: <1286028029.62.0.429525925265.issue10015@psf.upfronthosting.co.za>
Message-ID: <1286039716.61.0.675620160897.issue10015@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I can not, for the life of me, remember why ThreadPool is there, except as a fallback. It's also not part of the documented interface as well. Additionally, in Python 3 we now have futures.

----------

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

From report at bugs.python.org  Sat Oct  2 19:53:47 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Oct 2010 17:53:47 +0000
Subject: [issue9533] metaclass can't derive from ABC
In-Reply-To: <1281090819.15.0.255356922996.issue9533@psf.upfronthosting.co.za>
Message-ID: <1286042027.78.0.950052186389.issue9533@psf.upfronthosting.co.za>


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

You can now create metaclass abcs. However, having __abstractmethods__ does not prevent instance creation. This is a problem with a builtins, though.

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

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

From report at bugs.python.org  Sat Oct  2 20:03:47 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 02 Oct 2010 18:03:47 +0000
Subject: [issue10011] `except` doesn't use `isinstance`
In-Reply-To: <1285973470.62.0.723186105709.issue10011@psf.upfronthosting.co.za>
Message-ID: <1286042627.85.0.260095771295.issue10011@psf.upfronthosting.co.za>


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

It matters when exceptions are expected or are a normal part of control flow. For example StopIteration.

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

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

From report at bugs.python.org  Sat Oct  2 20:49:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 18:49:54 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286045394.93.0.38733691249.issue4661@psf.upfronthosting.co.za>


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

Version 4 of patch, now including doc updates.

The patch set is now complete.

----------
Added file: http://bugs.python.org/file19110/email_parse_bytes4.diff

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

From report at bugs.python.org  Sat Oct  2 21:55:34 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 02 Oct 2010 19:55:34 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1286049334.54.0.405318827585.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, I said msg80877 past, and I think so too, but
os.path module of python2.x seems not to support UNC
correctly, and I'm not sure if the behavior change is
allowed here.

Probably UNC support is new feature, so I'll attach
the patch to solve only this problem as is.

----------
Added file: http://bugs.python.org/file19111/py27_fix_relpath.patch

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

From report at bugs.python.org  Sat Oct  2 22:10:06 2010
From: report at bugs.python.org (Alan McIntyre)
Date: Sat, 02 Oct 2010 20:10:06 +0000
Subject: [issue1710703] zipfile.ZipFile behavior inconsistent.
Message-ID: <1286050206.72.0.299852381344.issue1710703@psf.upfronthosting.co.za>


Changes by Alan McIntyre <alan.mcintyre at gmail.com>:


Removed file: http://bugs.python.org/file9144/empty-zipfile.diff

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

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


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

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

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

In Python 2.6, the following works fine:

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


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

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

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

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

From report at bugs.python.org  Sat Oct  2 22:49:11 2010
From: report at bugs.python.org (Alan McIntyre)
Date: Sat, 02 Oct 2010 20:49:11 +0000
Subject: [issue1710703] zipfile.ZipFile behavior inconsistent.
Message-ID: <1286052551.15.0.173673686625.issue1710703@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

My apologies if Georg was waiting on me to say, "Yes." :-)

I've attached an updated patch that has the NEWS/doc changes Antoine mentioned.  I also just checked that the tests still pass on Linux against the current trunk, and that the docs still build properly.

----------
Added file: http://bugs.python.org/file19112/zipfile_empty3.diff

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

From report at bugs.python.org  Sat Oct  2 22:49:49 2010
From: report at bugs.python.org (Alan McIntyre)
Date: Sat, 02 Oct 2010 20:49:49 +0000
Subject: [issue1710703] zipfile.ZipFile behavior inconsistent.
Message-ID: <1286052589.45.0.596334946986.issue1710703@psf.upfronthosting.co.za>


Changes by Alan McIntyre <alan.mcintyre at gmail.com>:


Removed file: http://bugs.python.org/file18534/zipfile_empty2.diff

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

From report at bugs.python.org  Sat Oct  2 23:17:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 21:17:00 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286054220.22.0.0120410467542.issue4661@psf.upfronthosting.co.za>


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

Rietveld issue, with a small doc addition compared to pach4:

http://codereview.appspot.com/2362041

----------

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

From report at bugs.python.org  Sat Oct  2 23:25:46 2010
From: report at bugs.python.org (David Watson)
Date: Sat, 02 Oct 2010 21:25:46 +0000
Subject: [issue9647] os.confstr() does not handle value changing length
	between calls
In-Reply-To: <1285781559.72.0.62593560462.issue9647@psf.upfronthosting.co.za>
Message-ID: <20101002212537.GA29167@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

> If I understood correctly, you don't want the value to be truncated if the variable grows between the two calls to confstr(). Which behaviour would you expect? A Python exception?

A return size larger than the buffer is *supposed* to indicate
that the current value is larger than the supplied buffer, so I
would just expect it to reallocate the buffer, call confstr()
again and return the new value, unless it was known that such a
situation indicated an actual problem.

In other words, I would not expect it to do anything special.  I
didn't write the original patch the way I did in order to fix
this (potential) bug - it just seemed like the most natural way
to write the code.

----------

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

From report at bugs.python.org  Sat Oct  2 23:33:39 2010
From: report at bugs.python.org (dontbugme)
Date: Sat, 02 Oct 2010 21:33:39 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1286055219.73.0.964980673028.issue6792@psf.upfronthosting.co.za>


dontbugme <pythonbugsbugmenot at spamavert.com> added the comment:

you can add  InstallPath key with the corresponding value at [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Python\PythonCore\2.6\]
if you want disutils installer to detect your python
That makes him detect and install the librarys or scripts to the right directory, but doens't make your library 64bit compatible if it isn't
(means if the library doesn't work on 64 bit i neither will whith this work around) Only possibility of fixing that problem is installing 32bit python

----------
nosy: +dontbugme
versions: +Python 2.6

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

From report at bugs.python.org  Sat Oct  2 23:35:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 21:35:49 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286055349.8.0.334956140879.issue4661@psf.upfronthosting.co.za>


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

Upload svn patch, so that Martin's new rietveld support will (hopefully) create an automatic review link.

----------
Added file: http://bugs.python.org/file19113/email_parse_bytes5.diff

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

From report at bugs.python.org  Sat Oct  2 23:36:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 02 Oct 2010 21:36:53 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1286055413.13.0.0552185433838.issue6792@psf.upfronthosting.co.za>


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


----------
versions:  -Python 2.6

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

From report at bugs.python.org  Sun Oct  3 01:04:46 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 23:04:46 +0000
Subject: [issue10017] pprint.pprint raises TypeError on dictionaries with
	user-defined types as keys
In-Reply-To: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>
Message-ID: <1286060686.15.0.766718245857.issue10017@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Sun Oct  3 01:25:19 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 02 Oct 2010 23:25:19 +0000
Subject: [issue9369] const char* for PyObject_CallMethod and
	PyObject_CallFunction
In-Reply-To: <1279965202.04.0.507207277215.issue9369@psf.upfronthosting.co.za>
Message-ID: <1286061919.24.0.914890304278.issue9369@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/issue9369>
_______________________________________

From report at bugs.python.org  Sun Oct  3 01:48:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 02 Oct 2010 23:48:50 +0000
Subject: [issue1210680] Split email headers near a space
Message-ID: <1286063330.93.0.374250428028.issue1210680@psf.upfronthosting.co.za>


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

Since no test case has been provided I am closing this issue.

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

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

From report at bugs.python.org  Sun Oct  3 02:04:00 2010
From: report at bugs.python.org (Jeremy Kloth)
Date: Sun, 03 Oct 2010 00:04:00 +0000
Subject: [issue6792] Distutils-based installer does not detect 64bit versions
	of Python
In-Reply-To: <1251449540.11.0.0670330819334.issue6792@psf.upfronthosting.co.za>
Message-ID: <1286064240.14.0.123315002371.issue6792@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth at gmail.com>:


----------
nosy: +jkloth

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

From report at bugs.python.org  Sun Oct  3 04:12:53 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 03 Oct 2010 02:12:53 +0000
Subject: [issue9800] Fast path for small int-indexing of lists and tuples
In-Reply-To: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>
Message-ID: <1286071973.46.0.270767704263.issue9800@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

For what it's worth, a similar fast path existed in Python 2 for lists (but not tuples).  It was removed for Python 3.  I'm not sure why it was removed, but it may have been part of removing the PyInt type.

----------
nosy: +stutzbach

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

From report at bugs.python.org  Sun Oct  3 04:16:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Oct 2010 02:16:11 +0000
Subject: [issue1078919] email.Header (via add_header) encodes non-ASCII
	content incorrectly
Message-ID: <1286072171.81.0.277014602652.issue1078919@psf.upfronthosting.co.za>


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

I don't believe either the example that other mailers reject or the one that they accept are in fact RFC compliant.  Encoded words are not supposed to occur in (structured) MIME headers.  The behavior observed is a consequence of all headers, whether structured or unstructured, being treated as if they were unstructured by Header.

(There's a different problem in Python3 with this example, but I'll deal with that in a separate issue.)

What we have here is primarily a documentation bug.  The way to generate the correct (RFC compliant) header is as follows:

>>> m.add_header('Content-Disposition', 'attachment',
... filename=('iso-8859-1', '', 'Fu?baller_sind_klug.ppt'))
>>> str(m)
'Content-Disposition: attachment; filename*="iso-8859-1\'\'Fu%DFballer_sind_klug.ppt"\n\n'

I will add the explanation and this example to the docs.  In addition, in 3.2 I will disallow non-ASCII parameter values unless they are specified in a three element tuple as in the example above.  That will still leave some other places where structured headers are inappropriately encoded by Header (eg: addresses with non-ASCII names), but dealing with that is a somewhat deeper problem.

----------
title: Email.Header encodes non-ASCII content incorrectly -> email.Header (via add_header) encodes non-ASCII content incorrectly
type: feature request -> behavior

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

From report at bugs.python.org  Sun Oct  3 04:36:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 03 Oct 2010 02:36:10 +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: <1286073370.52.0.72639407618.issue9873@psf.upfronthosting.co.za>


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

As per RDM's email to python-dev, a better way to create the pseudo_str values would be by decoding as ascii with a surrogate escape error handler rather than by decoding as latin-1.

----------

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

From report at bugs.python.org  Sun Oct  3 05:37:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Oct 2010 03:37:50 +0000
Subject: [issue1078919] email.Header (via add_header) encodes non-ASCII
	content incorrectly
Message-ID: <1286077070.84.0.639277873448.issue1078919@psf.upfronthosting.co.za>


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

Here is a patch.

----------
keywords: +patch
stage: unit test needed -> patch review
Added file: http://bugs.python.org/file19114/add_header.patch

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

From report at bugs.python.org  Sun Oct  3 06:18:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Oct 2010 04:18:13 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1286079493.41.0.00710763891787.issue6302@psf.upfronthosting.co.za>


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

Here is a patch that makes the output consistently (bytes, string) pairs.  This is definitely a potential backward compatibility issue, but in general code which compensates for the old behavior should work fine with the new behavior, since it was always possible to get a (bytes, None) tuple back as a result, so most code should be handling that case correctly already.

IMO this change is nevertheless worthwhile; especially since if the patch in issue 4661 is accepted decode_header can be enhanced so that it will provide a way to obtain the bytes version of a header containing (RFC invalid) non-ASCII bytes.

Note that this breaks one of the tests in nttplib, so backward compatibility really is an issue, unfortunately.  I think nttplib's use case can be satisfied via the issue 4661 patch coupled with the decode_header bytes-recovery enhancement.

----------
dependencies: +email.parser: impossible to read messages encoded in a different encoding
keywords: +patch
nosy: +pitrou
Added file: http://bugs.python.org/file19115/decode_header.patch

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

From report at bugs.python.org  Sun Oct  3 06:18:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Oct 2010 04:18:33 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1286079513.11.0.0773093254699.issue6302@psf.upfronthosting.co.za>


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


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

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

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


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

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

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

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

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


This probably means that Tcl wasn't installed properly.

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

Help is appreciated!

Grant

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

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

From report at bugs.python.org  Sun Oct  3 08:34:13 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 03 Oct 2010 06:34:13 +0000
Subject: [issue10012] httplib shadows builtin, assumes strings
In-Reply-To: <1285976648.58.0.0752019030242.issue10012@psf.upfronthosting.co.za>
Message-ID: <1286087653.52.0.363108573867.issue10012@psf.upfronthosting.co.za>


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

Here are patches with tests for py3k and release27-maint, for explicit conversion of header values to bytes/str.

If someone likes to review the patch, please provide your comments.

----------
keywords: +patch
resolution:  -> accepted
stage:  -> patch review
type:  -> behavior
versions: +Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19116/issue10012-release27-maint.patch

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

From report at bugs.python.org  Sun Oct  3 08:34:40 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 03 Oct 2010 06:34:40 +0000
Subject: [issue10012] httplib shadows builtin, assumes strings
In-Reply-To: <1285976648.58.0.0752019030242.issue10012@psf.upfronthosting.co.za>
Message-ID: <1286087680.17.0.753688423944.issue10012@psf.upfronthosting.co.za>


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


Added file: http://bugs.python.org/file19117/issue10012-py3k.patch

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

From report at bugs.python.org  Sun Oct  3 14:44:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Oct 2010 12:44:53 +0000
Subject: [issue9873] urllib.parse: Allow bytes in some APIs that use string
	literals internally
In-Reply-To: <1286073370.52.0.72639407618.issue9873@psf.upfronthosting.co.za>
Message-ID: <1286109884.3111.16.camel@localhost.localdomain>


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

> As per RDM's email to python-dev, a better way to create the
> pseudo_str values would be by decoding as ascii with a surrogate
> escape error handler rather than by decoding as latin-1.

If you were worried about performance, then surrogateescape is certainly
much slower than latin1.

----------

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

From report at bugs.python.org  Sun Oct  3 15:04:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Oct 2010 13:04:30 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1286111070.01.0.517010440861.issue6302@psf.upfronthosting.co.za>


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

> I think nttplib's use case can be satisfied via the issue 4661 patch
> coupled with the decode_header bytes-recovery enhancement.

I don't really understand how that could.
nntplib needs to "decode" (in the decode_header sense) headers containing unescaped as well as escaped non-ASCII chars. Encoding with "ascii" clearly breaks the first use case.

Since the decode_header() API is so silly to begin with, I'd suggest providing another higher-level API instead. One which takes an str and returns another str (not bytes!) instead of that list of tuples.

If you really want to "fix" the current decode_header(), I'd recommend adding an optional "encoding" parameter so that nntplib can give utf-8 instead of ascii. nntplib and other consumers will still have to decode back in order to get an str, which makes the whole encoding thing a bit useless.

Oh, and instead of None, it would be nicer to give the actual encoding (e.g. "ascii"). It's no fun trying to guess.

----------
nosy: +barry

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

From report at bugs.python.org  Sun Oct  3 16:34:03 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 03 Oct 2010 14:34:03 +0000
Subject: [issue8980] distutils.tests.test_register.RegisterTestCase.test_strict
	fails
In-Reply-To: <1276313488.44.0.388606421429.issue8980@psf.upfronthosting.co.za>
Message-ID: <1286116443.4.0.698242917327.issue8980@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

done in r85197 / r85198

Thanks !

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

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

From report at bugs.python.org  Sun Oct  3 16:38:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Oct 2010 14:38:23 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1286116703.16.0.349977841908.issue6302@psf.upfronthosting.co.za>


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

Here is a proposal for decode_header_as_string().

----------
Added file: http://bugs.python.org/file19118/decode_header.patch

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

From report at bugs.python.org  Sun Oct  3 16:58:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 03 Oct 2010 14:58:09 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1286117889.33.0.307128574541.issue6302@psf.upfronthosting.co.za>


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

Yes, that was a late night post and as I was falling asleep I realized that I was wrong.

Certainly decode_header_as_string is a function most people using the email package will want and will re-implement in one form or another, so I think it is a good idea to add it.  I will take a look at the patch later.  And with such a function added we can leave decode_header alone for backward compatibility.

----------

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

From report at bugs.python.org  Sun Oct  3 17:31:39 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 15:31:39 +0000
Subject: [issue9989] ctypes bitfield problem
In-Reply-To: <1285785294.07.0.231109223206.issue9989@psf.upfronthosting.co.za>
Message-ID: <1286119899.4.0.614099630457.issue9989@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I think this issue is duplicate of #6493.

----------
nosy: +ocean-city
resolution:  -> duplicate
status: open -> closed
superseder:  -> Can not set value for structure members larger than 32 bits

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

From report at bugs.python.org  Sun Oct  3 17:44:42 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 15:44:42 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1286120682.11.0.600424759015.issue6493@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I glanced at my patch again, and I noticed it has a problem.
SET() cannot handle type larger than unsigned int on windows.
I'll recreate the patch...

----------
nosy: +ned.deily, stutzbach

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

From report at bugs.python.org  Sun Oct  3 17:47:05 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 03 Oct 2010 15:47:05 +0000
Subject: [issue9281] Race condition in distutils.dir_util.mkpath()
In-Reply-To: <1279342839.57.0.133468665449.issue9281@psf.upfronthosting.co.za>
Message-ID: <1286120825.5.0.956773317054.issue9281@psf.upfronthosting.co.za>


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

I'm attaching the patch for some mkpath functions in distutils2.

----------
components: +Distutils2
versions: +3rd party -Python 2.6
Added file: http://bugs.python.org/file19119/distutils2-mkpath.patch

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

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


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

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

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



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

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

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

From report at bugs.python.org  Sun Oct  3 18:34:31 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 16:34:31 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1286123671.7.0.877925324078.issue6493@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is at least better, simple patch. But ideally,
mask should be created from variable type. "short" mask
should be created for "short" variable, "long long" mask
for "long long" variable, vise verse.

I'll create such patch next. I hope it's final solution.

////////////////////////////////////////
// This works on attached patch.

from __future__ import print_function
import ctypes
class Blah(ctypes.Structure):
    _fields_ = [("a", ctypes.c_uint64, 64),
                ("b", ctypes.c_uint16, 16),
                ("c", ctypes.c_uint8, 8),
                ("d", ctypes.c_uint8, 8)]

x = Blah(0xFEDCBA9876543210,0xBEEF,0x44,0x12)
print(Blah.a, hex(x.a))
print(Blah.b, hex(x.b))
print(Blah.c, hex(x.c))
print(Blah.d, hex(x.d))

----------
versions:  -Python 2.6
Added file: http://bugs.python.org/file19120/py3k_fix_ctypes_cfields.patch

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

From report at bugs.python.org  Sun Oct  3 18:36:00 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 16:36:00 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1286123760.24.0.659951832419.issue6493@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file14506/ctypes_workaround.patch

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

From report at bugs.python.org  Sun Oct  3 18:36:13 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 16:36:13 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1286123773.68.0.0504983826868.issue6493@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file14507/ctypes_workaround_2.patch

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

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


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

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

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

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

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

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


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


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python

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

From report at bugs.python.org  Sun Oct  3 20:03:00 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 18:03:00 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1286128980.78.0.636402909366.issue6493@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry?my patch didn't work again... Because of this
compiler behavior. Is this ANSI standard?

#include <stdio.h>

typedef unsigned __int32 uint32;

static void
print_bits(uint32 n)
{
    int i;

    for (i = 31; i >= 0; --i)
    {
        printf("%c", (n & (1 << i)) ? '1' : '0');
    }
    printf(" : %X\n", n);
}

int main()
{
    uint32 n;

    n = 1;
    print_bits(n << 30);
    print_bits(n << 31);
    print_bits(n << 32);
    print_bits((n << 31) << 1);
}

R:\test\bitshift>a
01000000000000000000000000000000 : 40000000
10000000000000000000000000000000 : 80000000
00000000000000000000000000000001 : 1
00000000000000000000000000000000 : 0

I thought n << 32 should be 0. I hope new patch
is somehow better.

----------
Added file: http://bugs.python.org/file19121/py3k_fix_ctypes_cfields_v2.patch

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

From report at bugs.python.org  Sun Oct  3 20:19:04 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 03 Oct 2010 18:19:04 +0000
Subject: [issue9272] CGIHTTPServer poisons os.environ
In-Reply-To: <1279270191.51.0.568678636745.issue9272@psf.upfronthosting.co.za>
Message-ID: <1286129944.15.0.0400647080597.issue9272@psf.upfronthosting.co.za>


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

Fix committed in revision 85202 (py3k), r85203 (release31-maint), r85204(release27-maint). I had change the patch to use copy.deepcopy instead of os.environ.copy() because for the purposes of test os.environ was masked with EnvironmentGuard which does not have copy method.

Thanks for the patch.

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

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

From report at bugs.python.org  Sun Oct  3 20:26:35 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 03 Oct 2010 18:26:35 +0000
Subject: [issue10012] httplib shadows builtin, assumes strings
In-Reply-To: <1285976648.58.0.0752019030242.issue10012@psf.upfronthosting.co.za>
Message-ID: <1286130395.0.0.0672001457923.issue10012@psf.upfronthosting.co.za>


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

Fixed in r85205 (py3k), r85206 (release31-maint) and r85207 (release27-maint).

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

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

From report at bugs.python.org  Sun Oct  3 20:51:48 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 18:51:48 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1286131908.75.0.702481955366.issue6493@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file19122/py3k_fix_ctypes_cfields_v2.patch

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

From report at bugs.python.org  Sun Oct  3 20:52:07 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 18:52:07 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1286131927.44.0.846401603546.issue6493@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file19121/py3k_fix_ctypes_cfields_v2.patch

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

From report at bugs.python.org  Sun Oct  3 21:14:49 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 19:14:49 +0000
Subject: [issue6493] Can not set value for structure members larger than 32
	bits
In-Reply-To: <1247706719.26.0.735618414968.issue6493@psf.upfronthosting.co.za>
Message-ID: <1286133289.3.0.0305343347133.issue6493@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

This patch removes MAX_SIZE_INT limitation. I hope this
is final patch. I confirmed all ctypes test passed on
my environment. (Windows, VS8.0)

----------
Added file: http://bugs.python.org/file19123/py3k_fix_ctypes_cfields_v3.patch

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

From report at bugs.python.org  Sun Oct  3 21:20:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Oct 2010 19:20:36 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1286133636.99.0.660062470229.issue10020@psf.upfronthosting.co.za>


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


----------
assignee: docs at python -> ghaering
nosy: +ghaering
versions: +Python 3.1, Python 3.2

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

From report at bugs.python.org  Sun Oct  3 21:21:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Oct 2010 19:21:01 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1286133661.79.0.97644058179.issue10019@psf.upfronthosting.co.za>


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


----------
assignee:  -> bob.ippolito
nosy: +bob.ippolito

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

From report at bugs.python.org  Sun Oct  3 21:25:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Oct 2010 19:25:34 +0000
Subject: [issue1078919] email.Header (via add_header) encodes non-ASCII
	content incorrectly
Message-ID: <1286133934.56.0.300395995007.issue1078919@psf.upfronthosting.co.za>


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

> In addition, in 3.2 I will disallow non-ASCII parameter values unless
> they are specified in a three element tuple as in the example above.

Why would the caller be required to choose an encoding while you could simply default to utf-8? There doesn't seem to be much value in forcing the use of e.g. iso-8859-15.
Also, I'm not sure I understand what the goal of email6 is if you're breaking compatibility in email5 anyway :)

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

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

From report at bugs.python.org  Sun Oct  3 21:29:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Oct 2010 19:29:02 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1286134142.91.0.603390783814.issue6706@psf.upfronthosting.co.za>


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

I'm not an asyncore expert, but I can't see anything wrong with the patch.

----------
stage: needs patch -> patch review
versions:  -Python 2.6, Python 2.7, Python 3.1

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

From report at bugs.python.org  Sun Oct  3 21:31:27 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 19:31:27 +0000
Subject: [issue8017] c_char_p.value does not return a bytes object in Windows.
In-Reply-To: <1267074701.8.0.562765238894.issue8017@psf.upfronthosting.co.za>
Message-ID: <1286134287.72.0.936690250857.issue8017@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

You need to change

test_string = ctypes.c_char_p("This Is a test string, that should be of type bytes")

to

test_string = ctypes.c_char_p(b"This Is a test string, that should be of type bytes")

but this issue itself seems to be already fixed.

----------
nosy: +ocean-city
resolution:  -> fixed
stage: needs patch -> 
status: open -> closed

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

From report at bugs.python.org  Sun Oct  3 21:34:04 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 19:34:04 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1286134444.66.0.493728227891.issue9884@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Probably this issue is duplicate of #9266.

----------
nosy: +ocean-city

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

From report at bugs.python.org  Sun Oct  3 21:34:45 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 03 Oct 2010 19:34:45 +0000
Subject: [issue9266] ctypes "ValueError: NULL pointer access" on Win7 x64
In-Reply-To: <1279198550.56.0.12735266712.issue9266@psf.upfronthosting.co.za>
Message-ID: <1286134485.77.0.798007018213.issue9266@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Probably this issue is duplicate of #9884.

----------
nosy: +ocean-city

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

From report at bugs.python.org  Sun Oct  3 21:36:41 2010
From: report at bugs.python.org (Greg Hazel)
Date: Sun, 03 Oct 2010 19:36:41 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1286134601.91.0.978070849095.issue9884@psf.upfronthosting.co.za>


Changes by Greg Hazel <ghazel at users.sourceforge.net>:


----------
nosy: +ghazel

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

From report at bugs.python.org  Sun Oct  3 21:50:47 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 03 Oct 2010 19:50:47 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1286135447.67.0.790072872586.issue10019@psf.upfronthosting.co.za>


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

The C encoder should not be used when indent=0. Here is a patch+test for 2.7.
Note that json.dump (into a file object) already correctly emit newlines.

----------
keywords: +patch
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file19124/json_indent0.patch

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

From report at bugs.python.org  Sun Oct  3 22:24:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 03 Oct 2010 20:24:22 +0000
Subject: [issue10016] shutil.copyfile -- allow sparse copying
In-Reply-To: <1286029015.57.0.815158740908.issue10016@psf.upfronthosting.co.za>
Message-ID: <1286137462.96.0.013824900872.issue10016@psf.upfronthosting.co.za>


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

The use of fdst.truncate() is indeed wrong, since truncate() in 3.x is defined as truncating up to the current file position (which has been moved forward by the latest seek()).

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

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

From report at bugs.python.org  Sun Oct  3 23:31:25 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Sun, 03 Oct 2010 21:31:25 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1286141485.28.0.836283606545.issue10020@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Without SQLITE_OMIT_LOAD_EXTENSION, builds will break on Mac OS X 10.5 and 10.6 and maybe other platforms.

----------

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

From report at bugs.python.org  Sun Oct  3 23:48:33 2010
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Sun, 03 Oct 2010 21:48:33 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1286142513.75.0.302662564073.issue10020@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Fixed in r85208 by adding a note to the docs.

----------
resolution:  -> fixed
status: open -> pending

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

From report at bugs.python.org  Mon Oct  4 00:21:57 2010
From: report at bugs.python.org (phep)
Date: Sun, 03 Oct 2010 22:21:57 +0000
Subject: [issue9968] Let cgi.FieldStorage have named uploaded file
In-Reply-To: <1285675096.14.0.24974141754.issue9968@psf.upfronthosting.co.za>
Message-ID: <1286144517.81.0.105204989352.issue9968@psf.upfronthosting.co.za>


phep <patrice.pillot at teletopie.net> added the comment:

Well, this is actually somewhat more complicated than what my first tests showed due to the way multipart/form-data is dealt with in FieldStorage.read_multi().

The solution I proposed last time only works if the uploaded file is passed as the first form field.

I have to further study how things work in order to find some coherent solution.

I may not have time to go back to this issue before next week unfortunately.

phep

----------

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

From report at bugs.python.org  Mon Oct  4 00:45:45 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 03 Oct 2010 22:45:45 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1286145945.14.0.0723976619296.issue10020@psf.upfronthosting.co.za>


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

Thanks, Gerhard!

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

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

From report at bugs.python.org  Mon Oct  4 02:07:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Oct 2010 00:07:47 +0000
Subject: [issue1078919] email.Header (via add_header) encodes non-ASCII
	content incorrectly
Message-ID: <1286150867.86.0.326703689946.issue1078919@psf.upfronthosting.co.za>


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

The compatibility argument is a fair point, and yes we could default to utf8 and no language.  So that is probably a better solution than raising the error.

----------

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

From report at bugs.python.org  Mon Oct  4 02:52:51 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Mon, 04 Oct 2010 00:52: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: <1286153571.56.0.333502733747.issue1589@psf.upfronthosting.co.za>


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

I added some extra verification to Mercurial (http://www.selenic.com/hg/rev/f2937d6492c5). Feel free to use the following under the Python license in Python or elsewhere. It could be a separate method/function or it could integrated in wrap_socket and controlled by a keyword. I would appreciate if you find the implementation insufficient or incorrect.

The purpose with this function is to verify if the received and validated certificate matches the host we intended to connect to.

I try to keep it simple and to fail to the safe side. 

"Correct" subjectAltName handling seems not to be feasible.

Are CRLs checked by the SSL module? Otherwise it deserves a big fat warning.

(I now assume that notBefore is handled by the SSL module and shouldn't be checked here.)

def _verifycert(cert, hostname):
    '''Verify that cert (in socket.getpeercert() format) matches
    hostname and is valid at this time. CRLs and subjectAltName are
    not handled.
    
    Returns error message if any problems are found and None on success.
    '''
    if not cert:
        return _('no certificate received')
    notafter = cert.get('notAfter')
    if notafter and time.time() > ssl.cert_time_to_seconds(notafter):
        return _('certificate expired %s') % notafter
    dnsname = hostname.lower()
    for s in cert.get('subject', []):
        key, value = s[0]
        if key == 'commonName':
            certname = value.lower()
            if (certname == dnsname or
                '.' in dnsname and
                certname == '*.' + dnsname.split('.', 1)[1]):
                return None
            return _('certificate is for %s') % certname
    return _('no commonName found in certificate')


def check(a, b):
    if a != b:
        print (a, b)

# Test non-wildcard certificates        
check(_verifycert({'subject': ((('commonName', 'example.com'),),)}, 'example.com'),
    None)
check(_verifycert({'subject': ((('commonName', 'example.com'),),)}, 'www.example.com'),
    'certificate is for example.com')
check(_verifycert({'subject': ((('commonName', 'www.example.com'),),)}, 'example.com'),
    'certificate is for www.example.com')

# Test wildcard certificates
check(_verifycert({'subject': ((('commonName', '*.example.com'),),)}, 'www.example.com'),
    None)
check(_verifycert({'subject': ((('commonName', '*.example.com'),),)}, 'example.com'),
    'certificate is for *.example.com')
check(_verifycert({'subject': ((('commonName', '*.example.com'),),)}, 'w.w.example.com'),
    'certificate is for *.example.com')

# Avoid some pitfalls
check(_verifycert({'subject': ((('commonName', '*.foo'),),)}, 'foo'),
    'certificate is for *.foo')
check(_verifycert({'subject': ((('commonName', '*o'),),)}, 'foo'),
    'certificate is for *o')

import time
lastyear = time.gmtime().tm_year - 1
nextyear = time.gmtime().tm_year + 1
check(_verifycert({'notAfter': 'May  9 00:00:00 %s GMT' % lastyear}, 'example.com'),
    'certificate expired May  9 00:00:00 %s GMT' % lastyear)
check(_verifycert({'notAfter': 'Sep 29 15:29:48 %s GMT' % nextyear, 'subject': ()}, 'example.com'),
    'no commonName found in certificate')
check(_verifycert(None, 'example.com'),
    'no certificate received')

----------
nosy: +kiilerix

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

From report at bugs.python.org  Mon Oct  4 03:19:32 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Mon, 04 Oct 2010 01:19:32 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1286155172.36.0.443175129531.issue6484@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Removed file: http://bugs.python.org/file15753/.mailcap

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

From report at bugs.python.org  Mon Oct  4 03:27:15 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Mon, 04 Oct 2010 01:27:15 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1286155635.71.0.868916315239.issue6484@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

Replacing .mailcap with mailcap.txt. Same content, but with more conventional file name.

----------
Added file: http://bugs.python.org/file19125/mailcap.txt

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

From report at bugs.python.org  Mon Oct  4 03:29:55 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Mon, 04 Oct 2010 01:29:55 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1286155795.76.0.892534719048.issue6484@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Removed file: http://bugs.python.org/file15752/test_mailcap.py

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

From report at bugs.python.org  Mon Oct  4 03:30:02 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Mon, 04 Oct 2010 01:30:02 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1286155802.39.0.42312073352.issue6484@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Removed file: http://bugs.python.org/file17042/test_mailcap.py

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

From report at bugs.python.org  Mon Oct  4 03:39:24 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Mon, 04 Oct 2010 01:39:24 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1286156364.93.0.21945715625.issue6484@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

r.david.murray: Thanks a lot for your feedback! I've implemented those suggestions and they helped located a bug. (See case 9923.)

----------
Added file: http://bugs.python.org/file19126/test_mailcap.py

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

From report at bugs.python.org  Mon Oct  4 03:40:23 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Mon, 04 Oct 2010 01:40:23 +0000
Subject: [issue6484] No unit test for mailcap module
In-Reply-To: <1247596747.53.0.161658367753.issue6484@psf.upfronthosting.co.za>
Message-ID: <1286156423.37.0.10456094656.issue6484@psf.upfronthosting.co.za>


Changes by Gregory Nofi <crackityjones2004-p at yahoo.com>:


Added file: http://bugs.python.org/file19127/test_mailcap.py

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

From report at bugs.python.org  Mon Oct  4 03:44:59 2010
From: report at bugs.python.org (Gregory Nofi)
Date: Mon, 04 Oct 2010 01:44:59 +0000
Subject: [issue9923] mailcap module may not work on non-POSIX platforms if
	MAILCAPS env variable is set
In-Reply-To: <1285211036.93.0.380980799093.issue9923@psf.upfronthosting.co.za>
Message-ID: <1286156699.81.0.403671204227.issue9923@psf.upfronthosting.co.za>


Gregory Nofi <crackityjones2004-p at yahoo.com> added the comment:

I just submitted new versions of test_mailcap.py in case 6484.

----------

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

From report at bugs.python.org  Mon Oct  4 09:17:11 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 04 Oct 2010 07:17:11 +0000
Subject: [issue9884] The 4th parameter of method always None or 0 on x64
	Windows.
In-Reply-To: <1284714742.48.0.856656538994.issue9884@psf.upfronthosting.co.za>
Message-ID: <1286176631.23.0.0489292050024.issue9884@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I don't have x64 machine, so I cannot test this.
So this is just an idea.

It seems
Modules/_ctypes/libffi_msvc is a bit old.
Modules/_ctypes/libffi/src/x86 is newer.
Maybe this issue can be fixed by using newer one?

Thank you.

----------

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

From report at bugs.python.org  Mon Oct  4 09:26:47 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 04 Oct 2010 07:26:47 +0000
Subject: [issue9800] Fast path for small int-indexing of lists and tuples
In-Reply-To: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>
Message-ID: <1286177207.0.0.34562514967.issue9800@psf.upfronthosting.co.za>


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

A disadvantage of the patch is that ceval.c needs to know about the internal implementation of a PyLong.  At the moment, this information is encapsulated only in Objects/longobject.c and a couple of other places (I think marshal.c).

----------

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

From report at bugs.python.org  Mon Oct  4 10:57:33 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 04 Oct 2010 08:57:33 +0000
Subject: [issue10016] shutil.copyfile -- allow sparse copying
In-Reply-To: <1286029015.57.0.815158740908.issue10016@psf.upfronthosting.co.za>
Message-ID: <1286182653.05.0.126379115496.issue10016@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


----------
assignee:  -> tarek

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

From report at bugs.python.org  Mon Oct  4 12:37:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 10:37:11 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1286153571.56.0.333502733747.issue1589@psf.upfronthosting.co.za>
Message-ID: <1286188623.3178.9.camel@localhost.localdomain>


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

Hello,

> I added some extra verification to Mercurial
> (http://www.selenic.com/hg/rev/f2937d6492c5). Feel free to use the
> following under the Python license in Python or elsewhere. It could be
> a separate method/function or it could integrated in wrap_socket and
> controlled by a keyword. I would appreciate if you find the
> implementation insufficient or incorrect.

Thank you, I'll take a look!

> Are CRLs checked by the SSL module? Otherwise it deserves a big fat
> warning.

They are not, but AFAIK most browsers don't check CRLs either...
(or, rather they don't download updated CRLs)

> (I now assume that notBefore is handled by the SSL module and
> shouldn't be checked here.)

I can't say for sure, but OpenSSL seems to handle both notBefore and
notAfter as part of its cert verification routine (see interval_verify()
and cert_check_time() in crypto/x509/x509_vfy.c).

----------

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

From report at bugs.python.org  Mon Oct  4 13:12:49 2010
From: report at bugs.python.org (Tom Potts)
Date: Mon, 04 Oct 2010 11:12:49 +0000
Subject: [issue10016] shutil.copyfile -- allow sparse copying
In-Reply-To: <1286029015.57.0.815158740908.issue10016@psf.upfronthosting.co.za>
Message-ID: <1286190769.52.0.201647397651.issue10016@psf.upfronthosting.co.za>


Tom Potts <karaken12 at gmail.com> added the comment:

@pitrou
Hmm... the online docs and the contents of the doc directory on the trunk branch say differently:
"""
Resize the stream to the given *size* in bytes (or the current position if *size* is not specified).  The current stream position isn't changed. This resizing can extend or reduce the current file size.  In case of extension, the contents of the new file area depend on the platform (on most systems, additional bytes are zero-filled, on Windows they're undetermined).  The new file size is returned.
"""
Unless you know something else about this, I'm going to assume it's still okay to use.

@r.david.murray
Thanks for your comments -- I'm trying to put together some unit tests and documentation, against the Subversion trunk.

Tom

----------

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

From report at bugs.python.org  Mon Oct  4 13:57:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 11:57:44 +0000
Subject: [issue10016] shutil.copyfile -- allow sparse copying
In-Reply-To: <1286029015.57.0.815158740908.issue10016@psf.upfronthosting.co.za>
Message-ID: <1286193464.95.0.149547410668.issue10016@psf.upfronthosting.co.za>


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

Ok, after experimenting, I now understand what the truncate() call is for.

However, your heuristic for detecting sparse files is wrong. The unit for st_blocks is undefined as per the POSIX standard, although it gives recommendations:

?The unit for the st_blocks member of the stat structure is not defined within IEEE Std 1003.1-2001. In some implementations it is 512 bytes. It may differ on a file system basis. There is no correlation between values of the st_blocks and st_blksize, and the f_bsize (from <sys/statvfs.h>) structure members.

Traditionally, some implementations defined the multiplier for st_blocks in <sys/param.h> as the symbol DEV_BSIZE.?

(http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/stat.h.html)

Under Linux, 512 turns out to be the right multiplier (and not st_blksize):

>>> f = open("foo", "wb")
>>> f.write(b"x" * 4096)
4096
>>> f.truncate(16384)
16384
>>> f.close()
>>> st = os.stat("foo")
>>> st.st_size
16384
>>> st.st_blocks
8
>>> st.st_blocks * st.st_blksize
32768
>>> st.st_blocks * 512
4096

Also, GNU `cp` uses S_BLKSIZE rather than DEV_BSIZE when trying to detect the st_blocks unit size (both are 512 under Linux).

----------

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

From report at bugs.python.org  Mon Oct  4 14:01:50 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 04 Oct 2010 12:01:50 +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: <1286193710.81.0.33976198863.issue9873@psf.upfronthosting.co.za>


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

Yeah, I'll have to time it to see how much difference latin-1 vs surrogateescape makes when the MSB is set in any bytes.

----------

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

From report at bugs.python.org  Mon Oct  4 14:03:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 12:03:55 +0000
Subject: [issue10016] shutil.copyfile -- allow sparse copying
In-Reply-To: <1286029015.57.0.815158740908.issue10016@psf.upfronthosting.co.za>
Message-ID: <1286193835.66.0.435975871584.issue10016@psf.upfronthosting.co.za>


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

By the way:

> Thanks for your comments -- I'm trying to put together some unit tests > and documentation, against the Subversion trunk.

Please ignore trunk; all development (new features) should be done against branches/py3k.

----------

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

From report at bugs.python.org  Mon Oct  4 14:50:39 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 04 Oct 2010 12:50:39 +0000
Subject: [issue9725] urllib.request.FancyURLopener won't connect to pages
	requiring username and password
In-Reply-To: <1283274337.79.0.0864543833676.issue9725@psf.upfronthosting.co.za>
Message-ID: <1286196639.18.0.759024334912.issue9725@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/issue9725>
_______________________________________

From report at bugs.python.org  Mon Oct  4 15:56:52 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Mon, 04 Oct 2010 13:56:52 +0000
Subject: [issue7768] raw_input should encode unicode prompt with
	std.stdout.encoding.
In-Reply-To: <1264309924.17.0.144254143298.issue7768@psf.upfronthosting.co.za>
Message-ID: <1286200612.06.0.508401862722.issue7768@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

annoying stuff, indeed...

$ python -c 'print u"La cl\xe9: "'
La cl?: 

$ python -c 'raw_input(u"La cl\xe9: ")'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 5: ordinal not in range(128)

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

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

From report at bugs.python.org  Mon Oct  4 16:08:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 04 Oct 2010 14:08:14 +0000
Subject: [issue4775] Incorrect documentation - UTC time
In-Reply-To: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za>
Message-ID: <1286201294.03.0.737138617735.issue4775@psf.upfronthosting.co.za>


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

Based on the discussion so far, I am going to close this as "invalid".

----------
assignee: georg.brandl -> belopolsky
resolution:  -> invalid
status: open -> pending

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

From report at bugs.python.org  Mon Oct  4 16:15:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 04 Oct 2010 14:15:02 +0000
Subject: [issue7789] Issue using datetime with format()
In-Reply-To: <1264533717.66.0.926018869233.issue7789@psf.upfronthosting.co.za>
Message-ID: <1286201702.2.0.288887102617.issue7789@psf.upfronthosting.co.za>


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

The original bug report is invalid and the documentation issue is a duplicate of #8913.

----------
nosy: +belopolsky
resolution:  -> duplicate
superseder:  -> Document that datetime.__format__ is datetime.strftime

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

From report at bugs.python.org  Mon Oct  4 16:15:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 04 Oct 2010 14:15:09 +0000
Subject: [issue7789] Issue using datetime with format()
In-Reply-To: <1264533717.66.0.926018869233.issue7789@psf.upfronthosting.co.za>
Message-ID: <1286201709.69.0.18768592984.issue7789@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/issue7789>
_______________________________________

From report at bugs.python.org  Mon Oct  4 16:26:01 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Oct 2010 14:26:01 +0000
Subject: [issue9800] Fast path for small int-indexing of lists and tuples
In-Reply-To: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>
Message-ID: <1286202361.47.0.23585740655.issue9800@psf.upfronthosting.co.za>


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

In the past, we've allow ceval.c to peer through encapsulation in order to have fast paths.

----------

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

From report at bugs.python.org  Mon Oct  4 16:37:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 14:37:40 +0000
Subject: [issue9960] test_structmembers fails on s390x (bigendian 64-bit):
	int/Py_ssize_t issue
In-Reply-To: <1285600296.08.0.731959847047.issue9960@psf.upfronthosting.co.za>
Message-ID: <1286203060.25.0.0403909069786.issue9960@psf.upfronthosting.co.za>


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

Is this 2.7-specific? Otherwise, it would be better to provide a patch for 3.2 first, and then svnmerge to other branches.

> My reading of Python/getargs.c is that this macro does affect "u#" in a > manner analogous to "s#"; does this documentation need clarifying?

Probably. Same for "es#", "et#" and "t#" perhaps?

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

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

From report at bugs.python.org  Mon Oct  4 16:39:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 14:39:57 +0000
Subject: [issue9800] Fast path for small int-indexing of lists and tuples
In-Reply-To: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>
Message-ID: <1286203197.78.0.199114695953.issue9800@psf.upfronthosting.co.za>


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

As I mentioned, the speedup is invisible anyway, so it's not really a "fast path" ;)

----------

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

From report at bugs.python.org  Mon Oct  4 16:49:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 04 Oct 2010 14:49:48 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1286203788.23.0.351977738526.issue8913@psf.upfronthosting.co.za>


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

Alexander closed issue 7789 in favor of this one, which is fine, but I want to respond to Eric's rejection there of including info about datetime in the 'format mini language' section of the docs.  His point was that only the builtin types were documented there, but if the goal is to get people to actually use this facility, it would be helpful if some mention were made there of other stdlib types that support __format__.  Some set of 'see also' links, perhaps in a footnote?

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

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

From report at bugs.python.org  Mon Oct  4 16:57:18 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 04 Oct 2010 14:57:18 +0000
Subject: [issue8913] Document that datetime.__format__ is datetime.strftime
In-Reply-To: <1275794779.99.0.00462382173098.issue8913@psf.upfronthosting.co.za>
Message-ID: <1286204238.56.0.976943296627.issue8913@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm okay with that. Grepping Lib shows that date/datetime/time and Decimal are the only types that implement __format__. Decimal largely implements the same language as float.

----------

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

From report at bugs.python.org  Mon Oct  4 17:01:20 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 04 Oct 2010 15:01:20 +0000
Subject: [issue1078919] email.Header (via add_header) encodes non-ASCII
	content incorrectly
Message-ID: <1286204480.98.0.1212283021.issue1078919@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

RDM, I wonder if it wouldn't be better (in email6) to use an instance to represent the 3-tuple instead?  It might make for clearer client code, and would allow you to default things you might generally not care about.  E.g.

class NonASCIIParameter: # XXX come up with better name
  def __init__(self, text, charset='utf-8', language=''):

It's unfortunate that you have to reorder the arguments from the 3-tuple form of (charset, language, text) but I think you could play games with keyword arguments to make them consistent.

In general the patch looks fine to me, though I suggest splitting test_add_header() into separate tests for each of the three conditions you're testing there.

----------

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

From report at bugs.python.org  Mon Oct  4 17:10:42 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 04 Oct 2010 15:10:42 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1286205042.36.0.365725674256.issue6302@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

In email6, can we at least make tuple returning methods return namedtuples instead?

----------

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

From report at bugs.python.org  Mon Oct  4 17:18:41 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 04 Oct 2010 15:18:41 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1245288976.09.0.298419063758.issue6302@psf.upfronthosting.co.za>
Message-ID: <1286205521.06.0.950416103352.issue6302@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I agree that it makes sense to have consistent types in the output.  As for whether to add a new method or fix the existing one, I'm a bit torn, but I'd probably opt for fixing the existing function rather than adding a new one, just because I think there are few Python 3 applications out there that are counting on the old behavior.  (I could be wrong though ;).

----------

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

From report at bugs.python.org  Mon Oct  4 17:24:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 15:24:51 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1286205521.06.0.950416103352.issue6302@psf.upfronthosting.co.za>
Message-ID: <1286205884.3178.45.camel@localhost.localdomain>


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

> I agree that it makes sense to have consistent types in the output.
> As for whether to add a new method or fix the existing one, I'm a bit
> torn, but I'd probably opt for fixing the existing function rather
> than adding a new one, just because I think there are few Python 3
> applications out there that are counting on the old behavior.  (I
> could be wrong though ;).

The point of a new method is to return the header as a human-readable
string, rather than a list of tuples. It has added value besides leaving
the old method alone ;)

----------

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

From report at bugs.python.org  Mon Oct  4 17:27:38 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 04 Oct 2010 15:27:38 +0000
Subject: [issue6302] email.header.decode_header data types are inconsistent
	and incorrectly documented
In-Reply-To: <1286205884.3178.45.camel@localhost.localdomain>
Message-ID: <20101004112733.5861318b@mission>


Barry A. Warsaw <barry at python.org> added the comment:

>The point of a new method is to return the header as a human-readable
>string, rather than a list of tuples. It has added value besides
>leaving the old method alone ;)

+1 then! :)

----------

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

From report at bugs.python.org  Mon Oct  4 17:39:31 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 04 Oct 2010 15:39:31 +0000
Subject: [issue9065] tarfile:  default root:root ownership is incorrect.
In-Reply-To: <1277332057.13.0.313961006951.issue9065@psf.upfronthosting.co.za>
Message-ID: <1286206771.1.0.97023418429.issue9065@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Fixed in r85211 (py3k), r85212 (release31-maint), r85213 (release27-maint).

Thank you for the report.

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

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

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


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

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

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


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

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

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

From report at bugs.python.org  Mon Oct  4 18:29:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Oct 2010 16:29:00 +0000
Subject: [issue10021] Format parser is too permissive
In-Reply-To: <1286209446.65.0.698670214161.issue10021@psf.upfronthosting.co.za>
Message-ID: <1286209740.59.0.608980630816.issue10021@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/issue10021>
_______________________________________

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


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

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

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

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

From report at bugs.python.org  Mon Oct  4 18:37:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 16:37:12 +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: <1286210232.91.0.247554212978.issue1589@psf.upfronthosting.co.za>


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

Here is a patch against py3k. It adds a single ssl.match_hostname method, with rules from RFC 2818 (that is, tailored for HTTPS). Review welcome.

----------
keywords: +patch
stage:  -> patch review
Added file: http://bugs.python.org/file19128/sslcheck.patch

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

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


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

PEP 3101 has the following

"""
    Implementation note: The implementation of this proposal is
    not required to enforce the rule about a simple or dotted name
    being a valid Python identifier.  Instead, it will rely on the
    getattr function of the underlying object to throw an exception if
    the identifier is not legal.  The str.format() function will have
    a minimalist parser which only attempts to figure out when it is
    "done" with an identifier (by finding a '.' or a ']', or '}',
    etc.).
"""

Apparently CPython takes advantage of this note in its implementation.  Thus this is not a bug, but I think this implementation note should be added to CPython documentation.

----------

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

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


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


----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python

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

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


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


----------
nosy: +eric.smith, mark.dickinson

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

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


Eric Smith <eric at trueblade.com> added the comment:

Right. It seemed like a hassle to have the str.format parser try to figure out what a valid identifier is, so it just passes it through.

I don't see this as any different from:

>>> class X:
...    def __getattribute__(self, a): return 'foo'
... 
>>> getattr(X(), '$#@')
'foo'

----------

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

From report at bugs.python.org  Mon Oct  4 18:58:47 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 04 Oct 2010 16:58:47 +0000
Subject: [issue10021] Format parser is too permissive
In-Reply-To: <1286211282.49.0.727238009224.issue10021@psf.upfronthosting.co.za>
Message-ID: <AANLkTin4CAr-C1FRv-JUTZ-2rqbMvwM0Ni0G0pcE1xe=@mail.gmail.com>


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

2010/10/4 Eric Smith <report at bugs.python.org>:
>
> Eric Smith <eric at trueblade.com> added the comment:
>
> Right. It seemed like a hassle to have the str.format parser try to figure out what a valid identifier is, so it just passes it through.

You can always use "str.isidentifier()" (I don't remember if there's a capi).

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

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

From report at bugs.python.org  Mon Oct  4 19:02:58 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 04 Oct 2010 17:02:58 +0000
Subject: [issue10021] Format parser is too permissive
In-Reply-To: <1286209446.65.0.698670214161.issue10021@psf.upfronthosting.co.za>
Message-ID: <1286211778.53.0.0157490166428.issue10021@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Ah, but I don't need to in order to comply with the PEP!

----------

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

From report at bugs.python.org  Mon Oct  4 19:08:46 2010
From: report at bugs.python.org (Devin Cook)
Date: Mon, 04 Oct 2010 17:08:46 +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: <1286212126.76.0.64007303154.issue1589@psf.upfronthosting.co.za>


Devin Cook <devin.c.cook at gmail.com> added the comment:

I think it looks good except for the wildcard checking. According to the latest draft of that TLS id-checking RFC, you aren't supposed to allow the wildcard as part of a fragment. Of course this contradicts RFC 2818.

http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-09#section-4.4.3

If this gets accepted, I'll submit a patch to http.client and urllib that makes use of it.

----------

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

From report at bugs.python.org  Mon Oct  4 19:10:35 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 04 Oct 2010 17:10:35 +0000
Subject: [issue10021] Format parser is too permissive
In-Reply-To: <1286211778.53.0.0157490166428.issue10021@psf.upfronthosting.co.za>
Message-ID: <AANLkTiny01DCL4BVDG=js+zux3VJU-UdC0cBS+fr35ZO@mail.gmail.com>


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

On Mon, Oct 4, 2010 at 1:02 PM, Eric Smith <report at bugs.python.org> wrote:
..
> Ah, but I don't need to in order to comply with the PEP!

This is true and this is the reason I changed this issue from bug to
doc.   I seem to remember this having been discussed before, but I
cannot find the right thread.   There are at least two reasons cpython
docs should mention this:

1. From current documentation, users are likely to expect a value
error from format(".$#@", ..) rather than an attribute error.
2. Naive proxy objects may implement __getattribute__ that blindly
inserts attribute name into database queries leading to all kinds of
undesired behaviors.

----------

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

From report at bugs.python.org  Mon Oct  4 19:19:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 17:19:59 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1286212126.76.0.64007303154.issue1589@psf.upfronthosting.co.za>
Message-ID: <1286212791.3178.51.camel@localhost.localdomain>


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

> I think it looks good except for the wildcard checking. According to
> the latest draft of that TLS id-checking RFC, you aren't supposed to
> allow the wildcard as part of a fragment. Of course this contradicts
> RFC 2818.

Well, since it is then an "error" (according to the id-checking draft)
in the certificate itself rather than the hostname we are trying to
match, it seems there would be no real issue in accepting the match
anyway. It's up to CAs to make sure that certificates conform to
whatever standard is currently in effect.

I'm also assuming RFC 2818 is in wider use than the id-checking draft;
am I wrong?

----------

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

From report at bugs.python.org  Mon Oct  4 19:37:28 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 04 Oct 2010 17:37:28 +0000
Subject: [issue10021] Format parser is too permissive
In-Reply-To: <1286209446.65.0.698670214161.issue10021@psf.upfronthosting.co.za>
Message-ID: <1286213848.48.0.64883231003.issue10021@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree it should be documented as a CPython specific behavior. I should also add a CPython specific test for it, modeled on your code (if one doesn't already exist). I'll look into it.

----------

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

From report at bugs.python.org  Mon Oct  4 19:39:44 2010
From: report at bugs.python.org (Devin Cook)
Date: Mon, 04 Oct 2010 17:39:44 +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: <1286213984.46.0.127613201159.issue1589@psf.upfronthosting.co.za>


Devin Cook <devin.c.cook at gmail.com> added the comment:

> I'm also assuming RFC 2818 is in wider use than the id-checking draft;
> am I wrong?

Yeah, since RFC 2818 has been accepted since 2000 and the id-checking draft was started in 2009, I'd say it's a safe bet. I'm in no way authoritative though.

----------

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

From report at bugs.python.org  Mon Oct  4 19:45:59 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 04 Oct 2010 17:45:59 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1286214359.01.0.480284435115.issue5088@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi ?ric,
thanks a lot for your review. Your comments are just fine, so I'm attaching a new patch that contains them.

Yes, it's really nice to see one's work being accepted, and I do recognize I have a lot to learn about python procedures (either written or not :) so be sure I won't be demotivated by some initial "problems".

About the Debian-Python relationship, I have absolutely no control over interpreters packages in Debian, but I do care so much about Python that I thought giving my hand here would be quite right (and who knows, maybe one day, I'll be a core developer too :) .

Cheers,
Sandro

----------
Added file: http://bugs.python.org/file19129/issue5088-py3k-v2.patch

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

From report at bugs.python.org  Mon Oct  4 19:47:53 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 04 Oct 2010 17:47:53 +0000
Subject: [issue5501] Update multiprocessing docs re: freeze_support
In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>
Message-ID: <1286214473.23.0.326211617882.issue5501@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Sorry ?ric, I don't get it: do you mean that the fact that "freeze_support() can be called without issues on Unix or OS X" is a new feature? or I misread it completely?

----------

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

From report at bugs.python.org  Mon Oct  4 20:13:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Oct 2010 18:13:47 +0000
Subject: [issue5501] Update multiprocessing docs re: freeze_support
In-Reply-To: <1237312904.73.0.910184118935.issue5501@psf.upfronthosting.co.za>
Message-ID: <1286216027.85.0.985536933467.issue5501@psf.upfronthosting.co.za>


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

Rephrased: Is this relevant for 3.1?

(Bug and doc fixes go into 3.2, 3.1 and 2.7, but here only 3.2 and 2.7 are selected, so I asked if the bugfix/new feature/behavior in question was something new in 3.2 and thus not in 3.1.)

----------

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

From report at bugs.python.org  Mon Oct  4 20:15:23 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 04 Oct 2010 18:15:23 +0000
Subject: [issue9093] Tools/README is out of date
In-Reply-To: <1277658495.23.0.15994230675.issue9093@psf.upfronthosting.co.za>
Message-ID: <1286216123.63.0.99540236541.issue9093@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello Georg,
is this bug been fixed with r83608-10 ? from the commit diffs it seems so, but maybe there's something else you want to do.

Regards,
Sandro

----------
nosy: +sandro.tosi

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

From report at bugs.python.org  Mon Oct  4 20:18:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Oct 2010 18:18:46 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1286216326.97.0.601251057396.issue5088@psf.upfronthosting.co.za>


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

Forgot this one:

> `appended`
I don?t remember the default reST role being used in the Python docs; I don?t even remember what it is.  Your example makes me suspect emphasis, so using *appended* would do the same thing and be explicit.

> contrary to what one can think
Still not a native speaker, but wouldn?t ?may think? be more suited here?

Apart from that, +1.

----------

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

From report at bugs.python.org  Mon Oct  4 20:26:41 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 04 Oct 2010 18:26:41 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1286216326.97.0.601251057396.issue5088@psf.upfronthosting.co.za>
Message-ID: <AANLkTik8y-XjEfaredWYZ6Uh2Jf3E7VZUQ2Mh5MzfXo_@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Mon, Oct 4, 2010 at 20:18, ?ric Araujo <report at bugs.python.org> wrote:
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Forgot this one:
>
>> `appended`
> I don?t remember the default reST role being used in the Python docs; I don?t even remember what it is. ?Your example makes me suspect emphasis, so using *appended* would do the same thing and be explicit.

I think I looked in other part of the optparse.rst file how it's done
and used that, but I'm fine either ways.

>> contrary to what one can think
> Still not a native speaker, but wouldn?t ?may think? be more suited here?

ah ok, it might me more correct, dunno (not native too)

> Apart from that, +1.

Thanks! but what should I do: prepare a new patch with this 2 quite
little changes or leave that to the committer?

Regards,
Sandro

----------

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

From report at bugs.python.org  Mon Oct  4 20:37:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Oct 2010 18:37:57 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1286217477.65.0.664276720255.issue5088@psf.upfronthosting.co.za>


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

> I think I looked in other part of the optparse.rst file how it's done
and used that
Alright, let?s leave it alone then.

>>> contrary to what one can think
>> Still not a native speaker, but wouldn?t ?may think? be more suited here?
>ah ok, it might me more correct, dunno (not native too)
It has to do with the degree of probability you assign to the thought.

Unless someone adds something, I?ll commit your patch in some days.  I?ll change ?can?, don?t bother doing another patch.

----------

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

From report at bugs.python.org  Mon Oct  4 20:38:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 04 Oct 2010 18:38:10 +0000
Subject: [issue5088] optparse: inconsistent default value for append actions
In-Reply-To: <1233140307.53.0.685208172708.issue5088@psf.upfronthosting.co.za>
Message-ID: <1286217490.98.0.204205045305.issue5088@psf.upfronthosting.co.za>


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


----------
resolution:  -> accepted
status: open -> pending

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

From report at bugs.python.org  Mon Oct  4 22:10:48 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Oct 2010 20:10:48 +0000
Subject: [issue9800] Fast path for small int-indexing of lists and tuples
In-Reply-To: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>
Message-ID: <1286223048.44.0.980829696705.issue9800@psf.upfronthosting.co.za>


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

At any rate, I believe this used to be a fast-path.  IIRC, Aahz put it in after demonstrating a considerable speed boost for common cases.  Aahz, do you have any institutional memory around this one?

----------
nosy: +aahz

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

From report at bugs.python.org  Mon Oct  4 23:09:59 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 04 Oct 2010 21:09:59 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1286226599.23.0.456790647435.issue6706@psf.upfronthosting.co.za>


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

Python 3.2 changes committed in r85220.
Still have to commit EWOULDBLOCK/ECONNABORTED changes for 3.1 and 2.7.

----------

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

From report at bugs.python.org  Mon Oct  4 23:22:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 21:22:05 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1286227325.25.0.110700469933.issue9935@psf.upfronthosting.co.za>


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

Alexandre, do you have opinion on this?

----------

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

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


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

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

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

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

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


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

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

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

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

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

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

From report at bugs.python.org  Mon Oct  4 23:50:31 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 04 Oct 2010 21:50:31 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1286229031.65.0.527072643951.issue1731717@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

A workaround for those still having problems with this:

 stub out subprocess._cleanup with a no-op method.

It it only useful if your app is ever using subprocess and forgetting to call wait() on Popen objects before they are deleted.  If you are, you can keep a reference to the old _cleanup() method and periodically call it on your own.

http://bugs.python.org/issue1236 effectively demonstrates this.

----------

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

From report at bugs.python.org  Mon Oct  4 23:55:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 04 Oct 2010 21:55:57 +0000
Subject: [issue9962] GzipFile doesn't have peek()
In-Reply-To: <1285623515.75.0.317234760361.issue9962@psf.upfronthosting.co.za>
Message-ID: <1286229357.26.0.550316563769.issue9962@psf.upfronthosting.co.za>


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

I've committed the improvements in r85221. Thank you!

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

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

From report at bugs.python.org  Tue Oct  5 00:47:23 2010
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 04 Oct 2010 22:47:23 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1286232443.49.0.950820732208.issue9935@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Sorry Antoine, I have been busy with school work lately.

I like the general idea and I will try to look at your patch ASAP.

----------

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

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


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

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

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

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

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

hash('1pov')
-747753952

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

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

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

From report at bugs.python.org  Tue Oct  5 02:01:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 05 Oct 2010 00:01:28 +0000
Subject: [issue9042] Gettext cache and classes
In-Reply-To: <1277126619.45.0.50898561177.issue9042@psf.upfronthosting.co.za>
Message-ID: <1286236888.8.0.711329373004.issue9042@psf.upfronthosting.co.za>


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

Committed in r85223, r85224, r85225 (resp. 3.2, 3.1, 2.7).  Thanks again!

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

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

From report at bugs.python.org  Tue Oct  5 02:01:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Oct 2010 00:01:39 +0000
Subject: [issue10025] random.seed not initialized as advertised
In-Reply-To: <1286235186.65.0.07824350342.issue10025@psf.upfronthosting.co.za>
Message-ID: <1286236899.0.0.703853542271.issue10025@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Oct  5 04:32:40 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Oct 2010 02:32:40 +0000
Subject: [issue10025] random.seed not initialized as advertised
In-Reply-To: <1286235186.65.0.07824350342.issue10025@psf.upfronthosting.co.za>
Message-ID: <1286245960.38.0.678683515459.issue10025@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/issue10025>
_______________________________________

From report at bugs.python.org  Tue Oct  5 05:00:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Oct 2010 03:00:41 +0000
Subject: [issue1104021] wishlist: os.feed_urandom(input)
Message-ID: <1286247641.98.0.532153944604.issue1104021@psf.upfronthosting.co.za>


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


----------
nosy:  -BreamoreBoy
resolution: out of date -> 

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

From report at bugs.python.org  Tue Oct  5 05:15:52 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Oct 2010 03:15:52 +0000
Subject: [issue1104021] wishlist: os.feed_urandom(input)
Message-ID: <1286248552.9.0.0661297416099.issue1104021@psf.upfronthosting.co.za>


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


----------
resolution:  -> rejected

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

From report at bugs.python.org  Tue Oct  5 05:32:44 2010
From: report at bugs.python.org (Tony Meyer)
Date: Tue, 05 Oct 2010 03:32:44 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286249564.74.0.840466418087.issue4661@psf.upfronthosting.co.za>


Changes by Tony Meyer <anadelonbrin at users.sourceforge.net>:


----------
nosy: +anadelonbrin

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

From report at bugs.python.org  Tue Oct  5 06:50:25 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 05 Oct 2010 04:50:25 +0000
Subject: [issue9978] Better wait for slow machine in test_os (_kill_with_event)
In-Reply-To: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>
Message-ID: <1286254225.36.0.430537900937.issue9978@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
title: test_os failures on XP-4 buildbot -> Better wait for slow machine in test_os (_kill_with_event)

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

From report at bugs.python.org  Tue Oct  5 07:04:43 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Oct 2010 05:04:43 +0000
Subject: [issue9899] tkinter test_font fails on OS X with Aqua Tk
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1286255083.91.0.987586470982.issue9899@psf.upfronthosting.co.za>


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

After further investigation, on OS X at least, there is a difference in behavior between Tk 8.4 (the system default on OS X 10.4 and 10.5) and Tk 8.5 (the default on 10.6).  Lib/tkinter/font.py calls the Tk "font names" commands to check whether a font is already defined.  At the point where test_font.py is initially run, there has not been any real Tk activity yet.  For some reason, with 8.5 the system font names are returned; with 8.4 they are not:

$ /usr/bin/wish8.4
% font names
$ /usr/bin/wish8.5
% font names
systemPushButtonFont systemMenuItemFont systemApplicationFont systemSystemFont systemMenuItemMarkFont TkMenuFont TkDefaultFont systemSmallEmphasizedSystemFont systemDetailEmphasizedSystemFont systemMiniSystemFont TkHeadingFont TkTooltipFont systemUtilityWindowTitleFont systemViewsFont systemSmallSystemFont systemMenuTitleFont systemEmphasizedSystemFont TkTextFont systemDetailSystemFont TkCaptionFont systemLabelFont systemAlertHeaderFont systemMenuItemCmdKeyFont TkSmallCaptionFont TkFixedFont systemWindowTitleFont systemToolbarFont TkIconFont

So, a solution for that is to add a try block in test_font.py to create a font definition for TkDefaultFont if it does not already exist.  (Presumably, after the test failed and before it was re-run, other tests ran which caused the fonts to be defined so it passes.)  This time I have tested it with both Tk 8.4 and 8.5 on OS X 10.5 and 10.6.  Additional patch file attached (to be applied on top of the already applied first patch).

----------
assignee: ned.deily -> 
resolution: fixed -> accepted
stage: committed/rejected -> patch review
Added file: http://bugs.python.org/file19130/issue9899-fix1-py3k.patch

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

From report at bugs.python.org  Tue Oct  5 08:42:17 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Oct 2010 06:42:17 +0000
Subject: [issue9907] interactive mode TAB does not insert on OS X built with
	editline instead of GNU readline
In-Reply-To: <1285018607.7.0.0427821796342.issue9907@psf.upfronthosting.co.za>
Message-ID: <1286260937.49.0.808426581911.issue9907@psf.upfronthosting.co.za>


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

The modified patch looks OK to me and tests OK.  The rl_read_init_file call seems like a reasonable thing for users who are used to using libedit's .editrc.  As a practical matter, though, I think the only thing that would be affected is an .editrc TAB binding.  Some of the initializations done in Modules/readline.c, like rl_bind_key_in_map (for sure) and rl_completer_word_break_characters are silently ignored by the libedit readline-compatibility layer; it does not implement features like the emacs_meta_keymap.

----------

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

From report at bugs.python.org  Tue Oct  5 09:21:55 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Oct 2010 07:21:55 +0000
Subject: [issue10021] Format parser is too permissive
In-Reply-To: <1286209446.65.0.698670214161.issue10021@psf.upfronthosting.co.za>
Message-ID: <1286263315.71.0.650569429119.issue10021@psf.upfronthosting.co.za>


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

> I seem to remember this having been discussed before, but I
cannot find the right thread.

It came up in the issue 7951 discussion, I think.

----------

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

From report at bugs.python.org  Tue Oct  5 09:23:25 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 05 Oct 2010 07:23:25 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1286263405.02.0.337888652189.issue9980@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Oct  5 09:32:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 05 Oct 2010 07:32:05 +0000
Subject: [issue9873] urllib.parse: Allow bytes in some APIs that use string
	literals internally
In-Reply-To: <1286109884.3111.16.camel@localhost.localdomain>
Message-ID: <201010050931.54349.victor.stinner@haypocalc.com>


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

> If you were worried about performance, then surrogateescape is certainly
> much slower than latin1.

If you were really worried about performance, the bytes type is maybe faster 
than: decode bytes to str using latin-1, process str strings, encode str to 
bytes using latin-1.

----------

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

From report at bugs.python.org  Tue Oct  5 09:45:12 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 05 Oct 2010 07:45:12 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1286264712.0.0.729385569597.issue8445@psf.upfronthosting.co.za>


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

The test_heading_callback failure appears to be another Tk 8.4 vs Tk 8.5 problem.  Datapoints: the test fails using the Apple-supplied Tk 8.4 in OS X 10.6 and with a recent ActiveState Aqua Tk 8.4 on OS X 10.5; the test succeeds with the Apple-supplied Tk 8.5 in OS X 10.6.

----------
nosy: +ned.deily

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

From report at bugs.python.org  Tue Oct  5 10:24:07 2010
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 05 Oct 2010 08:24:07 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1286267047.79.0.914220362337.issue7330@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

I update the patch. Hope somebody could do a review.

----------
Added file: http://bugs.python.org/file19131/issue_7330.diff

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

From report at bugs.python.org  Tue Oct  5 10:24:58 2010
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 05 Oct 2010 08:24:58 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1286267098.16.0.13973626015.issue7330@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

I update the patch. Hope somebody could do a review.

----------
Added file: http://bugs.python.org/file19132/issue_7330.diff

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

From report at bugs.python.org  Tue Oct  5 10:26:16 2010
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 05 Oct 2010 08:26:16 +0000
Subject: [issue7330] PyUnicode_FromFormat segfault
In-Reply-To: <1258314153.95.0.978747695294.issue7330@psf.upfronthosting.co.za>
Message-ID: <1286267176.31.0.631761328855.issue7330@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Oooops! Sorry for re-submit the request...

----------

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

From report at bugs.python.org  Tue Oct  5 10:33:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 05 Oct 2010 08:33:54 +0000
Subject: [issue10024] Outdated advice in C-API tutorial?
In-Reply-To: <1286228751.32.0.127029935422.issue10024@psf.upfronthosting.co.za>
Message-ID: <1286267634.34.0.605380449998.issue10024@psf.upfronthosting.co.za>


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

The advice is still necessary, AFAIK. The issue is Windows, in particular producing function pointers across DLL boundaries. In Python core, this is not an issue, since the references will all be inside pythonXY.dll.

----------

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

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


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

Hi,

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

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

And run simply program for printing content of element section:

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

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

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


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

Thanks for any advice
Vojta Rylko

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

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

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

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

From report at bugs.python.org  Tue Oct  5 12:32:20 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Oct 2010 10:32:20 +0000
Subject: [issue9873] urllib.parse: Allow bytes in some APIs that use string
	literals internally
In-Reply-To: <201010050931.54349.victor.stinner@haypocalc.com>
Message-ID: <AANLkTin2f-+DZGai3mBcH7f7DX-iPet6BpqSJrC42082@mail.gmail.com>


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

On Tue, Oct 5, 2010 at 5:32 PM, STINNER Victor <report at bugs.python.org> wrote:
>
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
>
>> If you were worried about performance, then surrogateescape is certainly
>> much slower than latin1.
>
> If you were really worried about performance, the bytes type is maybe faster
> than: decode bytes to str using latin-1, process str strings, encode str to
> bytes using latin-1.

I'm fairly resigned to the fact that I'm going to need some kind of
micro-benchmark to compare the different approaches. For example, the
bytes based approach has a lot of extra assignments to local variables
that the str based approach doesn't need.

The first step is to actually have a str-based patch to compare to the
existing bytes based patch. If the code ends up significantly clearer
(as I expect it will), we can probably sacrifice a certain amount of
speed for that benefit.

----------

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

From report at bugs.python.org  Tue Oct  5 13:01:11 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 05 Oct 2010 11:01:11 +0000
Subject: [issue9873] urllib.parse: Allow bytes in some APIs that use string
	literals internally
In-Reply-To: <AANLkTin2f-+DZGai3mBcH7f7DX-iPet6BpqSJrC42082@mail.gmail.com>
Message-ID: <20101005110057.GA15396@remy>


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

I wonder if Option2 (ascii+surrogateescape vs latin1) is only about
performance. How about escapes that might occur if the Option2 is
adopted. That might take higher priority than performance.
Do we know 'how tight' that approach is?

----------

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

From report at bugs.python.org  Tue Oct  5 13:08:39 2010
From: report at bugs.python.org (Nils Philippsen)
Date: Tue, 05 Oct 2010 11:08:39 +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: <1286276919.16.0.389403636227.issue6011@psf.upfronthosting.co.za>


Changes by Nils Philippsen <nils at redhat.com>:


----------
nosy: +nils

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

From report at bugs.python.org  Tue Oct  5 13:16:19 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 05 Oct 2010 11:16:19 +0000
Subject: [issue10026] xml.dom.pulldom strange behavior
In-Reply-To: <1286273854.3.0.24375174829.issue10026@psf.upfronthosting.co.za>
Message-ID: <1286277379.34.0.859500575236.issue10026@psf.upfronthosting.co.za>


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

Please read
http://docs.python.org/library/xml.etree.elementtree.html?highlight=elementtree#xml.etree.ElementTree.iterparse
At START_ELEMENT, the element is not guaranteed to be fully populated;
you should handle the END_ELEMENT event instead.

This should be documented for the pulldom module as well, though.

----------
assignee:  -> docs at python
nosy: +amaury.forgeotdarc, docs at python

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

From report at bugs.python.org  Tue Oct  5 13:25:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Oct 2010 11:25:27 +0000
Subject: [issue9899] tkinter test_font fails on OS X with Aqua Tk
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1286277927.13.0.311706716388.issue9899@psf.upfronthosting.co.za>


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

I've committed the patch in r85229. Let's see if this makes the buildbots happy.

----------

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

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


Vojt?ch Rylko <vojta.rylko at seznam.cz> added the comment:

Program below also splits two of 10 000 elements into two rows. Is it acceptable behavior?

OUTPUT (ill part)
=============
<DOM Text node "u'Twitter'">
<DOM Text node "u'\n'">
<DOM Text node "u'Twi'">
<DOM Text node "u'tter'">
<DOM Text node "u'\n'">
<DOM Text node "u'Twitter'">
<DOM Text node "u'\n'">
<DOM Text node "u'Twitter'">


PROGRAM
=============
for event, node in events:
        if event == pulldom.CHARACTERS:
                print node.data

----------

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

From report at bugs.python.org  Tue Oct  5 14:16:22 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Tue, 05 Oct 2010 12:16:22 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1286280982.86.0.165069384498.issue7980@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

Attribute error confirmed on OSX, and py3k.

http://codereview.appspot.com/2371041

----------
keywords: +patch
Added file: http://bugs.python.org/file19133/issue7980.patch

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

From report at bugs.python.org  Tue Oct  5 14:23:34 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Tue, 05 Oct 2010 12:23:34 +0000
Subject: [issue9012] Separate compilation of time and datetime modules
In-Reply-To: <1276703214.18.0.763658156575.issue9012@psf.upfronthosting.co.za>
Message-ID: <1286281414.3.0.996114637385.issue9012@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/issue9012>
_______________________________________

From report at bugs.python.org  Tue Oct  5 14:41:08 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 05 Oct 2010 12:41:08 +0000
Subject: [issue10026] xml.dom.pulldom strange behavior
In-Reply-To: <1286273854.3.0.24375174829.issue10026@psf.upfronthosting.co.za>
Message-ID: <1286282468.37.0.322079216796.issue10026@psf.upfronthosting.co.za>


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

Yes, sax parsers may split CHARACTER events. See also the discussion:
http://www.mail-archive.com/xml-sig at python.org/msg00234.html

Again, the END_ELEMENT event is guaranteed to return the complete node.

----------

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

From report at bugs.python.org  Tue Oct  5 14:43:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Oct 2010 12:43:17 +0000
Subject: [issue9899] tkinter test_font fails on OS X with Aqua Tk
In-Reply-To: <1284928979.9.0.717353739827.issue9899@psf.upfronthosting.co.za>
Message-ID: <1286282597.63.0.700849648687.issue9899@psf.upfronthosting.co.za>


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

Looks alright, thank you!

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

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

From report at bugs.python.org  Tue Oct  5 15:23:16 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 05 Oct 2010 13:23:16 +0000
Subject: [issue9978] Better wait for slow machine in test_os (_kill_with_event)
In-Reply-To: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>
Message-ID: <1286284996.03.0.329344904413.issue9978@psf.upfronthosting.co.za>


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

In that case, the patch seems alright to me.

----------
versions: +Python 2.7

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

From report at bugs.python.org  Tue Oct  5 15:57:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 05 Oct 2010 13:57:48 +0000
Subject: [issue10021] Format parser is too permissive
In-Reply-To: <1286209446.65.0.698670214161.issue10021@psf.upfronthosting.co.za>
Message-ID: <1286287068.37.0.181484689621.issue10021@psf.upfronthosting.co.za>


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

This should not be classified as an "implementation detail". Either we should document it and cause other implementations to support it or check it ourselves.

----------

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

From report at bugs.python.org  Tue Oct  5 16:32:02 2010
From: report at bugs.python.org (Aahz)
Date: Tue, 05 Oct 2010 14:32:02 +0000
Subject: [issue9800] Fast path for small int-indexing of lists and tuples
In-Reply-To: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>
Message-ID: <1286289122.56.0.112547679124.issue9800@psf.upfronthosting.co.za>


Aahz <aahz at pythoncraft.com> added the comment:

Wasn't me!  And I've spent too little time on python-dev lately to
remember stuff like this.  :-(

----------
nosy: +Aahz

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

From report at bugs.python.org  Tue Oct  5 16:32:47 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 05 Oct 2010 14:32:47 +0000
Subject: [issue10021] Format parser is too permissive
In-Reply-To: <1286209446.65.0.698670214161.issue10021@psf.upfronthosting.co.za>
Message-ID: <1286289167.85.0.640694408537.issue10021@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I agree that it being an implementation detail is not a good thing. I think we should just document the current CPython behavior as the language standard: once parsed, any string after a dot is passed to getattr. I can't see why we should pay the penalty of validating it as an identifier when the behavior is well defined and matches my getattr example in msg 117965.

----------

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

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


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

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

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

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

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

From report at bugs.python.org  Tue Oct  5 16:39:46 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 05 Oct 2010 14:39:46 +0000
Subject: [issue8879] Implement os.link on Windows
In-Reply-To: <1275504458.06.0.136411734773.issue8879@psf.upfronthosting.co.za>
Message-ID: <1286289586.53.0.188530617528.issue8879@psf.upfronthosting.co.za>


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

I created #10027 for the st_nlink issue to handle it separately.

----------
dependencies: +os.lstat/os.stat don't set st_nlink on Windows

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

From report at bugs.python.org  Tue Oct  5 16:51:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 05 Oct 2010 14:51:09 +0000
Subject: [issue9800] Fast path for small int-indexing of lists and tuples
In-Reply-To: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>
Message-ID: <1286290269.83.0.245940939312.issue9800@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

I did some spelunking.  Guido committed the similar optimization in r8306.    The diff is at:
http://svn.python.org/view/python/trunk/Python/ceval.c?r1=8087&r2=8306

His commit message was:

    Huge speedup by inlining some common integer operations:
    int+int, int-int, int <compareop> int, and list[int].
    (Unfortunately, int*int is way too much code to inline.)

    Also corrected a NULL that should have been a zero.

It's possible that these kinds of optimizations were worthwhile with PyInt but aren't worthwhile with PyLong.

They were taken out by MvL in r59334, with a commit message of:

    Remove special-casing of integer operations, to stop
    using PyInt_CheckExact.

----------

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

From report at bugs.python.org  Tue Oct  5 17:03:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Oct 2010 15:03:11 +0000
Subject: [issue9800] Fast path for small int-indexing of lists and tuples
In-Reply-To: <1286290269.83.0.245940939312.issue9800@psf.upfronthosting.co.za>
Message-ID: <1286290985.3399.2.camel@localhost.localdomain>


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

> I did some spelunking.  Guido committed the similar optimization in r8306.    The diff is at:
> http://svn.python.org/view/python/trunk/Python/ceval.c?r1=8087&r2=8306
> 
> His commit message was:
> 
>     Huge speedup by inlining some common integer operations:
>     int+int, int-int, int <compareop> int, and list[int].
>     (Unfortunately, int*int is way too much code to inline.)
> 
>     Also corrected a NULL that should have been a zero.
> 
> It's possible that these kinds of optimizations were worthwhile with
> PyInt but aren't worthwhile with PyLong.

It also doesn't say the individual contribution of each optimization,
and it also doesn't say on which kind of workloads the "huge speedup"
was witnessed (I would say that pystone is a possibility, or perhaps
even some timeit micro-benchmark).

----------

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

From report at bugs.python.org  Tue Oct  5 17:09:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 05 Oct 2010 15:09:42 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1286291382.78.0.939302923308.issue7980@psf.upfronthosting.co.za>


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


----------
nosy: +belopolsky
stage: unit test needed -> needs patch

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

From report at bugs.python.org  Tue Oct  5 17:09:52 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 05 Oct 2010 15:09: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: <1286291392.36.0.474845378736.issue8028@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Could you please reduce this to the shorted possible example that reproduces the problem?

----------
nosy: +asksol

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

From report at bugs.python.org  Tue Oct  5 17:11:50 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 05 Oct 2010 15:11:50 +0000
Subject: [issue8094] Multiprocessing infinite loop
In-Reply-To: <1268125314.35.0.202558750367.issue8094@psf.upfronthosting.co.za>
Message-ID: <1286291510.33.0.978852622032.issue8094@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/issue8094>
_______________________________________

From report at bugs.python.org  Tue Oct  5 17:13:24 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 05 Oct 2010 15:13:24 +0000
Subject: [issue8144] muliprocessing shutdown infinite loop
In-Reply-To: <1268617866.73.0.54561408378.issue8144@psf.upfronthosting.co.za>
Message-ID: <1286291604.57.0.699092580686.issue8144@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Did you finish the code to reproduce the problem?

----------
nosy: +asksol

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

From report at bugs.python.org  Tue Oct  5 17:22:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 05 Oct 2010 15:22:28 +0000
Subject: [issue5672] Implement a way to change the python process name
In-Reply-To: <1238701084.1.0.0781987214897.issue5672@psf.upfronthosting.co.za>
Message-ID: <1286292148.31.0.33200971862.issue5672@psf.upfronthosting.co.za>


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

I'd rather not reopen this issue. It was too far-ranging, and has failed to get a specific solution. Please stop posting to this closed issue; if you want to contribute, please open a new one.

I think the inclusion of the module should see a discussion on python-dev first. It then also needs to be code-reviewed, which in turn needs a committer who either volunteers to do all this work, or who is willing to take the recommendation of some other reviewer.

My shallow review of the module is I would prefer to see the code structure revised. For example, c.h should go, spt_config.h should be integrated with autoconf, strlpcpy.c should go, spt_setup.c should go (IIUC) - IOW, this would need to be reformulated as a patch to the Python source tree. Of course, I can understand if Daniele would only start doing so if there was a chance that the functionality and approach is actually acceptable.

----------

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

From report at bugs.python.org  Tue Oct  5 18:34:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Oct 2010 16:34:52 +0000
Subject: [issue845560] imaplib: traceback from _checkquote with empty string
Message-ID: <1286296492.95.0.602951852398.issue845560@psf.upfronthosting.co.za>


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

The example works fine for me (server returns mailbox does not exist) in both 2.7 and py3k trunk, so I'm closing this as out of date.

----------
nosy: +r.david.murray -BreamoreBoy
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed

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

From report at bugs.python.org  Tue Oct  5 18:51:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Oct 2010 16:51:11 +0000
Subject: [issue9936] trace misreports "missing" lines
In-Reply-To: <1285296955.25.0.310844622187.issue9936@psf.upfronthosting.co.za>
Message-ID: <1286297471.3.0.376024004404.issue9936@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/issue9936>
_______________________________________

From report at bugs.python.org  Tue Oct  5 18:59:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Oct 2010 16:59:19 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
	as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1286297959.57.0.773916544612.issue9325@psf.upfronthosting.co.za>


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

I am afraid, for ordinary scripts these modules effectively use option 3.  I think these modules should remove its own scaffolding from "real" __main__ before loading any traced code.  I am not sure how this can be achieved, though.

----------

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

From report at bugs.python.org  Tue Oct  5 19:10:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Oct 2010 17:10:29 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1286298629.54.0.243614538367.issue7980@psf.upfronthosting.co.za>


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

MunSic,

It looks like issue7980.patch is just a unit test.  Do you have a patch to fix the issue?

----------

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

From report at bugs.python.org  Tue Oct  5 19:16:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Oct 2010 17:16:08 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1286298968.45.0.281585813208.issue7980@psf.upfronthosting.co.za>


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

RDM> FYI there's been a proposal to create a time.py module anyway
RDM> in order to add some pure python functions not worth writing in c.
RDM> For reference, it's issue 7989.

Issue #7989 was retargeted to deal with datetime module.  The time.py issue is #9528.

----------

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

From report at bugs.python.org  Tue Oct  5 19:32:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Oct 2010 17:32:20 +0000
Subject: [issue9079] Make gettimeofday available in time module
In-Reply-To: <1277427154.32.0.0996770896527.issue9079@psf.upfronthosting.co.za>
Message-ID: <1286299940.81.0.923922381813.issue9079@psf.upfronthosting.co.za>


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


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

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

From report at bugs.python.org  Tue Oct  5 19:35:34 2010
From: report at bugs.python.org (Jonathan Niehof)
Date: Tue, 05 Oct 2010 17:35:34 +0000
Subject: [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>
Message-ID: <1286300134.26.0.428702498637.issue9991@psf.upfronthosting.co.za>


Changes by Jonathan Niehof <jniehof at lanl.gov>:


----------
nosy: +Jelly.Chen, lister171254

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

From report at bugs.python.org  Tue Oct  5 19:52:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Oct 2010 17:52:26 +0000
Subject: [issue9528] Add pure Python implementation of time module to CPython
In-Reply-To: <1281666364.27.0.384776817221.issue9528@psf.upfronthosting.co.za>
Message-ID: <AANLkTinP6WUKAxnnHKTwyx4nyq_yeKqOak-BA5_fXDtT@mail.gmail.com>


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

On Thu, Aug 12, 2010 at 10:26 PM, STINNER Victor <report at bugs.python.org> wrote:
..
>> 1. Datetime.py time source (time.time()) represents time as
>> a floating point number which leads to system dependent behavior
>> and introduces floating point operations where they are not needed.
>
> Why not introducing a new function in time module? Other people may benefit from this.
>
I agree.  See issue 9079.

We can do that.  I'll experiment with this approach within issue 9527.

>> 4. No changes will be done to timemodule.c other than renaming
>
> What about time_strftime()? It is 170 lines long: will it be moved to _basictime.c? You have to keep
> the code filling the "struct tm" structure in (_)timemodule.c.

No, I don't want  time_strftime in _basictime.  I want
datetime_strftime to be independently implemented and freed of legacy
restrictions on the year range.   The _basictime module should include
a very simple wrapper around system strftime if we want to keep using
it in datetime.py, but it would be best to have complete pure python
implementation of both strftime and strptime.

----------

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

From report at bugs.python.org  Tue Oct  5 20:02:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Oct 2010 18:02:52 +0000
Subject: [issue7582] Use ISO timestamp in diff.py
In-Reply-To: <1261929478.18.0.289329990174.issue7582@psf.upfronthosting.co.za>
Message-ID: <1286301772.94.0.208745396677.issue7582@psf.upfronthosting.co.za>


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


----------
dependencies: +Add aware local time support to datetime module

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

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


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

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


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

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

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

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

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


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

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

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

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

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

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

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


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

The relevant comment at Stack Overflow is:

"""
It looks like it's a bug in the documentation. The 'equivalent' code working in python2, but not in python3, where it has an infinite loop.

And the latest version of the documentation has the same problem: http://docs.python.org/release/3.1.2/library/functions.html

Look like change r61361 was the problem, as it merged changes from python 2.6 without verifying that they were correct for python 3.
"""

----------
nosy: +belopolsky, loewis

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

From report at bugs.python.org  Tue Oct  5 20:38:02 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Oct 2010 18:38:02 +0000
Subject: [issue10029] bug in sample code in documentation
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286303882.24.0.63200259978.issue10029@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/issue10029>
_______________________________________

From report at bugs.python.org  Tue Oct  5 20:43:10 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Oct 2010 18:43:10 +0000
Subject: [issue10029] bug in sample code in documentation
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286304190.52.0.978183544965.issue10029@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/issue10029>
_______________________________________

From report at bugs.python.org  Tue Oct  5 20:51:58 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Tue, 05 Oct 2010 18:51:58 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286304718.38.0.0553177581032.issue10029@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

The code was taken from the itertools.izip documentation for Python 2, where it did work.

In Python 2, next() raises StopIteration which is propagated up and causes the izip() to stop.  In Python 3, map is itself a generator and the StopIteration terminates the map operation instead of terminating the zip operation.

----------
nosy: +stutzbach
resolution:  -> accepted
stage:  -> needs patch
title: bug in sample code in documentation -> "Equivalent to" code for zip is wrong in Python 3
versions: +Python 3.2

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

From report at bugs.python.org  Tue Oct  5 20:57:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Oct 2010 18:57:39 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286305059.73.0.576255335527.issue10029@psf.upfronthosting.co.za>


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

Note that the following variant where maps are replaced with list comprehensions seems to work:

def zip(*iterables):
    # zip('ABCD', 'xy') --> Ax By                                                                                                                                                      
    iterables = [iter(i) for i in iterables]
    while iterables:
	yield tuple([next(j) for j in iterables])

----------

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

From report at bugs.python.org  Tue Oct  5 21:23:38 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 05 Oct 2010 19:23:38 +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: <1286306618.7.0.101196195528.issue10027@psf.upfronthosting.co.za>


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

Overall I think this looks like a reasonable restructuring, and it works in a few manual tests of existing hardlinks on my system. Until #8879 goes in, we can't really add tests for this.

Hirokazu, do you want to commit this since you came up with it?

----------
resolution:  -> accepted

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

to:

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



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

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

to:

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

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

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

to:

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

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

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

From report at bugs.python.org  Tue Oct  5 22:45:30 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Oct 2010 20:45:30 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
	as a script
In-Reply-To: <1286297959.57.0.773916544612.issue9325@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=tj6x8P7EQth4+vBA5bBRNnkkHoMz4QrXY+RW9@mail.gmail.com>


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

On Wed, Oct 6, 2010 at 2:59 AM, Alexander Belopolsky
<report at bugs.python.org> wrote:
>
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>
> I am afraid, for ordinary scripts these modules effectively use option 3. ?I think these modules should remove its own scaffolding from "real" __main__ before loading any traced code. ?I am not sure how this can be achieved, though.

If you use runpy.run_module or runpy.run_path, they will switch the
existing __main__ out of sys.modules, replacing it with a temporary
module. However, that approach is currently slightly broken, in that
it leaves the temporary module namespace inaccessible if the module
execution fails with an exception (hence the existence of
run_module_as_main). I've thought of a few ways to fix that, but never
explored any of them:
- allow the module to be used for execution to be passed in to
run_module and run_path as a new optional parameter
- allow a list (or other mutable container) to be passed in as an
output parameter, and stick the temporary module in there
- define a thread-local variable for the runpy module that stores the
last module namespace executed via runpy in the current thread (and a
convenience API for retrieving it)

Option 2 strikes me as rather clumsy, so we can probably skip that. I
find option 3 to be quite elegant in a sys.exc_info() kind of way, but
option 1 is probably simpler.

----------

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

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


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

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

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

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

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

"""Test daemon"""

import daemon
import logging
import time
import serial
import os

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

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

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

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

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

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

it nicely opens the port.

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



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

Yours, Tjeerd

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

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

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


Changes by Tjeerd Pinkert <t.j.pinkert at alumnus.utwente.nl>:


----------
type:  -> behavior

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

From report at bugs.python.org  Tue Oct  5 23:32:11 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 05 Oct 2010 21:32:11 +0000
Subject: [issue4872] Python will not co-exist with MFC (memory leak)
In-Reply-To: <1231365332.46.0.804752973069.issue4872@psf.upfronthosting.co.za>
Message-ID: <1286314331.09.0.973000000347.issue4872@psf.upfronthosting.co.za>


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

- The "memory leaks" are reported in the IDE output window when the process exits; this lists all non deallocated blocks of memory.  This feature is not enabled by default.  Creating a CString probably initializes this feature.

- Py_Finalize() doesn't free all memory used by Py_Initialize(); this is not a problem, as long as a second call to Py_Initialize() reuses the same memory.

Closing as "won't fix": there is no need to free everything when the process exits.

----------
nosy: +amaury.forgeotdarc
resolution: invalid -> wont fix
status: pending -> closed

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

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


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

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

If i follow the documentation, the following should work.

    python -m unittest simple_test

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

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

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

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

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

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

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

From report at bugs.python.org  Wed Oct  6 00:21:54 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 05 Oct 2010 22:21:54 +0000
Subject: [issue9060] Python/dup2.c doesn't compile on (at least) newlib
In-Reply-To: <1277286692.98.0.844862215955.issue9060@psf.upfronthosting.co.za>
Message-ID: <1286317314.99.0.573832058362.issue9060@psf.upfronthosting.co.za>


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

> but Python 2.x doesn't appear to actually bother 
> to compile dup2.c even if the system lacks dup2

Is it sure? The file configure.in has the same command in both versions:
    AC_REPLACE_FUNCS(dup2 getcwd strdup)

Added the #include anyway in r85236, r85237, 85238.

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Wed Oct  6 00:28:21 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 05 Oct 2010 22:28:21 +0000
Subject: [issue9017] doctest option flag to enable/disable some chunk of
	doctests?
In-Reply-To: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>
Message-ID: <1286317701.87.0.30892818622.issue9017@psf.upfronthosting.co.za>


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

There is already doctest.SKIP. Isn't it already what you want?

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

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

From report at bugs.python.org  Wed Oct  6 00:30:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Oct 2010 22:30:20 +0000
Subject: [issue10031] Withdraw anti-recommendation of relative imports from
	documentation
In-Reply-To: <1286309891.2.0.339569302596.issue10031@psf.upfronthosting.co.za>
Message-ID: <1286317820.19.0.419972522579.issue10031@psf.upfronthosting.co.za>


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

Note that of the versions still getting doc updates, only 2.7 still supports the old style relative imports.

----------
nosy: +r.david.murray
type:  -> behavior
versions:  -Python 2.6, Python 3.3

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

From report at bugs.python.org  Wed Oct  6 00:35:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Oct 2010 22:35:57 +0000
Subject: [issue10030] Patch for zip decryption speedup
In-Reply-To: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>
Message-ID: <1286318157.25.0.316566668186.issue10030@psf.upfronthosting.co.za>


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

It would be nice to retain the pure python version as a fallback for non CPython implementations, that will require tweaking the tests to make sure both are tested.

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

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

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


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

There's an error in the documentation for readline here:  http://docs.python.org/library/readline.html#example

The first example doesn't import readline.

----------
assignee: docs at python
components: Documentation
messages: 118040
nosy: Jason.Baker, docs at python
priority: normal
severity: normal
status: open
title: Readline doc issue
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10034>
_______________________________________

From report at bugs.python.org  Wed Oct  6 00:51:34 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 05 Oct 2010 22:51:34 +0000
Subject: [issue2892] improve cElementTree iterparse error handling
In-Reply-To: <1210940435.5.0.243679200602.issue2892@psf.upfronthosting.co.za>
Message-ID: <1286319094.79.0.288548454455.issue2892@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

If it's a regression, it should be fixed in some 2.7.x  release
Is there a patch somewhere?

----------
nosy: +amaury.forgeotdarc
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2892>
_______________________________________

From report at bugs.python.org  Wed Oct  6 00:53:42 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 05 Oct 2010 22:53:42 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1286319222.99.0.748944052208.issue4487@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

David, can this issue be closed?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4487>
_______________________________________

From report at bugs.python.org  Wed Oct  6 01:16:01 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 05 Oct 2010 23:16:01 +0000
Subject: [issue2982] more tests for pyexpat
In-Reply-To: <1211905628.44.0.670797216201.issue2982@psf.upfronthosting.co.za>
Message-ID: <1286320561.65.0.742100853371.issue2982@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Adapted patch for py3k and applied in r85239.
Maciek, if you have another tests for error handling, please open a new issue.

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2982>
_______________________________________

From report at bugs.python.org  Wed Oct  6 01:17:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 05 Oct 2010 23:17:12 +0000
Subject: [issue4487] Add utf8 alias for email charsets
In-Reply-To: <1228223832.43.0.0399583143577.issue4487@psf.upfronthosting.co.za>
Message-ID: <1286320632.02.0.856750866242.issue4487@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes.  Benjamin merged this to py3k in r82292.  If someone wants to explain to me how to cherry pick the changeset into 3.1 I'd be happy to do it, otherwise I think I'm done with this one :)

----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4487>
_______________________________________

From report at bugs.python.org  Wed Oct  6 01:44:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 05 Oct 2010 23:44:23 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286322263.87.0.530517573449.issue10029@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/issue10029>
_______________________________________

From report at bugs.python.org  Wed Oct  6 03:42:05 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 06 Oct 2010 01:42:05 +0000
Subject: [issue10032] os.setuid and os.setgid have unexpected influence on
	serial module
In-Reply-To: <1286311684.44.0.770931367073.issue10032@psf.upfronthosting.co.za>
Message-ID: <1286329325.57.0.197855182424.issue10032@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

While you did not specify what platform you are running this on, the issue here is almost certainly a misunderstanding of how permissions work.  On UNIX-y systems, access to device files is normally governed by permissions like any other file or directory.  On many systems, groups are set up to allow users to access devices without requiring root permission.  User "tjp" is very likely a member of a supplementary group that has group permission to the device in question.  When run under sudo, the program initially can access the device because of the superuser (root) permission.  After it is daemonizied, though, it no longer has root but it does not have the supplementary group permissions it would have had running normally; it only has uid 1000 and gid 1000.

The following example illustrates:

# in this example, /dev/mixer has a gid of 29 (group=audio)
# and the user (uid=501,gid=501) is a member of group 29
$ id -u
501
$ id -g
501
$ id -G
501 6 22 24 25 27 29 44 46 107 112 114 1001 40100 40200
$ ls -ln /dev/mixer
crw-rw---- 1 0 29 14, 0 Oct  5 14:06 /dev/mixer
$ python -c "open('/dev/mixer','r')"
$ sudo python -c "open('/dev/mixer','r')
$ sudo python -c "import os; os.setgid(501); os.setuid(501); open('/dev/mixer','r')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
IOError: [Errno 13] Permission denied: '/dev/mixer'
$ python -c "import os; print(os.getgroups())"
[6, 22, 24, 25, 27, 29, 44, 46, 107, 112, 114, 501, 1001, 40100, 40200]
$ sudo python -c "import os; print(os.getgroups())"
[0]

If this does not explain the results you are seeing, please re-open with additional supporting information.

----------
nosy: +ned.deily
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10032>
_______________________________________

From report at bugs.python.org  Wed Oct  6 04:08:42 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 06 Oct 2010 02:08:42 +0000
Subject: [issue10033] can't run unittest because of issubclass
In-Reply-To: <1286314685.42.0.495645038827.issue10033@psf.upfronthosting.co.za>
Message-ID: <1286330922.57.0.251423009448.issue10033@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The unittest module was substantially revised and enhanced for Python 2.7 and the upcoming 3.2.  Your test case now works properly under both.

$ python2.6 -m unittest -v simple_test

----------------------------------------------------------------------
Ran 0 tests in 0.000s

OK
$ python2.7 -m unittest -v simple_test
test_1 (simple_test.A) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
$ python3.2 -m unittest -v simple_test
test_1 (simple_test.A) ... ok

----------------------------------------------------------------------
Ran 1 test in 0.000s

OK

Since only security issues are still being accepted for Python 2.6, this problem will not be fixed there.

----------
nosy: +ned.deily
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10033>
_______________________________________

From report at bugs.python.org  Wed Oct  6 04:37:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 06 Oct 2010 02:37:15 +0000
Subject: [issue10032] os.setuid and os.setgid have unexpected influence on
	serial module
In-Reply-To: <1286311684.44.0.770931367073.issue10032@psf.upfronthosting.co.za>
Message-ID: <1286332635.04.0.712782415491.issue10032@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If you do want to pursue this further note that "[your] own crappy code" is a better reproducer to post than something that depends on a third party module.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10032>
_______________________________________

From report at bugs.python.org  Wed Oct  6 06:28:04 2010
From: report at bugs.python.org (halfjuice)
Date: Wed, 06 Oct 2010 04:28:04 +0000
Subject: [issue10035] sgmllib fail to parse html containing <!- .... ->
In-Reply-To: <1286339282.85.0.467383816638.issue10035@psf.upfronthosting.co.za>
Message-ID: <1286339282.85.0.467383816638.issue10035@psf.upfronthosting.co.za>


New submission from halfjuice <halfjuice at gmail.com>:

When parsing html containing the following tag:
... <!- ie6 doesn't allow empty div. -> ...
SGMLParser will stop parse following content without any warning. When such tag is removed everything works fine.

When looking into sgmllib.py, statement below found:

    if rawdata.startswith("<!", i):
        # This is some sort of declaration; in "HTML as
        # deployed," this should only be the document type
        # declaration ("<!DOCTYPE html...>").

I think that's why something goes wrong here.

----------
components: Library (Lib)
messages: 118048
nosy: halfjuice
priority: normal
severity: normal
status: open
title: sgmllib fail to parse html containing <!- .... ->
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10035>
_______________________________________

From report at bugs.python.org  Wed Oct  6 07:07:10 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Oct 2010 05:07:10 +0000
Subject: [issue10035] sgmllib fail to parse html containing <!- .... ->
In-Reply-To: <1286339282.85.0.467383816638.issue10035@psf.upfronthosting.co.za>
Message-ID: <1286341630.15.0.921974577164.issue10035@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Are you sure you got the comment syntax right? e.g.
<!-- ie6 doesn't allow empty div. -->

SGMLParser should handle that.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10035>
_______________________________________

From report at bugs.python.org  Wed Oct  6 07:09:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Oct 2010 05:09:02 +0000
Subject: [issue10034] Readline doc issue
In-Reply-To: <1286318872.8.0.983307601226.issue10034@psf.upfronthosting.co.za>
Message-ID: <1286341742.33.0.335847581011.issue10034@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r85240.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10034>
_______________________________________

From report at bugs.python.org  Wed Oct  6 07:11:54 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Oct 2010 05:11:54 +0000
Subject: [issue10026] xml.dom.pulldom strange behavior
In-Reply-To: <1286273854.3.0.24375174829.issue10026@psf.upfronthosting.co.za>
Message-ID: <1286341914.67.0.633044449588.issue10026@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10026>
_______________________________________

From report at bugs.python.org  Wed Oct  6 07:51:25 2010
From: report at bugs.python.org (Jeffrey Finkelstein)
Date: Wed, 06 Oct 2010 05:51:25 +0000
Subject: [issue10036] compiler warnings for various modules on Ubuntu x86
In-Reply-To: <1286344285.28.0.174737248843.issue10036@psf.upfronthosting.co.za>
Message-ID: <1286344285.28.0.174737248843.issue10036@psf.upfronthosting.co.za>


New submission from Jeffrey Finkelstein <jeffrey.finkelstein at gmail.com>:

On Ubuntu 10.04.1, with
"uname -a" outputting "Linux hostname 2.6.32-25-generic #44-Ubuntu SMP Fri Sep 17 20:26:08 UTC 2010 i686 GNU/Linux"
"gcc --version" outputting "gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3"

On hg revision 7965 of the py3k branch, I get the following compile-time warnings:

/mnt/data/src/py3k/Modules/_posixsubprocess.c: In function ?child_exec?:
/mnt/data/src/py3k/Modules/_posixsubprocess.c:152: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_posixsubprocess.c:158: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_posixsubprocess.c:159: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_posixsubprocess.c:163: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_posixsubprocess.c:164: warning: ignoring return value of ?write?, declared with attribute warn_unused_result

/mnt/data/src/py3k/Modules/socketmodule.c: In function ?socket_gethostbyname_ex?:
/mnt/data/src/py3k/Modules/socketmodule.c:3282: warning: dereferencing pointer ?sa? does break strict-aliasing rules
/mnt/data/src/py3k/Modules/socketmodule.c:3280: note: initialized from here
/mnt/data/src/py3k/Modules/socketmodule.c: In function ?socket_gethostbyaddr?:
/mnt/data/src/py3k/Modules/socketmodule.c:3339: warning: dereferencing pointer ?sa? does break strict-aliasing rules
/mnt/data/src/py3k/Modules/socketmodule.c:3309: note: initialized from here

/mnt/data/src/py3k/Modules/_multiprocessing/multiprocessing.c: In function ?multiprocessing_sendfd?:
/mnt/data/src/py3k/Modules/_multiprocessing/multiprocessing.c:125: warning: dereferencing type-punned pointer will break strict-aliasing rules
/mnt/data/src/py3k/Modules/_multiprocessing/multiprocessing.c: In function ?multiprocessing_recvfd?:
/mnt/data/src/py3k/Modules/_multiprocessing/multiprocessing.c:168: warning: dereferencing type-punned pointer will break strict-aliasing rules

/mnt/data/src/py3k/Modules/_ctypes/libffi/src/closures.c: In function ?dlmmap_locked?:
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/closures.c:416: warning: ignoring return value of ?ftruncate?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/closures.c:428: warning: ignoring return value of ?ftruncate?, declared with attribute warn_unused_result
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/dlmalloc.c: In function ?mmap_resize?:
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/dlmalloc.c:3193: warning: implicit declaration of function ?mremap?
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/dlmalloc.c: In function ?sys_trim?:
/mnt/data/src/py3k/Modules/_ctypes/libffi/src/dlmalloc.c:3612: warning: comparison between pointer and integer

----------
components: Build
messages: 118051
nosy: jfinkels
priority: normal
severity: normal
status: open
title: compiler warnings for various modules on Ubuntu x86
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10036>
_______________________________________

From report at bugs.python.org  Wed Oct  6 08:08:03 2010
From: report at bugs.python.org (halfjuice)
Date: Wed, 06 Oct 2010 06:08:03 +0000
Subject: [issue10035] sgmllib fail to parse html containing <!- .... ->
In-Reply-To: <1286339282.85.0.467383816638.issue10035@psf.upfronthosting.co.za>
Message-ID: <1286345283.09.0.919694480958.issue10035@psf.upfronthosting.co.za>


halfjuice <halfjuice at gmail.com> added the comment:

well, <!-- ... -> is ok since it's comment. <!- ... -> is probably a IE hack. see http://www.google.com/dictionary?langpair=en|zh-CN&q=vague&hl=en&aq=f

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10035>
_______________________________________

From report at bugs.python.org  Wed Oct  6 08:39:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Oct 2010 06:39:16 +0000
Subject: [issue10035] sgmllib fail to parse html containing <!- .... ->
In-Reply-To: <1286339282.85.0.467383816638.issue10035@psf.upfronthosting.co.za>
Message-ID: <1286347156.61.0.198245206696.issue10035@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Is that URL really what you wanted to show me?

Also, I'm not intimate with all of SGML's syntax, but ISTM that what you show here is invalid SGML, and as such SGMLParser is not required to parse it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10035>
_______________________________________

From report at bugs.python.org  Wed Oct  6 09:10:15 2010
From: report at bugs.python.org (halfjuice)
Date: Wed, 06 Oct 2010 07:10:15 +0000
Subject: [issue10035] sgmllib fail to parse html containing <!- .... ->
In-Reply-To: <1286339282.85.0.467383816638.issue10035@psf.upfronthosting.co.za>
Message-ID: <1286349015.78.0.632239701821.issue10035@psf.upfronthosting.co.za>


halfjuice <halfjuice at gmail.com> added the comment:

Sorry, the URL on the page is sort of broken. The URL contains the "<!- ... ->" stuff.

I think you're right, the <!- is probably just a mistake which is not in the SGML standard. But I'm wondering if the SGMLParser can SKIP such an invalid statement? My browser does this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10035>
_______________________________________

From report at bugs.python.org  Wed Oct  6 09:16:29 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Oct 2010 07:16:29 +0000
Subject: [issue10035] sgmllib fail to parse html containing <!- .... ->
In-Reply-To: <1286339282.85.0.467383816638.issue10035@psf.upfronthosting.co.za>
Message-ID: <1286349389.78.0.81049071199.issue10035@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The browser needs to be very liberal in what it accepts, since nobody wants their page view to break because of such a technicality. This is different for a tool like SGMLParser.

In light of this, and because sgmllib is removed anyway in Python 3, I'm closing this.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10035>
_______________________________________

From report at bugs.python.org  Wed Oct  6 10:07:51 2010
From: report at bugs.python.org (harobed)
Date: Wed, 06 Oct 2010 08:07:51 +0000
Subject: [issue9017] doctest option flag to enable/disable some chunk of
	doctests?
In-Reply-To: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>
Message-ID: <1286352471.39.0.41634723445.issue9017@psf.upfronthosting.co.za>


harobed <stephane at harobed.org> added the comment:

doctest.SKIP is like #doctest: +DISABLE but he don't have #doctest: +ENABLE feature.

doctest.SKIP disable all the bottom of test, DISABLE/ENABLE?can SKIP only one part of test.

Regards,
Stephane

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9017>
_______________________________________

From report at bugs.python.org  Wed Oct  6 10:10:24 2010
From: report at bugs.python.org (Tjeerd Pinkert)
Date: Wed, 06 Oct 2010 08:10:24 +0000
Subject: [issue10032] os.setuid and os.setgid have unexpected influence on
	serial module
In-Reply-To: <1286311684.44.0.770931367073.issue10032@psf.upfronthosting.co.za>
Message-ID: <1286352624.15.0.73250512839.issue10032@psf.upfronthosting.co.za>


Tjeerd Pinkert <t.j.pinkert at alumnus.utwente.nl> added the comment:

Indeed I use Linux, sorry for the inconvenience of not mentioning.

Thanks Ned, I think this is indeed the case. Using os.setgroups with a list of group ids (one for the file access, one for the serial port) before switching user with os.setgid, os.setuid solved the problem.
I think os.initgroups(username, gid) does just this, only is not yet available in my distro.

It could be a feature of os that the groups of the user are set on a os.setuid call? Or would this break compatibility with the standard unix library behaviour?

To David: Yes you are right, only it would have cost me quite a bit of time to strip the code, and I tried this code to see if the behaviour was consistent when using other daemon code. Next time I will post my own code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10032>
_______________________________________

From report at bugs.python.org  Wed Oct  6 10:28:48 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Wed, 06 Oct 2010 08:28:48 +0000
Subject: [issue10028] test_concurrent_futures fails on Windows Server 2003
In-Reply-To: <1286303139.16.0.442132720104.issue10028@psf.upfronthosting.co.za>
Message-ID: <1286353728.45.0.199211895268.issue10028@psf.upfronthosting.co.za>


Changes by Brian Quinlan <brian at sweetapp.com>:


----------
assignee:  -> bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10028>
_______________________________________

From report at bugs.python.org  Wed Oct  6 10:58:18 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 06 Oct 2010 08:58:18 +0000
Subject: [issue9017] doctest option flag to enable/disable some chunk of
	doctests?
In-Reply-To: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>
Message-ID: <1286355498.12.0.522701028162.issue9017@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I'm not a great doctest user, but did you try to disable the SKIP directive at the end? something like "doctest: -SKIP"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9017>
_______________________________________

From report at bugs.python.org  Wed Oct  6 10:59:54 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 06 Oct 2010 08:59:54 +0000
Subject: [issue9017] doctest option flag to enable/disable some chunk of
	doctests?
In-Reply-To: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>
Message-ID: <1286355594.72.0.617519990156.issue9017@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

AFAIR +SKIP always only refers to one Example anyway.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9017>
_______________________________________

From report at bugs.python.org  Wed Oct  6 11:01:20 2010
From: report at bugs.python.org (Douglas Leeder)
Date: Wed, 06 Oct 2010 09:01:20 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286355680.92.0.711651435764.issue10029@psf.upfronthosting.co.za>


Changes by Douglas Leeder <douglas.leeder at gmail.com>:


----------
nosy: +Douglas.Leeder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10029>
_______________________________________

From report at bugs.python.org  Wed Oct  6 11:08:50 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Wed, 06 Oct 2010 09:08:50 +0000
Subject: [issue10028] test_concurrent_futures fails on Windows Server 2003
In-Reply-To: <1286303139.16.0.442132720104.issue10028@psf.upfronthosting.co.za>
Message-ID: <1286356130.41.0.585710737904.issue10028@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Hey Brian,

Could you try applying the patch that I attached and let me know what error message you get?

Cheers,
(the other) Brian

----------
keywords: +patch
Added file: http://bugs.python.org/file19137/error.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10028>
_______________________________________

From report at bugs.python.org  Wed Oct  6 13:21:38 2010
From: report at bugs.python.org (harobed)
Date: Wed, 06 Oct 2010 11:21:38 +0000
Subject: [issue9017] doctest option flag to enable/disable some chunk of
	doctests?
In-Reply-To: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>
Message-ID: <1286364098.63.0.435873700513.issue9017@psf.upfronthosting.co.za>


harobed <stephane at harobed.org> added the comment:

Ok, option +SKIP and -SKIP work well, look test.py file

I need maybe improve the documentation with an +SKIP and -SKIP example ?

Documentation section about SKIP option is here : http://docs.python.org/library/doctest.html?highlight=doctest.skip#doctest.SKIP

Regards,
Stephane

----------
Added file: http://bugs.python.org/file19138/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9017>
_______________________________________

From report at bugs.python.org  Wed Oct  6 13:25:59 2010
From: report at bugs.python.org (Ask Solem)
Date: Wed, 06 Oct 2010 11:25:59 +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: <1286364358.68.0.746245038707.issue10037@psf.upfronthosting.co.za>


New submission from Ask Solem <askh at opera.com>:

While working on an "autoscaling" (yes, people call it that...) feature for Celery, I noticed that the processes created by the _handle_workers thread doesn't always work.  I have reproduced this in general, by just using the maxtasksperchild feature and letting the workers terminate themselves so this seems to have always been an issue (just not easy to reproduce unless workers are created with some frequency)

I'm not quite sure of the reason yet, but I finally managed to track it down to the workers being stuck while receiving from the queue.

The patch attached seems to resolve the issue by polling the queue before trying to receive.

I know this is short, I may have some more data later.

----------
components: Library (Lib)
files: multiprocessing-worker-poll.patch
keywords: needs review, patch
messages: 118062
nosy: asksol
priority: critical
severity: normal
stage: patch review
status: open
title: multiprocessing.pool processes started by worker handler stops working
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19139/multiprocessing-worker-poll.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10037>
_______________________________________

From report at bugs.python.org  Wed Oct  6 13:44:55 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 06 Oct 2010 11:44:55 +0000
Subject: [issue9017] doctest option flag to enable/disable some chunk of
	doctests?
In-Reply-To: <1276778533.38.0.325280903618.issue9017@psf.upfronthosting.co.za>
Message-ID: <1286365495.52.0.355893905184.issue9017@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

harobed, the -SKIP solution does not work. Doctest directives only apply to a single line.

After a quick search, I found two workarounds there:
http://stackoverflow.com/questions/1809037/python-doctest-skip-entire-block
- Replace >>> with >>
or
- split the docstring, and add something like "__dont_test__ = " in front of the second part; the string becomes part of a statement and won't be parsed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9017>
_______________________________________

From report at bugs.python.org  Wed Oct  6 13:47:51 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 06 Oct 2010 11:47: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: <1286365671.59.0.556119133038.issue10027@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

There are some questions.

1. About my patch, I noticed it removed following code.
   Isn't this needed? I like clean code, but I don't want to
   break anything.

    /* Get WIN32_FIND_DATA structure for the path to determine if
       it is a symlink */
    if(info.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT) {
        find_data_handle = FindFirstFileA(path, &find_data);
        if(find_data_handle != INVALID_HANDLE_VALUE) {
            if(find_data.dwReserved0 == IO_REPARSE_TAG_SYMLINK) {
                /* first clear the S_IFMT bits */
                result->st_mode ^= (result->st_mode & 0170000);
                /* now set the bits that make this a symlink */
                result->st_mode |= 0120000;
            }
            FindClose(find_data_handle);
        }
    }


    /* Set S_IFEXEC if it is an .exe, .bat, ... */
    dot = strrchr(path, '.');
    if (dot) {
        if (stricmp(dot, ".bat") == 0 || stricmp(dot, ".cmd") == 0 ||
            stricmp(dot, ".exe") == 0 || stricmp(dot, ".com") == 0)
            result->st_mode |= 0111;
    }

2. About current behavior. when os.stat() is used for junction
   (reparse point, but not simlink), returned information is
   about junction on XP or earlier, but about target folder on
   Vista or above. Is this intended bahavior?

Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Wed Oct  6 13:51:07 2010
From: report at bugs.python.org (amiadb)
Date: Wed, 06 Oct 2010 11:51:07 +0000
Subject: [issue8359] % formating - TypeError: not all arguments converted
	during string formatting
In-Reply-To: <1270892279.77.0.4172116449.issue8359@psf.upfronthosting.co.za>
Message-ID: <1286365867.42.0.0234904820084.issue8359@psf.upfronthosting.co.za>


amiadb <amiadb at gmail.com> added the comment:

This bug is very disturbing in Hebrew too.
I need to translate "% hour" to "?% ????" and its wrong in Hebrew. in Hebrew I need to write "??? ???" (one hour).

----------
nosy: +amiadb

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8359>
_______________________________________

From report at bugs.python.org  Wed Oct  6 13:53:11 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 06 Oct 2010 11:53:11 +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: <1286365991.5.0.939170809352.issue10027@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

P.S. Thank you for acceptance. I really wanted to commit
that code!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Wed Oct  6 14:26:05 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Oct 2010 12:26:05 +0000
Subject: [issue9325] Add an option to pdb/trace/profile to run library module
	as a script
In-Reply-To: <1279743902.96.0.66207849175.issue9325@psf.upfronthosting.co.za>
Message-ID: <1286367965.67.0.0355003193433.issue9325@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/issue9325>
_______________________________________

From report at bugs.python.org  Wed Oct  6 15:08:07 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Wed, 06 Oct 2010 13:08:07 +0000
Subject: [issue9903] test_concurrent_futures writes on stderr
In-Reply-To: <1284943723.6.0.157191690698.issue9903@psf.upfronthosting.co.za>
Message-ID: <1286370487.42.0.56586763508.issue9903@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Fixed in r85288

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9903>
_______________________________________

From report at bugs.python.org  Wed Oct  6 17:29:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Oct 2010 15:29:16 +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: <1286378956.07.0.844870980978.issue1589@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If nobody objects, I will commit this (with docs) soon. Then I will open a separate issue for the http.client / urllib.request integration, since the discussion is already quite long here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Oct  6 17:36:58 2010
From: report at bugs.python.org (Nik Tautenhahn)
Date: Wed, 06 Oct 2010 15:36:58 +0000
Subject: [issue10038] Returntype of json.loads() on strings
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>


New submission from Nik Tautenhahn <nik at livinglogic.de>:

Hi,

before 2.7, an
import json
json.loads('"abc"')

yielded u"abc".

in 2.7 I get
"abc" (a byte string).

I would have expected an entry in "news" or "What's new in 2.7" why this change happened. In addition, all examples at http://docs.python.org/library/json are wrong for Python 2.7  if json.loads is involved.

Any insight on this?

best regards,
Nik

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 118069
nosy: docs at python, llnik
priority: normal
severity: normal
status: open
title: Returntype of json.loads() on strings
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Wed Oct  6 17:41:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Oct 2010 15:41:56 +0000
Subject: [issue10038] Returntype of json.loads() on strings
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1286379716.64.0.434176079771.issue10038@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: docs at python -> bob.ippolito
nosy: +bob.ippolito

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Wed Oct  6 17:46:04 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 06 Oct 2010 15:46:04 +0000
Subject: [issue10038] Returntype of json.loads() on strings
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1286379964.12.0.0320817912142.issue10038@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

This is related to this issue from simplejson:
http://code.google.com/p/simplejson/issues/detail?id=28

This problem is why I still use simplejson 1.x; moving forward to simplejson 2.x or Python's json is unlikely.

----------
nosy: +fdrake

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Wed Oct  6 18:32:17 2010
From: report at bugs.python.org (Nik Tautenhahn)
Date: Wed, 06 Oct 2010 16:32:17 +0000
Subject: [issue10038] Returntype of json.loads() on strings
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1286382736.49.0.581100863086.issue10038@psf.upfronthosting.co.za>


Nik Tautenhahn <nik at livinglogic.de> added the comment:

Well, Ok, if I take bob's comment from the simplejson Issue, I can understand that some people want byte strings. But then I would like to have something like a "parse_str" hook, to enhance my json-Decoder or maybe a keyword argument for the default json-Decoder...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Wed Oct  6 20:15:28 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 06 Oct 2010 18:15:28 +0000
Subject: [issue10032] os.setuid and os.setgid have unexpected influence on
	serial module
In-Reply-To: <1286311684.44.0.770931367073.issue10032@psf.upfronthosting.co.za>
Message-ID: <1286388928.36.0.70258652004.issue10032@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

"It could be a feature of os that the groups of the user are set on a os.setuid call? Or would this break compatibility with the standard unix library behaviour?"

The POSIX system interface specification specifically prohibits that: "The setuid() function shall not affect the supplementary group list in any way."

http://www.opengroup.org/onlinepubs/009695399/functions/setuid.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10032>
_______________________________________

From report at bugs.python.org  Wed Oct  6 20:32:51 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Wed, 06 Oct 2010 18:32: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: <1286389971.32.0.291008339447.issue1589@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

I'm sorry to make the discussion longer ...


>From a Python user/programmers point of view it would be nice if http://docs.python.org/library/ssl.html also clarified what "validation" means (apparently that the cert chain all the way from one of ca_certs is valid and with valid dates, except that CRLs not are checked?). It could perhaps be mentioned next to the ca_certs description. It would also be nice to see an example with subjectAltName, both with DNS and IP entries.

Has it been tested that the way Python uses OpenSSL really checks both notBefore and notAfter?


Some comments to the patch. Some of them are just thoughts that can be ignored, but I think some of them are relevant.

_dnsname_to_pat:

AFAICS * shouldn't match the empty string. I would expect "fail(cert, '.a.com')".

I would prefer to fail to the safe side and only allow a left-most wildcard and thus not allow multiple or f* wildcards, just like draft-saintandre-tls-server-id-check-09 suggests.

I would prefer to not use re for such an important task where clarity and correctness is so important. If we only allow left-most wildcards it shouldn't be necessary.

match_hostname:

I don't understand "IP addresses are not accepted for hostname". I assume that if commonName specifies an IP address then a hostname with this address is valid. So isn't it more that "subjectAltName iPAddress isn't supported"? But wouldn't it be better and simpler to simply support iPAddress - either as the only check iff hostname "looks" like an IP address, alternatively in all cases check against both DNS and IP entries?

"dnsnames" doesn't say much about what it is. Perhaps "unmatched"?

"if san: ... else: ..." would perhaps be a bit clearer.

"doesn't match with either of (%s)" ... isn't the paranthesis around the list elements too pythonic for a message intended for end users?

Separate error messages for subjectAltName and commonName could be helpful.

I assume it should be "no appropriate _commonName_" to match "subjectAltName".

test:

cert for example.com is defined twice.


Finally:

How about unicode and/or IDN hostnames?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Oct  6 20:32:59 2010
From: report at bugs.python.org (Tom Morris)
Date: Wed, 06 Oct 2010 18:32:59 +0000
Subject: [issue9163] test_gdb fails
In-Reply-To: <1278314862.38.0.121904956787.issue9163@psf.upfronthosting.co.za>
Message-ID: <1286389979.61.0.973836515016.issue9163@psf.upfronthosting.co.za>


Tom Morris <tfmorris at gmail.com> added the comment:

Did this fix actually make the 2.7 release?  I just installed 2.7 on 64-bit Ubuntu and ran into the same problem.

python -c "import sysconfig; print sysconfig.get_config_vars()['PY_CFLAGS']"
-fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include  -DPy_BUILD_CORE

Python 2.7 (r27:82500, Oct  6 2010, 12:53:54) 
[GCC 4.4.1] on linux2

uname -a
Linux tfmorris-laptop 2.6.31-22-generic #65-Ubuntu SMP Thu Sep 16 16:21:34 UTC 2010 x86_64 GNU/Linux

----------
nosy: +tfmorris

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9163>
_______________________________________

From report at bugs.python.org  Wed Oct  6 21:05:34 2010
From: report at bugs.python.org (5houston)
Date: Wed, 06 Oct 2010 19:05:34 +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: <1286391934.28.0.470389383116.issue8028@psf.upfronthosting.co.za>


5houston <cadabras at gmail.com> added the comment:

Yes I could. You can find it attached.

----------
Added file: http://bugs.python.org/file19140/minCrashing.py.bz2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8028>
_______________________________________

From report at bugs.python.org  Wed Oct  6 21:15:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Oct 2010 19:15:00 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1286389971.32.0.291008339447.issue1589@psf.upfronthosting.co.za>
Message-ID: <1286392173.3133.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> From a Python user/programmers point of view it would be nice if
> http://docs.python.org/library/ssl.html also clarified what
> "validation" means (apparently that the cert chain all the way from
> one of ca_certs is valid and with valid dates, except that CRLs not
> are checked?). It could perhaps be mentioned next to the ca_certs
> description. It would also be nice to see an example with
> subjectAltName, both with DNS and IP entries.

As mentioned in the patch, IP entries are not supported.
I'm planning to do a couple of doc updates as part of the commit, but
any doc suggestions should go in a separate issue IMO. This will make
things more manageable.

> Has it been tested that the way Python uses OpenSSL really checks both
> notBefore and notAfter?

I just checked and, yes, it does (but only if you specify CERT_OPTIONAL
or CERT_REQUIRED, of course).

> AFAICS * shouldn't match the empty string. I would expect "fail(cert,
> '.a.com')".

Good point.

> I would prefer to fail to the safe side and only allow a left-most
> wildcard and thus not allow multiple or f* wildcards, just like
> draft-saintandre-tls-server-id-check-09 suggests.

Well, RFC 2818 allows them, and I see no point in being stricter.

> I would prefer to not use re for such an important task where clarity
> and correctness is so important. If we only allow left-most wildcards
> it shouldn't be necessary.

I'm not convinced that manual parsing is really more readable than
regular expressions, and wildcards are a pretty obvious use case for
regular expressions. Perhaps it's a matter of habit.

> match_hostname:
> 
> I don't understand "IP addresses are not accepted for hostname". I
> assume that if commonName specifies an IP address then a hostname with
> this address is valid. So isn't it more that "subjectAltName iPAddress
> isn't supported"?

Indeed. But, strictly speaking, there are no tests for IPs, so it
shouldn't be taken for granted that it works, even for commonName.
The rationale is that there isn't really any point in using an IP rather
a host name.

> But wouldn't it be better and simpler to simply support iPAddress -
> either as the only check iff hostname "looks" like an IP address,
> alternatively in all cases check against both DNS and IP entries?

Well, that's additional logic to code. I'm not sure it's worth it,
especially given that the function is called match_hostname in the first
place.

> "doesn't match with either of (%s)" ... isn't the paranthesis around
> the list elements too pythonic for a message intended for end users?

Hmm, perhaps.

> Separate error messages for subjectAltName and commonName could be
> helpful.

That depends if you're an end user or an SSL expert, I guess. end users
don't know what subjectAltNames and commonNames are.

> I assume it should be "no appropriate _commonName_" to match
> "subjectAltName".

Ah, yes.

> cert for example.com is defined twice.

Right.

> How about unicode and/or IDN hostnames?

I haven't looked how these work in the context of certificate checking.
I would prefer to tackle that separately if needed, but someone can
provide a patch for this if they want.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Oct  6 21:45:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 06 Oct 2010 19:45:55 +0000
Subject: [issue9163] test_gdb fails
In-Reply-To: <1286389979.61.0.973836515016.issue9163@psf.upfronthosting.co.za>
Message-ID: <4CACD1E7.60104@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Did this fix actually make the 2.7 release?

Are you sure you posted to the right issue? I fail to see the
relationship between your message and the original report.

If you found a bug in Python 2.7, please report it as a
separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9163>
_______________________________________

From report at bugs.python.org  Thu Oct  7 03:26:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Oct 2010 01:26:21 +0000
Subject: [issue10014] sys.path[0] is incorrect if PYTHONFSENCODING is used
In-Reply-To: <1286021663.34.0.689026258035.issue10014@psf.upfronthosting.co.za>
Message-ID: <1286414781.59.0.441752456317.issue10014@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #10039.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10014>
_______________________________________

From report at bugs.python.org  Thu Oct  7 01:22:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Oct 2010 23:22:04 +0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1286407324.76.0.960335338658.issue1943@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch against current py3k.

----------
Added file: http://bugs.python.org/file19142/unialloc6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
_______________________________________

From report at bugs.python.org  Wed Oct  6 22:32:15 2010
From: report at bugs.python.org (Tom Morris)
Date: Wed, 06 Oct 2010 20:32:15 +0000
Subject: [issue9163] test_gdb fails
In-Reply-To: <1278314862.38.0.121904956787.issue9163@psf.upfronthosting.co.za>
Message-ID: <1286397135.38.0.945911890517.issue9163@psf.upfronthosting.co.za>


Tom Morris <tfmorris at gmail.com> added the comment:

Sorry, I misread the 'version' field as the version the fix was committed for, not the version the bug was reported against.

The fix was reportedly fixed in r82648 and v2.7 is r82500.  If there's ever a 2.7.1, I guess the fix will appear, but since the solution is to just ignore the test, that's easy to do manually. :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9163>
_______________________________________

From report at bugs.python.org  Thu Oct  7 01:37:43 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 06 Oct 2010 23:37:43 +0000
Subject: [issue10014] sys.path[0] is incorrect if PYTHONFSENCODING is used
In-Reply-To: <1286021663.34.0.689026258035.issue10014@psf.upfronthosting.co.za>
Message-ID: <1286408263.12.0.222197463384.issue10014@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The problem is that PySys_SetArgvEx() ...

Not only PySys_SetArgvEx(). There is another issue with RunMainFromImporter() which do: sys.path[0] = filename

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10014>
_______________________________________

From report at bugs.python.org  Thu Oct  7 04:57:11 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Thu, 07 Oct 2010 02:57:11 +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: <1286420231.96.0.0922539917032.issue2571@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since 'we' can reopen any closed issue, I will try to answer what I think you might be asking.

I closed this because of Daniel's suggestion coupled with the Richard disclaiming further interest and neither Raghuram nor any new responder saying anything more.

The issue title is a misstatement arising from the OP not noticing how to change the behavior. Anyone reopening this (or opening a new issue) would need to change the title to reflect what he thinks should be done. I will not do that because the naive change proposed in the thread seems unnecessary, while further investigation suggests that it may be wrong or insufficient.

The original post refers to use_rawinput as a 'module global value'. It is not that but a cmd.Cmd class data attribute that can be changed either for the class or an instance. It is one of 9 that might be so changed.

Looking at the patch with #405952 shows that Cmd.__init__ had no parameters and Cmd.cmdloop always read input with raw_input(), now renamed just input() (making the attribute name a bit obsolete). The replacement then was something like

                    if self.use_rawinput:
                        try:
                            line = input(self.prompt)
                        except EOFError:
                            line = 'EOF'
                    else:
                        sys.stdout.write(self.prompt) # note sys.,
                        sys.stdout.flush()            # not self. here
                        line = sys.stdin.readline()
                        if not len(line):
                            line = 'EOF'
                        else:
                            line = line[:-1] # chop \n

The reason for this patch, which *almost* replicates raw_input(), was that raw_input and/or readline swallowed an exception, whereas the replacement code does not. I wonder:
1. Does input() still do the same and should it?
2. Is there something about cmd processing that this is the only use of input() where this exception swallowing is a problem?
3. If so, why not always use the replacement? Speed?
4. I am sort of asking whether this was/is really the right hack.

Someone later added completekey as an initialization parameter (rather than as a date attribute) and the following code

        if self.use_rawinput and self.completekey:
            try:
                import readline
                self.old_completer = readline.get_completer()
                readline.set_completer(self.complete)
                readline.parse_and_bind(self.completekey+": complete")
            except ImportError:

I know nothing about readline and why it (apparently) requires the use of input(), but the point here is that setting use_rawinput to False disables completekey. This should be documented but I did not see such.

At the same or later time, someone added stdin and stdout parameters and change 'sys' to 'self' in the first snippet above. Given that these parameters appears useless when use_rawinput is True, why was use_rawinput not automatically set to false then? Blunder or subtle reason? Someone who proposes auto-resetting should try to find the name of the patch and/or commit author and ask.

It seems to me that all the process parameters should be handled uniformly. Make then all class attributes and let any be changed for instances as keyword attributes to __init__(). Given the conflict noted above, perhaps raise ValueError if someone makes contradictory changes.

So, ?ric, if your question was academic, I would leave this closed.
If it was not, and you want to reopen, retitle, and assign it to yourself, go ahead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Wed Oct  6 23:57:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Oct 2010 21:57:21 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <4CACEE0E.8080101@kiilerich.com>
Message-ID: <1286402236.3133.22.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't know if there is a point or not, but some hosts are for some 
> reason intended to be connected to using IP address and their 
> certificates thus contains IP addresses. I think we should support that 
> too, and I find it a bit confusing to only have partial support for 
> subjectAltName.

Do you have examples? Otherwise it is difficult to implement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Thu Oct  7 00:15:40 2010
From: report at bugs.python.org (Trent Mick)
Date: Wed, 06 Oct 2010 22:15:40 +0000
Subject: [issue2142] difflib.unified_diff(...) produces invalid patches
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1286403340.38.0.805779747706.issue2142@psf.upfronthosting.co.za>


Changes by Trent Mick <trentm at gmail.com>:


----------
assignee:  -> trentm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Wed Oct  6 22:59:01 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 06 Oct 2010 20:59:01 +0000
Subject: [issue10028] test_concurrent_futures fails on Windows Server 2003
In-Reply-To: <1286303139.16.0.442132720104.issue10028@psf.upfronthosting.co.za>
Message-ID: <1286398741.65.0.794387322145.issue10028@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm getting error 6 aka ERROR_INVALID_HANDLE.

I'll try to figure out what's going on later this week if I can find time. I'll also run this on my Server 2008 machine to see how works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10028>
_______________________________________

From report at bugs.python.org  Wed Oct  6 22:32:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Oct 2010 20:32:54 +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: <1286397174.71.0.516853742943.issue1589@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch with doc updates and the corrections mentioned above.

----------
Added file: http://bugs.python.org/file19141/sslcheck2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Thu Oct  7 03:25:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Oct 2010 01:25:33 +0000
Subject: =?utf-8?q?=5Bissue10039=5D_python_=C3=A9=2Epy_fails_with_UnicodeEncodeErr?=
	=?utf-8?q?or_if_PYTHONFSENCODING_is_used?=
In-Reply-To: <1286414733.34.0.0267403088134.issue10039@psf.upfronthosting.co.za>
Message-ID: <1286414733.34.0.0267403088134.issue10039@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If a program name contains a non-ascii character in its name and/or full path and PYTHONFSENCODING is set to an encoding different than the locale encoding, Python fails to open the program.

Example in the utf-8 locale:

$ PYTHONFSENCODING=ascii ./python ?.py
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' in position 0: ordinal not in range(128)

This issue is similar to #9992 and #10014.

Solutions: remove PYTHONFSENCODING environment variable or redecode the filename from the locale encoding to the filesystem encoding.

Attached patch implements the latter.

--

We may also redecode Py_GetProgramName().

----------
components: Interpreter Core, Unicode
files: redecode_filename.patch
keywords: patch
messages: 118089
nosy: haypo
priority: normal
severity: normal
status: open
title: python ?.py fails with UnicodeEncodeError if PYTHONFSENCODING is used
versions: Python 3.2
Added file: http://bugs.python.org/file19143/redecode_filename.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10039>
_______________________________________

From report at bugs.python.org  Thu Oct  7 06:20:43 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 07 Oct 2010 04:20:43 +0000
Subject: [issue10038] Returntype of json.loads() on strings
In-Reply-To: <1286402181.99.0.250735760549.issue10038@psf.upfronthosting.co.za>
Message-ID: <AANLkTimcn_L7jK5tuhANdEjm2u_ryj4pVz2-ZYgRNBEw@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

As I understand it, the decision to return str instead of unicode
values for the "simplejson" module was simply inherited by the
standard library.  As such, it still needs to be evaluated in the
context of the standard library, because of the incompatibility it
introduces.

I still maintain that it's a bug, and should be treated as such.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Thu Oct  7 03:57:13 2010
From: report at bugs.python.org (Robert Rohde)
Date: Thu, 07 Oct 2010 01:57:13 +0000
Subject: [issue10040] GZipFile failure on large files
In-Reply-To: <1286416633.51.0.196300487006.issue10040@psf.upfronthosting.co.za>
Message-ID: <1286416633.51.0.196300487006.issue10040@psf.upfronthosting.co.za>


New submission from Robert Rohde <rohde at robertrohde.com>:

I attempted to use GZipFile to process a 1.93 GB file that expands to 18.8 GB.

This consistently produces the same corrupted output file that has approximately, but not exactly, the right output file size.

I bypassed GZipFile by calling the 7-Zip executable to open the compressed file.  This works correctly and consistently.

I haven't tried to figure out how GZipFile works, but I assume that this failure is probably related to the very large size of the files I am working with.  I've used GZipFile before on much smaller files with no apparent problems.  I have no idea what precisely goes wrong, or how to fix it, but I felt it was important to note that GZipFile isn't working for at least some very large files.

----------
components: Library (Lib)
messages: 118091
nosy: Robert.Rohde
priority: normal
severity: normal
status: open
title: GZipFile failure on large files
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10040>
_______________________________________

From report at bugs.python.org  Thu Oct  7 10:12:59 2010
From: report at bugs.python.org (kai zhu)
Date: Thu, 07 Oct 2010 08:12:59 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>


New submission from kai zhu <kaizhu256 at gmail.com>:

i'm working on an independent py2to3 utility which directly imports py2x modules, by reverse compiling ast trees (code.google.com/p/asciiporn/source/browse/stable.py)

while forward porting the python2x redis client, this issue came up.
i kno its bad to use strings in sockets, but it seems webapps use it exploiting the fact utf8 is becoming a defacto web 'binary' standard



$ python3.1 echo.py
connected <socket.socket object, fd=4, family=2, type=1, proto=0> ('127.0.0.1', 41115)

$ python3.1 client.py 
b'hello\r\n' recv()
b'hello\r\n' makefile(mode = "rb")
'hello\n' makefile(mode = "r")


## echo.py - echo server program
import socket
serv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
  serv.bind(('localhost', 12345))
  serv.listen(1)
  while True:
    conn, addr = serv.accept()
    print( 'connected', conn, addr )
    while True:
      data = conn.recv(4096)
      if not data:
        conn.close()
        break
      conn.send(data)
finally:
  serv.close()



## client.py - client program
data = b'hello\r\n'
import socket
clie = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
  clie.connect(('localhost', 12345))

  clie.send(data)
  data = clie.recv(4096)
  print(repr(data), 'recv()')

  clie.send(data)
  file = clie.makefile('rb')
  data = file.readline()
  print(repr(data), 'makefile(mode = "rb")')

  clie.send(data)
  file = clie.makefile('r')
  data = file.readline()
  print(repr(data), 'makefile(mode = "r")') ## '\r' is silently dropped
finally:
  clie.close()

----------
components: 2to3 (2.x to 3.0 conversion tool), IO, Library (Lib), Unicode
messages: 118095
nosy: kaizhu
priority: normal
severity: normal
status: open
title: socket.makefile(mode = 'r').readline() silently removes carriage return
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Wed Oct  6 23:33:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Oct 2010 21:33:11 +0000
Subject: [issue9759] GzipFile object should raise ValueError on .read() after
	.close()
In-Reply-To: <1283535391.41.0.374921176114.issue9759@psf.upfronthosting.co.za>
Message-ID: <1286400791.58.0.437678979886.issue9759@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r85291 (3.x), and backported to 3.1 (r85293) and 2.7 (r85292). Thank you!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9759>
_______________________________________

From report at bugs.python.org  Thu Oct  7 04:30:45 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 07 Oct 2010 02:30:45 +0000
Subject: [issue8584] test_multiprocessing skips some tests
In-Reply-To: <1272669386.78.0.641016378449.issue8584@psf.upfronthosting.co.za>
Message-ID: <1286418645.92.0.4664002824.issue8584@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in r85299 (py3k), r85300 (release31-maint), and r85301 (release27-maint).

----------
assignee: jnoller -> brian.curtin
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8584>
_______________________________________

From report at bugs.python.org  Wed Oct  6 23:46:02 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Wed, 06 Oct 2010 21:46:02 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1286392173.3133.17.camel@localhost.localdomain>
Message-ID: <4CACEE0E.8080101@kiilerich.com>


Mads Kiilerich <mads at kiilerich.com> added the comment:

> Indeed. But, strictly speaking, there are no tests for IPs, so it
> shouldn't be taken for granted that it works, even for commonName.
> The rationale is that there isn't really any point in using an IP rather
> a host name.

I don't know if there is a point or not, but some hosts are for some 
reason intended to be connected to using IP address and their 
certificates thus contains IP addresses. I think we should support that 
too, and I find it a bit confusing to only have partial support for 
subjectAltName.

> Well, that's additional logic to code. I'm not sure it's worth it,
> especially given that the function is called match_hostname in the first
> place.

"hostname" in Python usually refers to both IP addresses and DNS 
hostnames (just like in URLs), so I think it is a fair assumption that 
IP addresses also works in this hostname function.

Perhaps it should be noted that CertificateError only is raised by 
match_hostname so a paranoid programmer don't start catching it 
everywhere - and also that match_hostname won't raise SSLError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Wed Oct  6 22:52:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 06 Oct 2010 20:52:28 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1286398348.83.0.991735824695.issue9003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

A big warning is now present (*) in the urllib and httplib documentation pages. Also, once issue1589 is fixed, we can go forward and make {http.client,urllib.request} check hostname and cert if the user gives the location of a bunch of CA certs.

(*) see e.g. http://docs.python.org/dev/library/urllib.request.html

----------
dependencies: +New SSL module doesn't seem to verify hostname against commonName in certificate
nosy: +Ryan.Tucker, ahasenack, db, devin, heikki, janssen, kiilerix, vila, zooko
stage:  -> needs patch
title: urllib about https behavior -> urllib.request and http.client should allow certificate checking
type:  -> feature request
versions: +Python 3.2, Python 3.3 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Wed Oct  6 22:29:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 06 Oct 2010 20:29:50 +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: <1286396990.85.0.370689110554.issue2571@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can we reopen this as a feature request for 3.2?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Thu Oct  7 10:26:52 2010
From: report at bugs.python.org (Francesco Ricciardi)
Date: Thu, 07 Oct 2010 08:26:52 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>


New submission from Francesco Ricciardi <francesco.ricciardi at hp.com>:

Tested with version 3.2a2. Not tested on version 2.7.

The current implementation of functools.total_ordering generates a stack overflow because it implements the new comparison functions with inline operator, which the Python interpreter might reverse if "other" does not implement them. Reversing the comparison makes the interpreter call again the lambda function for comparison generating a stack overflow.

Run the attached test file for an example of this behavior.

----------
components: Library (Lib)
files: test_total_ordering.py
messages: 118096
nosy: francescor
priority: normal
severity: normal
status: open
title: total_ordering stack overflow
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file19144/test_total_ordering.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Thu Oct  7 10:29:15 2010
From: report at bugs.python.org (Francesco Ricciardi)
Date: Thu, 07 Oct 2010 08:29:15 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1286440155.54.0.975544947706.issue10042@psf.upfronthosting.co.za>


Francesco Ricciardi <francesco.ricciardi at hp.com> added the comment:

Attached there is a solution of the problem, by implementing each comparison only with the class __xx__ and __eq__ operators.

Also in the file there is a complete test suite for it.

----------
Added file: http://bugs.python.org/file19145/new_total_ordering.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Wed Oct  6 23:56:21 2010
From: report at bugs.python.org (Nik Tautenhahn)
Date: Wed, 06 Oct 2010 21:56:21 +0000
Subject: [issue10038] Returntype of json.loads() on strings
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1286402181.99.0.250735760549.issue10038@psf.upfronthosting.co.za>


Nik Tautenhahn <nik at livinglogic.de> added the comment:

Well, then at least the documentation and the "What's changed" need to be updated. Furthermore, if such decisions are made, it would be at least nice to have some general "decode-hook" for json.JSONDecoder - the "object_hook" is only used for dict-objects - why is there no hook for strings or a general hook which is used on any objects?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Thu Oct  7 11:23:29 2010
From: report at bugs.python.org (Nik Tautenhahn)
Date: Thu, 07 Oct 2010 09:23:29 +0000
Subject: [issue10038] Returntype of json.loads() on strings
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1286443409.5.0.590311789175.issue10038@psf.upfronthosting.co.za>


Nik Tautenhahn <nik at livinglogic.de> added the comment:

Yep, the solution should not be "maybe it's str, maybe it's unicode" - I mean, if the decoder gives you a str if there are no fancy characters and unicode if it contains some, this might lead to some confusion... And yes, in my opinion, this is a bug, too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Thu Oct  7 11:51:00 2010
From: report at bugs.python.org (Anders Sandvig)
Date: Thu, 07 Oct 2010 09:51:00 +0000
Subject: [issue809163] Can't add files with spaces
Message-ID: <1286445060.08.0.365970514919.issue809163@psf.upfronthosting.co.za>


Changes by Anders Sandvig <anders.sandvig at gmail.com>:


----------
nosy: +asandvig

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue809163>
_______________________________________

From report at bugs.python.org  Thu Oct  7 12:13:50 2010
From: report at bugs.python.org (Steven Samuel Cole)
Date: Thu, 07 Oct 2010 10:13:50 +0000
Subject: [issue10043] UnboundLocalError with local variable set by setattr,
	caused by code run later
In-Reply-To: <1286446430.16.0.85312530766.issue10043@psf.upfronthosting.co.za>
Message-ID: <1286446430.16.0.85312530766.issue10043@psf.upfronthosting.co.za>


New submission from Steven Samuel Cole <steven.samuel.cole at gmail.com>:

inside a function, I create a local variable by using setattr with the current module as object, as in
  setattr(modules[__name__], 'name', 'value')

if I _later_ in the code set name to None, the attribute becomes unavailable even for code that is executed _before_ setting name to None.

please also see sample file.

----------
components: Interpreter Core
files: show_weird_behavior.py
messages: 118099
nosy: ssc
priority: normal
severity: normal
status: open
title: UnboundLocalError with local variable set by setattr, caused by code run later
type: behavior
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file19146/show_weird_behavior.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10043>
_______________________________________

From report at bugs.python.org  Thu Oct  7 13:31:52 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Oct 2010 11:31:52 +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: <1286451112.95.0.78255995703.issue10043@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

When python sees the assignment "name = None", it assumes that 'name' is a local variable. This happens before any code is executed. It then sees that you're printing 'name' before it is assigned to, which is an error. It does not take into account the dynamic creation of the module level variable.

----------
nosy: +eric.smith
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10043>
_______________________________________

From report at bugs.python.org  Thu Oct  7 13:33:07 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Oct 2010 11:33:07 +0000
Subject: [issue10014] sys.path[0] is incorrect if PYTHONFSENCODING is used
In-Reply-To: <1286021663.34.0.689026258035.issue10014@psf.upfronthosting.co.za>
Message-ID: <1286451187.09.0.537038333853.issue10014@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue depends on issue #10039.

----------
dependencies: +python ?.py fails with UnicodeEncodeError if PYTHONFSENCODING is used

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10014>
_______________________________________

From report at bugs.python.org  Thu Oct  7 13:41:52 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Oct 2010 11:41:52 +0000
Subject: [issue10014] sys.path[0] is incorrect if PYTHONFSENCODING is used
In-Reply-To: <1286021663.34.0.689026258035.issue10014@psf.upfronthosting.co.za>
Message-ID: <1286451712.54.0.926110381941.issue10014@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r85302: _wrealpath() and _Py_wreadlink() support surrogates in the input path.

--

realpath_fs_encoding.patch: patch _wrealpath() to encode the resulting path with the filesystem encoding (with surrogateescape) instead of the locale encoding. This patch is incomplete: it doesn't fix the issue for non-Windows platforms without the realpath() function.

redecode_filename.patch (from issue #10039) + realpath_fs_encoding.patch fix this issue on my Linux (Debian Sid) box.

----------
keywords: +patch
Added file: http://bugs.python.org/file19147/realpath_fs_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10014>
_______________________________________

From report at bugs.python.org  Thu Oct  7 13:56:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 11:56:30 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is an experimental patch to optimize some operations on small ints.
pystone is 5-10% faster, pybench 2-3% faster, and here are some relevant benchmarks from unladen swallow:

### nbody ###
Min: 0.345136 -> 0.317502: 1.09x faster
Avg: 0.346827 -> 0.319561: 1.09x faster
Significant (t=79.50)
Stddev: 0.00140 -> 0.00198: 1.4084x larger

### nqueens ###
Min: 0.339744 -> 0.313506: 1.08x faster
Avg: 0.342630 -> 0.315380: 1.09x faster
Significant (t=73.41)
Stddev: 0.00218 -> 0.00146: 1.4931x smaller


If the principle gets accepted, we could experiment with further optimizations such as dedicated opcodes for addition-with-int-constant, subscripting-with-int-constant, etc.

----------
files: smallints.patch
keywords: patch
messages: 118103
nosy: Aahz, aahz, mark.dickinson, pitrou, rhettinger, stutzbach
priority: normal
severity: normal
status: open
title: small int optimization
type: performance
versions: Python 3.2
Added file: http://bugs.python.org/file19148/smallints.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 13:58:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 11:58:18 +0000
Subject: [issue9800] Fast path for small int-indexing of lists and tuples
In-Reply-To: <1283969230.58.0.425189432441.issue9800@psf.upfronthosting.co.za>
Message-ID: <1286452698.12.0.0874976911286.issue9800@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the approach in issue10044 is better.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9800>
_______________________________________

From report at bugs.python.org  Thu Oct  7 14:08:35 2010
From: report at bugs.python.org (Steven Samuel Cole)
Date: Thu, 07 Oct 2010 12:08:35 +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: <1286453315.68.0.601260258062.issue10043@psf.upfronthosting.co.za>


Steven Samuel Cole <steven.samuel.cole at gmail.com> added the comment:

I'm just a developer, I don't know anything about Python internals or what Python sees or does at what stage.

Looking at the sample file, code executed later has an influence on code executed earlier - and that behavior is unexpected, confusing, bizarre, no matter what expert explanations there are.

It took me a while to isolate this problem, thought I report it here to save others the effort. This should at least be mentioned in the docs somewhere around setattr(...).

I think it is premature to declare this report invalid and close the bug - but hey, if _you_ are not interested in improving Python wherever possible, why would _I_ be ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10043>
_______________________________________

From report at bugs.python.org  Thu Oct  7 14:31:16 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Oct 2010 12:31:16 +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: <1286454676.64.0.0604361872436.issue10043@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It's a well documented behavior.

Surely you ran across this link while researching your problem? http://docs.python.org/reference/executionmodel.html#naming-and-binding
The paragraph beginning "The following constructs bind names ..." describes why setattr does not create a binding, although I'll grant that it doesn't mention setattr by name. The paragraph beginning "If a name binding operation occurs anywhere within a code block ..." explains why the assignment affects code that occurs before the binding.

If you'd like to improve the docs, please suggest a patch.

Also note that you're not creating a local variable with setattr, you're creating a module level (sometimes called global) variable. Perhaps that's part of the misunderstanding? You might want to look into the global (on nonlocal) statement, unless there's some particular reason the name you're creating needs to be dynamically computed.

----------
assignee:  -> docs at python
components: +Documentation -Interpreter Core
nosy: +docs at python
resolution: invalid -> 
stage:  -> needs patch
status: closed -> open
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10043>
_______________________________________

From report at bugs.python.org  Thu Oct  7 14:35:33 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Oct 2010 12:35:33 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286454933.97.0.241028279375.issue10041@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Isn't this just the normal universal newline handling? When you open it in binary mode you see all of the characters, but in text mode (the absence of "b") you get normalized newlines (that is, they're converted to "\n").

----------
components:  -2to3 (2.x to 3.0 conversion tool)
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Thu Oct  7 15:03:52 2010
From: report at bugs.python.org (Steven Samuel Cole)
Date: Thu, 07 Oct 2010 13:03:52 +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: <1286456632.19.0.823797357358.issue10043@psf.upfronthosting.co.za>


Steven Samuel Cole <steven.samuel.cole at gmail.com> added the comment:

thank you very much for the clarification.

i did indeed not come across the page you've linked to, mainly because i did not really know what to google for. actually, i do not recall ever looking into the python language reference in 6+ years of python coding.

googling for 'python UnboundLocalError setattr' returns this bug report as top result at the moment, as your link leads to more indepth information, the main objective of saving / alleviating others the research work seems achieved. i will nonetheless try to make time to get get my head around the python doc conventions and processes and submit a patch.

thanks for pointing out the difference between a local variable and one with module scope. however, it is not relevant for my situation: i have a long list of strings coming in (database column names, not under my influence) which i need to access _like_ a local variable. if you can think of a smarter approach to turn parameter strings into variables of whatever scope, i'm all ears, but i have a feeling that's actually what setattr(...) is meant for.
 
as a quick fix for the UnboundLocalError, sticking to working with module attributes worked for me. instead of changing the value of a dynamically created variable in the conventional way
  my_var = None
(which is where the error occurred in my code), it might help to use setattr(...) even if the variable name is known:
  setattr(modules[__name__], 'my_var', None)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10043>
_______________________________________

From report at bugs.python.org  Thu Oct  7 15:34:26 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 Oct 2010 13:34:26 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286458466.04.0.0822113763513.issue10044@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Arithmetic with void* pointers is not allowed by the Microsoft compilers. char* should be used instead.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 15:50:20 2010
From: report at bugs.python.org (Shashank)
Date: Thu, 07 Oct 2010 13:50:20 +0000
Subject: [issue10030] Patch for zip decryption speedup
In-Reply-To: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>
Message-ID: <1286459420.75.0.676690914371.issue10030@psf.upfronthosting.co.za>


Shashank <shashank.sunny.singh at gmail.com> added the comment:

I have updated the patch with a check for the availability of C impl and to use pure-py impl as a fallback.

How do you suggest would the tests change? As I had mentioned before, in my understanding since there is no change in the API the already existing tests should work.

One can simulate the absence of C impl in a system where it is present but AFAIU this is not what it is usually done (e.g, in the case of optional zlib dependency in the same module)

----------
Added file: http://bugs.python.org/file19149/zipdecrypt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10030>
_______________________________________

From report at bugs.python.org  Thu Oct  7 15:53:40 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 07 Oct 2010 13:53:40 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1286459620.64.0.983930347485.issue10042@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Thu Oct  7 16:44:01 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 07 Oct 2010 14:44:01 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286462641.01.0.678964008535.issue10044@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

How does performance change if you adjust NSMALLPOSINTS and NSMALLNEGINTS, but make no other changes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 17:24:44 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Oct 2010 15:24:44 +0000
Subject: [issue10030] Patch for zip decryption speedup
In-Reply-To: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>
Message-ID: <1286465084.38.0.192472070988.issue10030@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is what is normally done *now* when there is both a C and a python implementation (see, for example, test_datetime.py and test_io.py for two different approaches to that).  Not all tests have been updated to this practice.

Thanks for working on this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10030>
_______________________________________

From report at bugs.python.org  Thu Oct  7 17:49:09 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Oct 2010 15:49:09 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286466549.31.0.652231406906.issue10044@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Looks like a nice idea, at first glance, though I haven't looked at the code in detail.  I like the use of the macros to abstract away the long implementation details.

"INPLACE_SUBTRACT_end", not "INPLACE_SUBSTRACT_end", please!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 17:53:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Oct 2010 15:53:49 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286466829.35.0.619674254513.issue10044@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

+#define _PyLong_IS_SMALL_INT(v) \
+    (((PyLongObject *)(v)) >= _PyLong_small_ints && \
+     ((PyLongObject *)(v)) < _PyLong_SMALL_INTS_END)
+/* These macros purposedly avoid a cast to int, since it is most of time
+   useless, and sometimes detrimental (because of truncation).
+   XXX _PyLong_AS_SMALL_INT might be slower if sizeof(PyLongObject) is not
+   a power of two.
+   */

Urk!  This is nasty.  :(

I don't think arbitrary comparisons of pointers give well-defined results, unless those pointers both happen to point into the same array.  (Might be wrong;  I don't have a copy of the C standard to hand.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 17:53:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 07 Oct 2010 15:53:55 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286466835.32.0.427565011987.issue10029@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As Daniel pointed out, the "equivalent to" code in builtins section comes from 2.x itertools documentation where and equivalent generator definition is presented for each function.  While these definitions are helpful when used for documenting a module oriented towards more advanced users, I doubt that exposing novices who are looking up builtins to the yield keyword and generators is a good idea.  The zip() example is particularly problematic.  Conceptually, zip is a very simple function, but the "equivalent to" code is not easy to decipher.   The reliance on StopIteration exception escaping from map to break out of the infinite loop is clever, but not obvious.  Moreover, as this bug demonstrates, this trick relies on subtle details that changed in 3.x.

I suggest removing the "equivalent to" code from the zip section and replacing it with an example showing how to use zip with a for loop similar to the example illustrating enumerate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10029>
_______________________________________

From report at bugs.python.org  Thu Oct  7 18:00:16 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 07 Oct 2010 16:00:16 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286467216.79.0.633474583586.issue10029@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> I suggest removing the "equivalent to" code from the zip section and
> replacing it with an example showing how to use zip with a for loop
> similar to the example illustrating enumerate.

+1

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10029>
_______________________________________

From report at bugs.python.org  Thu Oct  7 18:13:12 2010
From: report at bugs.python.org (PoltoS)
Date: Thu, 07 Oct 2010 16:13:12 +0000
Subject: [issue8293] HTTPSConnection.close() does not immediately close the
	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1286467992.28.0.0842420190121.issue8293@psf.upfronthosting.co.za>


PoltoS <poltorak at alsenet.com> added the comment:

I've the with module ssl. If I do sock.close() (sock is instance of ssl.SSLSocket), the connection is not closed: I see it as Established in netstat and nothing is sent over network: tcpdump show nothing going thru the network.

Python 2.6.5
Linux Ubuntu

----------
nosy: +PoltoS
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8293>
_______________________________________

From report at bugs.python.org  Thu Oct  7 18:13:52 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Oct 2010 16:13:52 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286468032.44.0.59665579262.issue10044@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Maybe we could consider adding an extra field to a PyLong giving its 'small_int' value for small values, and some flag value for non-small longs.  An extra field wouldn't actually enlarge the size of a PyLong for small values---on a 64-bit machine, a value like 23L takes 28 bytes, for which 32 bytes will actually be allocated (since Python always allocates in multiples of 8 bytes, I believe).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 18:22:18 2010
From: report at bugs.python.org (PoltoS)
Date: Thu, 07 Oct 2010 16:22:18 +0000
Subject: [issue8293] HTTPSConnection.close() does not immediately close the
	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1286468538.01.0.616916291447.issue8293@psf.upfronthosting.co.za>


PoltoS <poltorak at alsenet.com> added the comment:

By the way, doing a sock.shutdown(socket.SHUT_RDWR) with a subsequent sock.close() helps to really close an SSL socket. But this may raise additional errors with subsequent close() since on some OS (like OS X) shutdown may close the socket. Am I right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8293>
_______________________________________

From report at bugs.python.org  Thu Oct  7 18:23:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 16:23:47 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286468032.44.0.59665579262.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286468618.5569.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Maybe we could consider adding an extra field to a PyLong giving its
> 'small_int' value for small values, and some flag value for non-small
> longs.  An extra field wouldn't actually enlarge the size of a PyLong
> for small values---on a 64-bit machine, a value like 23L takes 28
> bytes, for which 32 bytes will actually be allocated (since Python
> always allocates in multiples of 8 bytes, I believe).

I actually had a patch for that. It declared a ob_digit[2] array instead
of ob_digit[1], and ob_digit[1] contained the small int. But the patch
still used the pointer comparison approach for PyLong_IS_SMALL_INT,
because I think it's faster (just two comparisons). So there didn't seem
to much point.

Also, the pointer addition trick for addition (see BINARY_ADD) is
probably faster than the more intuitive method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 18:27:20 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 07 Oct 2010 16:27:20 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286468840.71.0.333993292413.issue10044@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> I don't think arbitrary comparisons of pointers give well-defined
> results, unless those pointers both happen to point into the same
> array.  (Might be wrong;  I don't have a copy of the C standard to
> hand.)

Technically arbitrary relational comparisons of pointers are undefined, but in practice Antoine's assumptions here are very modest.  They boil down to:

   v >= &array[0] && v < &array[array_len]

It is hard for me to imagine a system designed such that the expression  could evaluate to true when v is not in the array.

I suppose a system could be designed where relational comparisons of unrelated data pointers causes a segmentation fault or similar, but that also seems unlikely to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 19:05:50 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 Oct 2010 17:05:50 +0000
Subject: [issue5870] subprocess.DEVNULL
In-Reply-To: <1240946644.39.0.609275389725.issue5870@psf.upfronthosting.co.za>
Message-ID: <1286471150.96.0.058365219333.issue5870@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5870>
_______________________________________

From report at bugs.python.org  Thu Oct  7 19:10:51 2010
From: report at bugs.python.org (Max)
Date: Thu, 07 Oct 2010 17:10:51 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286471451.76.0.119082489793.issue10029@psf.upfronthosting.co.za>


Max <maxmoroz at gmail.com> added the comment:

Personally, I find it impossible in some cases to understand exactly what a function does just from reading a textual description. In those cases, I always refer to the equivalent code if it's given. In fact that's the reason I was looking going the zip equivalent function!

I would feel it's a loss if equivalent code disappear from the docs.

I understand sometimes the code requires maintenance, but I'd rather live with some temporary bugs than lose the equivalent code.

As to subtleties of how it works, that's not really a concern, if that's the only way to understand the precise meaning of whatever it explains.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10029>
_______________________________________

From report at bugs.python.org  Thu Oct  7 19:12:32 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Oct 2010 17:12:32 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286471552.9.0.980213070915.issue10044@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/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 19:37:49 2010
From: report at bugs.python.org (Patrick Strawderman)
Date: Thu, 07 Oct 2010 17:37:49 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>


New submission from Patrick Strawderman <patrick at zope.com>:

cStringIO.StringO's seek method has O(n) characteristics in certain,
albeit pathological, cases, while the pure Python implementation and
cStringIO.StringI's seek methods both execute in constant time in all cases.

When the file offset is set n bytes beyond the end of actual data,
the gap is filled in with n bytes in cStringIO.StringO's seek method.

however, POSIX states that reads of data in the gap will return null bytes
only if a subsequent write has taken place, so filling in the gap is not
required at the time of the seek.

This patch for 2.7 corrects the behavior by unifying StringO and StringI's
seek methods, and moving the writing of null bytes to StringO's write
method.  There may be a more elegant way to write this, I don't know.
I believe this issue affects Python 3 as well, though I have yet to
test it.

NOTE: Perhaps this seems like an extreme edge case not worthy of a fix, but
this actually caused problems for us when parsing images with malformed
EXIF data; a web request for uploading such a photo was taking on the order
of 15 minutes.  When we stopped using cStringIO.StringO, it took seconds.

----------
files: cStringIO.diff
keywords: patch
messages: 118123
nosy: boogenhagn
priority: normal
severity: normal
status: open
title: poor cStringIO.StringO seek performance
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19150/cStringIO.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Thu Oct  7 19:38:19 2010
From: report at bugs.python.org (Patrick Strawderman)
Date: Thu, 07 Oct 2010 17:38:19 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286473099.11.0.156653218912.issue10045@psf.upfronthosting.co.za>


Changes by Patrick Strawderman <patrick at zope.com>:


----------
components: +None
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Thu Oct  7 19:39:02 2010
From: report at bugs.python.org (Patrick Strawderman)
Date: Thu, 07 Oct 2010 17:39:02 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286473142.72.0.620935447307.issue10045@psf.upfronthosting.co.za>


Changes by Patrick Strawderman <patrick at zope.com>:


----------
components:  -None

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Thu Oct  7 19:40:01 2010
From: report at bugs.python.org (Patrick Strawderman)
Date: Thu, 07 Oct 2010 17:40:01 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286473201.03.0.400918020047.issue10045@psf.upfronthosting.co.za>


Patrick Strawderman <patrick at zope.com> added the comment:

The second sentence should have said "the gap is filled in with n null bytes"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Thu Oct  7 19:43:13 2010
From: report at bugs.python.org (Trent Mick)
Date: Thu, 07 Oct 2010 17:43:13 +0000
Subject: [issue2142] difflib.unified_diff(...) produces invalid patches
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1286473393.67.0.650805570104.issue2142@psf.upfronthosting.co.za>


Trent Mick <trentm at gmail.com> added the comment:

c.f. some discussion on python-dev here:
http://mail.python.org/pipermail/python-dev/2010-October/104501.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
_______________________________________

From report at bugs.python.org  Thu Oct  7 20:25:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Oct 2010 18:25:34 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286475934.11.0.33378415749.issue10045@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/issue10045>
_______________________________________

From report at bugs.python.org  Thu Oct  7 20:26:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 07 Oct 2010 18:26:59 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286476019.32.0.0994892731032.issue10045@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm changing the versions to just 2.7 (though I'm not sure this can be considered a bug fix), since StringIO is reimplemented as part of io in 3.x.

----------
nosy: +r.david.murray
versions:  -Python 2.6, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Thu Oct  7 21:23:31 2010
From: report at bugs.python.org (Aahz)
Date: Thu, 07 Oct 2010 19:23:31 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286479411.64.0.158371021979.issue10044@psf.upfronthosting.co.za>


Changes by Aahz <aahz at pythoncraft.com>:


----------
nosy:  -Aahz, aahz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 21:30:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 19:30:55 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286468840.71.0.333993292413.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286479851.3143.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Technically arbitrary relational comparisons of pointers are
> undefined, but in practice Antoine's assumptions here are very modest.
> They boil down to:
> 
>    v >= &array[0] && v < &array[array_len]

I can't say anything about the standard, but p > q looks like it should
be the same as (p - q) > 0, which looks rather well-defined for
pointers.

(at worse we could cast to _Py_uintptr_t, hopefully the compiler
wouldn't produce any different code)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 21:32:15 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Oct 2010 19:32:15 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1286479935.54.0.0465937023428.issue10042@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks, this is a good idea.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10042>
_______________________________________

From report at bugs.python.org  Thu Oct  7 21:37:17 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Oct 2010 19:37:17 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286480237.64.0.444141117326.issue10029@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'll update the docs with an equivalent that works and that has a comment showing when the StopIteration is raised and caught.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10029>
_______________________________________

From report at bugs.python.org  Thu Oct  7 22:25:08 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 07 Oct 2010 20:25:08 +0000
Subject: [issue7285] multiprocessing module, example code error
In-Reply-To: <1257647520.68.0.169575152715.issue7285@psf.upfronthosting.co.za>
Message-ID: <1286483108.46.0.803937492418.issue7285@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
i've verified that the problem still exists in an up-to-date py3k branch, and that the proposed patch indeed fixes the bug.

Since the patch no more applies cleanly, I've refreshed it, and also added additional information about authkey that it must be a byte string.

Regards,
Sandro

----------
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19151/issue7285-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7285>
_______________________________________

From report at bugs.python.org  Thu Oct  7 22:29:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 20:29:22 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286483362.84.0.406683510893.issue10044@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> How does performance change if you adjust NSMALLPOSINTS and
> NSMALLNEGINTS, but make no other changes?

It makes a very small difference (which is understandable since it doesn't cut down on code execution a lot).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:00:38 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Oct 2010 21:00:38 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286485238.28.0.948908067086.issue10044@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Technically arbitrary relational comparisons of pointers are undefined,
> but in practice Antoine's assumptions here are very modest.

I disagree:  there's a very real practical danger here.  Namely, optimizing compilers are free to assume that code doesn't involve any undefined behaviour and optimize accordingly.  gcc for one is known to make extensive use of this freedom.  I wouldn't be at all surprised to find some current or future version of gcc optimizing an (p >= start_of_array) check to 'always true', on the basis that it *will* always be true in legal code.

Please don't introduce undefined behaviour here---it's asking for trouble.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:04:02 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Oct 2010 21:04:02 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286485442.93.0.345929097918.issue10044@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> I can't say anything about the standard, but p > q looks like it should
> be the same as (p - q) > 0

Yep.

> which looks rather well-defined for pointers.

Nope.  It's only well-defined for pointers pointing into the same array (or to one past the end of an array).  Otherwise it's undefined behaviour.

See section 6.5.6, paragraph 9, of

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:11:28 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 07 Oct 2010 21:11:28 +0000
Subject: [issue6417] multiprocessing Process examples: print and getppid
In-Reply-To: <1246719525.24.0.54072257834.issue6417@psf.upfronthosting.co.za>
Message-ID: <1286485888.31.0.173649026059.issue6417@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
indentation problem has been fixed in r79901 and py3k syntax has been fixed in r74764.

wrt os.getppid(), in the documentation it's stated that with 3.2 it added support for windows too: I'd like someone running a windows box (I don't have a win system anywhere near to me) to check if the mp example works correctly as it is.

Regards,
Sandro

----------
nosy: +sandro.tosi
versions: +Python 3.2 -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6417>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:12:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 21:12:25 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286485442.93.0.345929097918.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286485942.3143.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Nope.  It's only well-defined for pointers pointing into the same
> array (or to one past the end of an array).  Otherwise it's undefined
> behaviour.

How can the compiler tell whether two pointers are "into the same
array"? That sounds like an undecidable criterion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:14:37 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Oct 2010 21:14:37 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286486077.92.0.189281112915.issue10044@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> How can the compiler tell whether two pointers are "into the same
> array"? That sounds like an undecidable criterion.

It doesn't have to be able to tell---it's allowed to assume.  :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:15:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 21:15:31 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286486077.92.0.189281112915.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286486128.3143.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > How can the compiler tell whether two pointers are "into the same
> > array"? That sounds like an undecidable criterion.
> 
> It doesn't have to be able to tell---it's allowed to assume.  :-)

That doesn't very clear or understandable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:18:57 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 07 Oct 2010 21:18:57 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286486337.22.0.410841281198.issue10044@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

In the bad old days of 386 segment:offset memory architectures this was a problem. You could have overlapping segments but pointers inside an object were always in the same segment, so the segment selectors never had to be inspected. Pointers to different objects could indeed have the same offset and would compare equal.

We should follow the standard here: no comparisons between pointers to different arrays (basically).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:22:03 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Oct 2010 21:22:03 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286486523.86.0.587248442341.issue10044@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See the example above:  suppose that a compiler is looking at a (p >= q) comparison of pointers.  Suppose furthermore that in a particular case that compiler is smart enough to figure out that q is a pointer to the start of an array.  Then the compiler is *permitted to assume* that p also points into the same array, since if it didn't then the code would introduce undefined behaviour.  And since q is the start of the array, and p is (by assumption) a pointer into the same array, p >= q will automatically be true, so the compiler is free to replace the expression with the integer '1' (i.e., true).

gcc does similar things with checks like (x + 1 > x):  if x is a (signed) int, then gcc can and will optimize (x + 1 > x) to 'true', on the basis that x + 1 can never overflow, because such overflow would be undefined behaviour and therefore can't occur in a valid C program.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:29:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 21:29:39 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286486337.22.0.410841281198.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286486974.3143.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In the bad old days of 386 segment:offset memory architectures this
> was a problem. You could have overlapping segments but pointers inside
> an object were always in the same segment, so the segment selectors
> never had to be inspected. Pointers to different objects could indeed
> have the same offset and would compare equal.

AFAIK it caused lots of other problems much more annoying than just
pointer compares, and programmers had to juggle by hand with various
addressing modes (near, far, etc.).

ISTM that all C programs nowadays assume some kind of flat, paged memory
model, CPython included; I don't think we have to fear some i386-like
segmentation model.

> We should follow the standard here: no comparisons between pointers to
> different arrays (basically).

Again, what is an "array" supposed to be? In memory there are no
"arrays".

Let's say I have the following function in a module:

int ptr_compare(char *a, char *b)
{
   return a > b;
}

and another module, the following function

int foo()
{
    static char x[5];
    static char y[6];
    return ptr_compare(x + 2, y + 3);
}

How is the compiler supposed to know whether a and b belong to the same
array when compiling ptr_compare?

Otherwise, we could cast to Py_uintptr_t.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:34:55 2010
From: report at bugs.python.org (Jason Baker)
Date: Thu, 07 Oct 2010 21:34:55 +0000
Subject: [issue10046] Correction to atexit documentation
In-Reply-To: <1286487295.44.0.431847380909.issue10046@psf.upfronthosting.co.za>
Message-ID: <1286487295.44.0.431847380909.issue10046@psf.upfronthosting.co.za>


New submission from Jason Baker <amnorvend at gmail.com>:

There's an issue with the documentation on the atexit module[1].  It states:

"Note: the functions registered via this module are not called when the program is killed by a signal, when a Python fatal internal error is detected, or when os._exit() is called."

This isn't necessarily true.  For instance, if I start the following script:

from atexit import register
from time import sleep

@register
def end():
    print 'atexit'

while True:
    sleep(1)

...and then do a "kill -SIGINT <pid>", the atexit function gets called.  It would be helpful to have a more detailed description of the rules on how this works.

[1] http://docs.python.org/library/atexit.html#module-atexit

----------
assignee: docs at python
components: Documentation
messages: 118141
nosy: Jason.Baker, docs at python
priority: normal
severity: normal
status: open
title: Correction to atexit documentation
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10046>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:36:32 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Oct 2010 21:36:32 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286487392.97.0.352339214859.issue10044@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> How is the compiler supposed to know whether a and b belong to the same
> array when compiling ptr_compare?

It doesn't need to know.  So long as the compiler can guarantee that its code will produce correct results in the case that a and b *do* both point to the same array, that's enough.  In other words, when producing code for ptr_compare, the compiler is allowed to *assume* that a and b point into the same array, and act accordingly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:38:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 21:38:46 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286486523.86.0.587248442341.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286487519.3143.22.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> See the example above:  suppose that a compiler is looking at a (p >=
> q) comparison of pointers.  Suppose furthermore that in a particular
> case that compiler is smart enough to figure out that q is a pointer
> to the start of an array.

Which array? You can have arrays everywhere in memory, at any address,
ending anywhere.

union {
   struct {
      char ch1;
      char arr1[2];
   }
   struct {
      char arr2[2];
      char ch2;
   }
   struct {
      char arr3[3];
   }
}

Which is an array, and which is not? is &ch1 an array? and arr1? and
arr2+1? Why would the compiler choose one over another? And what about
arrays defined in other modules?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:40:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 21:40:58 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286487392.97.0.352339214859.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286487653.3143.24.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> In other words, when producing code for ptr_compare, the compiler is
> allowed to *assume* that a and b point into the same array, and act
> accordingly.

But this assumption doesn't bring *anything*, right?
That is, there is no shortcut way to compute "p - q" or "p > q" when
both point into the same "array".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Thu Oct  7 23:47:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 21:47:51 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286488071.78.0.608554903293.issue10044@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, a Py_uintptr_t version works and has the same performance. Would you agree to it or is there still some menacing oddity from the i386 days lurking around?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Fri Oct  8 00:03:48 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Oct 2010 22:03:48 +0000
Subject: [issue10044] small int optimization
In-Reply-To: <1286452590.11.0.255060275257.issue10044@psf.upfronthosting.co.za>
Message-ID: <1286489028.95.0.0275163417486.issue10044@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> For the record, a Py_uintptr_t version works and has the same
> performance. Would you agree to it or is there still some menacing 
> oddity from the i386 days lurking around?

Technically, it's still dodgy:  as the gcc manual notes in:

http://gcc.gnu.org/onlinedocs/gcc/Arrays-and-pointers-implementation.html#Arrays-and-pointers-implementation

". That is, one may not use integer arithmetic to avoid the undefined behavior of pointer arithmetic as proscribed in C99 6.5.6/8."

I can't see as much scope for problems with the uintptr_t version.  But just because I can't anticipate the problems, it doesn't mean they don't exist.

It really would be better to avoid the undefined behaviour if at all possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10044>
_______________________________________

From report at bugs.python.org  Fri Oct  8 00:31:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 22:31:03 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286490663.95.0.78047950976.issue10045@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think there's much point in fixing this. 2.7 users can use io.BytesIO, which is a fast type implemented in C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Fri Oct  8 00:32:19 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 07 Oct 2010 22:32:19 +0000
Subject: [issue6825] Minor documentation bug with os.path.split
In-Reply-To: <1251923724.11.0.872695091666.issue6825@psf.upfronthosting.co.za>
Message-ID: <1286490739.0.0.54307003901.issue6825@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
I find the proposed text change good, and so here's a patch to add that in a bit different format (sorry it's quite of a mess, but I took the occasion to wrap that paragraph to 80th column).

Regards,
Sandro

----------
keywords: +patch
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19152/issue6825-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6825>
_______________________________________

From report at bugs.python.org  Fri Oct  8 00:34:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Oct 2010 22:34:30 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286490870.97.0.920642421985.issue10041@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As Eric said. Please see the socket.makefile doc:

?Return a file object associated with the socket. The exact returned type depends on the arguments given to makefile(). These arguments are interpreted the same way as by the built-in open() function.?

(http://docs.python.org/py3k/library/socket.html#socket.socket.makefile)

And in turn, the built-in open() function des cribes the `newline` parameters, which sets whether newline characters are translated.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Fri Oct  8 00:51:28 2010
From: report at bugs.python.org (Thomas Klausner)
Date: Thu, 07 Oct 2010 22:51:28 +0000
Subject: [issue10047] python-2.6.6 coredump running newspipe
In-Reply-To: <1286491888.31.0.583289344322.issue10047@psf.upfronthosting.co.za>
Message-ID: <1286491888.31.0.583289344322.issue10047@psf.upfronthosting.co.za>


New submission from Thomas Klausner <tk at giga.or.at>:

I'm running newspipe-1.1.9, an RSS reader
(http://newspipe.sourceforge.net/), on NetBSD-5.99.11/amd64 using
Python-2.6.6.

Sometimes, it core dumps with particular feeds in the configuration (I
guess depending on the feed, because when I comment out the offending
feed in the opml file, it runs through to completion).

The backtrace looks like this:
Core was generated by `python'.
Program terminated with signal 10, Bus error.
#0  0x00007f7ffdc35a21 in PyOS_snprintf (str=0x7f7ff5dfe3d8 "@", size=120, format=0x1 <Address 0x1 out of bounds>) at Python/mysnprintf.c:43
43      {
(gdb) bt
#0  0x00007f7ffdc35a21 in PyOS_snprintf (str=0x7f7ff5dfe3d8 "@", size=120, format=0x1 <Address 0x1 out of bounds>) at Python/mysnprintf.c:43
#1  0x00007f7ffdc471a6 in PyOS_ascii_formatd (buffer=0x7f7ff5dfe3d8 "@", buf_size=120, format=0x7f7ff5dfe388 "%.2f", d=0.15256118774414062) at Python/pystrtod.c:455
#2  0x00007f7ffdbaa7fa in formatfloat (buf=0x7f7ff5dfe3d8 "@", buflen=120, flags=16, prec=2, type=102, v=0x7f7ffcc6d510) at Objects/stringobject.c:4378
#3  0x00007f7ffdbabd32 in PyString_Format (format=0x7f7ffc8144e0, args=0x7f7ffcc6d510) at Objects/stringobject.c:4943
#4  0x00007f7ffdbaa3b0 in string_mod (v=0x7f7ffc8144e0, w=0x7f7ffcc6d510) at Objects/stringobject.c:4116
#5  0x00007f7ffdb459db in binary_op1 (v=0x7f7ffc8144e0, w=0x7f7ffcc6d510, op_slot=32) at Objects/abstract.c:917
#6  0x00007f7ffdb45c81 in binary_op (v=0x7f7ffc8144e0, w=0x7f7ffcc6d510, op_slot=32, op_name=0x7f7ffdc6c089 "%") at Objects/abstract.c:969
#7  0x00007f7ffdb467ad in PyNumber_Remainder (v=0x7f7ffc8144e0, w=0x7f7ffcc6d510) at Objects/abstract.c:1221
#8  0x00007f7ffdc08a03 in PyEval_EvalFrameEx (f=0x7f7fefa1dab0, throwflag=0) at Python/ceval.c:1180
#9  0x00007f7ffdc1175f in fast_function (func=0x7f7ff8a9bed8, pp_stack=0x7f7ff5dfeae8, n=1, na=1, nk=0) at Python/ceval.c:3836
#10 0x00007f7ffdc11565 in call_function (pp_stack=0x7f7ff5dfeae8, oparg=1) at Python/ceval.c:3771
#11 0x00007f7ffdc0d81f in PyEval_EvalFrameEx (f=0x7f7fee920420, throwflag=0) at Python/ceval.c:2412
#12 0x00007f7ffdc0f715 in PyEval_EvalCodeEx (co=0x7f7ffcc247b0, globals=0x7f7ffd1c5880, locals=0x0, args=0x7f7ff5b0aac8, argcount=8, kws=0x7f7ff5b0ab08, kwcount=0, defs=0x7f7ff8d3c4e8,
    defcount=5, closure=0x0) at Python/ceval.c:3000
#13 0x00007f7ffdc1184a in fast_function (func=0x7f7ff8a9cc80, pp_stack=0x7f7ff5dfeff8, n=8, na=8, nk=0) at Python/ceval.c:3846
#14 0x00007f7ffdc11565 in call_function (pp_stack=0x7f7ff5dfeff8, oparg=7) at Python/ceval.c:3771
#15 0x00007f7ffdc0d81f in PyEval_EvalFrameEx (f=0x7f7ff5b0a820, throwflag=0) at Python/ceval.c:2412
#16 0x00007f7ffdc1175f in fast_function (func=0x7f7ff8a9e140, pp_stack=0x7f7ff5dff358, n=1, na=1, nk=0) at Python/ceval.c:3836
#17 0x00007f7ffdc11565 in call_function (pp_stack=0x7f7ff5dff358, oparg=0) at Python/ceval.c:3771
#18 0x00007f7ffdc0d81f in PyEval_EvalFrameEx (f=0x7f7ff5b0a420, throwflag=0) at Python/ceval.c:2412
#19 0x00007f7ffdc1175f in fast_function (func=0x7f7ffca1db90, pp_stack=0x7f7ff5dff6b8, n=1, na=1, nk=0) at Python/ceval.c:3836
#20 0x00007f7ffdc11565 in call_function (pp_stack=0x7f7ff5dff6b8, oparg=0) at Python/ceval.c:3771
#21 0x00007f7ffdc0d81f in PyEval_EvalFrameEx (f=0x7f7ff5b03190, throwflag=0) at Python/ceval.c:2412
#22 0x00007f7ffdc0f715 in PyEval_EvalCodeEx (co=0x7f7ffca0d4e0, globals=0x7f7ffca473a0, locals=0x0, args=0x7f7ff04d3e68, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
    at Python/ceval.c:3000
#23 0x00007f7ffdb7a612 in function_call (func=0x7f7ffca1daa0, arg=0x7f7ff04d3e50, kw=0x0) at Objects/funcobject.c:524
#24 0x00007f7ffdb495e8 in PyObject_Call (func=0x7f7ffca1daa0, arg=0x7f7ff04d3e50, kw=0x0) at Objects/abstract.c:2492
#25 0x00007f7ffdb5eca0 in instancemethod_call (func=0x7f7ffca1daa0, arg=0x7f7ff04d3e50, kw=0x0) at Objects/classobject.c:2579
#26 0x00007f7ffdb495e8 in PyObject_Call (func=0x7f7ff8ac2a00, arg=0x7f7ffd112050, kw=0x0) at Objects/abstract.c:2492
#27 0x00007f7ffdc10cd3 in PyEval_CallObjectWithKeywords (func=0x7f7ff8ac2a00, arg=0x7f7ffd112050, kw=0x0) at Python/ceval.c:3619
#28 0x00007f7ffdc4e69f in t_bootstrap (boot_raw=0x7f7ffd1b4590) at ./Modules/threadmodule.c:428
#29 0x00007f7ffd90ba32 in pthread_setcancelstate () from /usr/lib/libpthread.so.1
#30 0x00007f7ffd26e9b0 in ___lwp_park50 () from /usr/lib/libc.so.12
#31 0x0000000000000000 in ?? ()
(gdb) fr 1
#1  0x00007f7ffdc471a6 in PyOS_ascii_formatd (buffer=0x7f7ff5dfe3d8 "@", buf_size=120, format=0x7f7ff5dfe388 "%.2f", d=0.15256118774414062) at Python/pystrtod.c:455
455         PyOS_snprintf(buffer, buf_size, format, d);
(gdb) l
450             format = tmp_format;
451         }
452
453
454         /* Have PyOS_snprintf do the hard work */
455         PyOS_snprintf(buffer, buf_size, format, d);
456
457         /* Do various fixups on the return string */
458
459         /* Get the current locale, and find the decimal point string.
(gdb) p format
$1 = 0x7f7ff5dfe388 "%.2f"
(gdb) fr 0
#0  0x00007f7ffdc35a21 in PyOS_snprintf (str=0x7f7ff5dfe3d8 "@", size=120, format=0x1 <Address 0x1 out of bounds>) at Python/mysnprintf.c:43
43      {
(gdb) l
38         CAUTION:  Unlike C99, str != NULL and size > 0 are required.
39      */
40
41      int
42      PyOS_snprintf(char *str, size_t size, const  char  *format, ...)
43      {
44          int rc;
45          va_list va;
46
47          va_start(va, format);
(gdb)

It seems that the format argument is corrupted while calling PyOS_snprintf.

Any ideas what could cause this or how to fix this?

----------
components: Interpreter Core
messages: 118150
nosy: wiz
priority: normal
severity: normal
status: open
title: python-2.6.6 coredump running newspipe
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10047>
_______________________________________

From report at bugs.python.org  Fri Oct  8 01:11:00 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Oct 2010 23:11:00 +0000
Subject: [issue10014] sys.path[0] is incorrect if PYTHONFSENCODING is used
In-Reply-To: <1286021663.34.0.689026258035.issue10014@psf.upfronthosting.co.za>
Message-ID: <1286493060.79.0.976331221817.issue10014@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I just created Python/fileutils.c: update the patch for this new file.

----------
Added file: http://bugs.python.org/file19153/realpath_fs_encoding-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10014>
_______________________________________

From report at bugs.python.org  Fri Oct  8 01:11:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Oct 2010 23:11:05 +0000
Subject: [issue10014] sys.path[0] is incorrect if PYTHONFSENCODING is used
In-Reply-To: <1286021663.34.0.689026258035.issue10014@psf.upfronthosting.co.za>
Message-ID: <1286493065.26.0.706865144794.issue10014@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file19147/realpath_fs_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10014>
_______________________________________

From report at bugs.python.org  Fri Oct  8 01:40:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Oct 2010 23:40:08 +0000
Subject: [issue6612] 'import site' fails when called from an unlinked directory
In-Reply-To: <1249034007.06.0.695800326888.issue6612@psf.upfronthosting.co.za>
Message-ID: <1286494808.39.0.856497651389.issue6612@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

There was a bug in copy_absolute(): if _Py_wgetcwd() failed, the result was undefined (depending of the content of "path" buffer). Especially, absolutize() calls copy_absolute() with a buffer allocated on the stack: the content of this buffer depends on the undefined content of the stack.

Fixed in Python 3.2 (r85309+r85311), 2.7 (r85312) and 3.1 (r85313).

copy_absolute() is used (by calculate_path()) to fill sys.path.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6612>
_______________________________________

From report at bugs.python.org  Fri Oct  8 01:52:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 07 Oct 2010 23:52:02 +0000
Subject: [issue6612] 'import site' fails when called from an unlinked directory
In-Reply-To: <1249034007.06.0.695800326888.issue6612@psf.upfronthosting.co.za>
Message-ID: <1286495522.04.0.0258844338764.issue6612@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

deleted_cwd.patch, patch based on labrat's patch updated to py3k:
http://www.physics.drexel.edu/~wking/code/hg/hgwebdir.cgi/python/rev/77f3ad10ba45

Procedure to test the patch:
 - go into Python source tree
 - make a directory "z"
 - enter z directory
 - delete the z directory (in another terminal)
 - run ../python

----------
Added file: http://bugs.python.org/file19154/deleted_cwd.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6612>
_______________________________________

From report at bugs.python.org  Fri Oct  8 02:52:58 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 Oct 2010 00:52:58 +0000
Subject: [issue4907] ast.literal_eval does not properly handled complex numbers
In-Reply-To: <1231602302.94.0.22786815912.issue4907@psf.upfronthosting.co.za>
Message-ID: <1286499178.36.0.196391189211.issue4907@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed handling on unary minus in r85314.  In so doing, it also liberalized what literal_eval() accepts (3j+4 for example). This simplified the implementation and removed an unnecessary restriction which wasn't needed for "safety".

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4907>
_______________________________________

From report at bugs.python.org  Fri Oct  8 03:27:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Oct 2010 01:27:13 +0000
Subject: [issue10046] Correction to atexit documentation
In-Reply-To: <1286487295.44.0.431847380909.issue10046@psf.upfronthosting.co.za>
Message-ID: <1286501233.84.0.473119245089.issue10046@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It is possible this behavior changed after the docs were written.  I'm adding a couple of people to nosy who might have some insight into that possibility.  It could be either a change in finalization procedures or a change in signal handling semantics, I think.

----------
nosy: +Rhamphoryncus, pitrou, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10046>
_______________________________________

From report at bugs.python.org  Fri Oct  8 03:43:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Oct 2010 01:43:21 +0000
Subject: [issue10047] python-2.6.6 coredump running newspipe
In-Reply-To: <1286491888.31.0.583289344322.issue10047@psf.upfronthosting.co.za>
Message-ID: <1286502201.68.0.49748079727.issue10047@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Indeed, newspipe appears to be a pure python package, so this looks like it is probably a bug in python somewhere.

You might want to report it to newspipe too, though.  They are likely to be able to figure out how to reduce the problem to a minimum cause faster than we are.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10047>
_______________________________________

From report at bugs.python.org  Fri Oct  8 03:45:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Oct 2010 01:45:48 +0000
Subject: [issue10047] python-2.6.6 coredump running newspipe
In-Reply-To: <1286491888.31.0.583289344322.issue10047@psf.upfronthosting.co.za>
Message-ID: <1286502348.84.0.873410637466.issue10047@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Can you reproduce this using python2.7?  Python 2.6 is in security fix only mode now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10047>
_______________________________________

From report at bugs.python.org  Fri Oct  8 04:38:28 2010
From: report at bugs.python.org (Adam Olsen)
Date: Fri, 08 Oct 2010 02:38:28 +0000
Subject: [issue10046] Correction to atexit documentation
In-Reply-To: <1286487295.44.0.431847380909.issue10046@psf.upfronthosting.co.za>
Message-ID: <1286505508.03.0.802549911877.issue10046@psf.upfronthosting.co.za>


Adam Olsen <rhamph at gmail.com> added the comment:

Signals can directly kill a process.  Try SIGTERM to see this.  SIGINT is caught and handled by Python, which just happens to default to a graceful exit (unless stuck in a lib that prevents that.)  Try pasting your script into an interactive interpreter session and you'll see that it doesn't exit at all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10046>
_______________________________________

From report at bugs.python.org  Fri Oct  8 04:46:20 2010
From: report at bugs.python.org (Evan Driscoll)
Date: Fri, 08 Oct 2010 02:46:20 +0000
Subject: [issue6825] Minor documentation bug with os.path.split
In-Reply-To: <1251923724.11.0.872695091666.issue6825@psf.upfronthosting.co.za>
Message-ID: <1286505980.96.0.454889101258.issue6825@psf.upfronthosting.co.za>


Evan Driscoll <evaned at gmail.com> added the comment:

Hah, I totally forgot about this thing.

I'd suggest a change to the proposed patch. The patched version says:

  "In nearly all cases, ``join(head, tail)`` returns a location
   equivalent to *path* (the only exception being when there were 
   multiple slashes separating *head* from *tail*)."

Except now the parenthetical remark at the end of that sentence is a bit weird, because "a//a" != "a/a" is no longer an exception.

I'd suggest a wording such as one of the following, depending on where you want the emphasis (on the meaning of the return value of a path or on the actual contents of the return value as a string):

  "In all cases, ``join(head, tail)`` returns a location equivalent
   to *path*."

  "In most cases, ``join(head, tail)`` equals *path*; the
   exceptions to this are when there were multiple slashes
   separating *head* from *tail* or when *os.altsep* separators
   are replaced by *os.sep*."

The first suggestion could be followed by a remark "(but the strings may be unequal)" if you'd like.

I'd also replace "a location equivalent to" with "a path to the same location as" or something like that; "location" doesn't appear anywhere else on that page, and it seems slightly out of place to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6825>
_______________________________________

From report at bugs.python.org  Fri Oct  8 05:07:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Oct 2010 03:07:02 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286507222.15.0.588422072767.issue4661@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is an updated patch incorporating the reitveld feedback and feedback from python-dev about the API.  Now we have BytesParser instead of Parser with a parsebytes method, and a message_from_binary_file helper.  Generator also now converts bodies with an 8bit CTE into bodies with an appropriate 7bit coding.

Things still to do: (1) Add the (documented in this patch) BytesFeedParser class. (2) Figure out how to encode unknown bytes using the 'unknown' MIME charset in headers instead of replacing them with '?'s.  (3) Once I land a revised patch for issue 6302, add a flag to DecodedGenerator to have it fully decode headers.

I'd like to land this patch before Alpha3 if possible, so I'm setting it to release blocker for Georg to decide whether or not that is possible.  I'll complete the work in subsequent patches after the alpha, but everything needed to test the patch in field conditions is already present.

Georg, feel free to knock down the priority right away if you don't think it is ready or don't want to take time to even decide if it is ready :)

----------
priority: high -> release blocker
Added file: http://bugs.python.org/file19155/email_parse_bytes7.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Fri Oct  8 05:24:47 2010
From: report at bugs.python.org (kai zhu)
Date: Fri, 08 Oct 2010 03:24:47 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286508287.93.0.0400254171427.issue10041@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

my bad for not rtfm, but it seems the newline argument has no effect in socket.makefile.

the TextIOWrapper signatures don't seem to match.  a hack to put newline parameter in 4th position or making it a keyword arg doesn't work either (scratch my head...)

socket.py source <line 162>
        text = io.TextIOWrapper(buffer, encoding, newline)

textio.c <line 807>
static int
textiowrapper_init(textio *self, PyObject *args, PyObject *kwds)
{
    char *kwlist[] = {"buffer", "encoding", "errors",
                      "newline", "line_buffering",
                      NULL};




$ python3 echo.py ## from previous example

$ python3 client.py 
b'hello\r\n' recv()
b'hello\r\n' makefile(mode = "rb")
'hello\n' makefile(mode = "r", newline = "")



# echo client program
data = b'hello\r\n'
import socket
clie = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
try:
  clie.connect(('localhost', 12345))

  clie.send(data)
  data = clie.recv(4096)
  print(repr(data), 'recv()')

  clie.send(data)
  file = clie.makefile('rb')
  data = file.readline()
  print(repr(data), 'makefile(mode = "rb")')

  clie.send(data)
  file = clie.makefile('r', newline = '')
  data = file.readline()
  print(repr(data), 'makefile(mode = "r", newline = "")') ## '\r' is still silently dropped
finally:
  clie.close()

----------
resolution: invalid -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Fri Oct  8 05:31:25 2010
From: report at bugs.python.org (kai zhu)
Date: Fri, 08 Oct 2010 03:31:25 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286508685.4.0.991804757985.issue10041@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

my bad again, hacking newline parameter to the correct argument position works (its in the position where error should b).

a one line patch would be:

socket.py <line 163>
-        text = io.TextIOWrapper(buffer, encoding, newline)
+        text = io.TextIOWrapper(buffer, encoding, newline = newline)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Fri Oct  8 06:07:22 2010
From: report at bugs.python.org (kai zhu)
Date: Fri, 08 Oct 2010 04:07:22 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286510842.66.0.723356612796.issue10041@psf.upfronthosting.co.za>


Changes by kai zhu <kaizhu256 at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19156/socket.makefile.newline.kwarg.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Fri Oct  8 06:37:29 2010
From: report at bugs.python.org (kiorky)
Date: Fri, 08 Oct 2010 04:37:29 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1286512649.04.0.700698777555.issue1777412@psf.upfronthosting.co.za>


kiorky <kiorky at cryptelium.net> added the comment:

This patch doesnt apply anymore on py26.
Joining an updated patch.

----------
Added file: http://bugs.python.org/file19157/strftime-pre-1900.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Fri Oct  8 06:47:06 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 08 Oct 2010 04:47:06 +0000
Subject: [issue10040] GZipFile failure on large files
In-Reply-To: <1286416633.51.0.196300487006.issue10040@psf.upfronthosting.co.za>
Message-ID: <1286513226.26.0.222394712138.issue10040@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Since you mention 7-zip, does that mean you are seeing the problem on a Windows platform?  If so, exactly which version of Windows and what kind of system?  Also, unless someone recognizes this as a duplicate of an earlier issue, there may not be much action on it unless you can supply a test case to reproduce the problem.

----------
components: +Windows -Library (Lib)
nosy: +ned.deily
stage:  -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10040>
_______________________________________

From report at bugs.python.org  Fri Oct  8 08:36:31 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 Oct 2010 06:36:31 +0000
Subject: [issue10046] Correction to atexit documentation
In-Reply-To: <1286487295.44.0.431847380909.issue10046@psf.upfronthosting.co.za>
Message-ID: <1286519791.3.0.657024928531.issue10046@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

One could also argue that on SIGINT, the program is not "killed" but "interrupted" by the signal :)

What about "... killed by an unhandled signal ..."?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10046>
_______________________________________

From report at bugs.python.org  Fri Oct  8 09:35:38 2010
From: report at bugs.python.org (Bob Ippolito)
Date: Fri, 08 Oct 2010 07:35:38 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1286523338.58.0.223115569272.issue10019@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

The test in the patch assumes a specific iteration order for the dict "h", changing the dict to have only one key would fix this problem with the test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10019>
_______________________________________

From report at bugs.python.org  Fri Oct  8 09:39:05 2010
From: report at bugs.python.org (Bob Ippolito)
Date: Fri, 08 Oct 2010 07:39:05 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1286523545.67.0.591791711258.issue10019@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

The test also repeats an equivalent dict to "h" in the check function.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10019>
_______________________________________

From report at bugs.python.org  Fri Oct  8 09:44:58 2010
From: report at bugs.python.org (Bob Ippolito)
Date: Fri, 08 Oct 2010 07:44:58 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1286523898.41.0.566981609924.issue10019@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

I just applied a version of this patch with corrections to the tests here:
http://code.google.com/p/simplejson/source/detail?r=234

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10019>
_______________________________________

From report at bugs.python.org  Fri Oct  8 09:52:19 2010
From: report at bugs.python.org (Robert Rohde)
Date: Fri, 08 Oct 2010 07:52:19 +0000
Subject: [issue10040] GZipFile failure on large files
In-Reply-To: <1286416633.51.0.196300487006.issue10040@psf.upfronthosting.co.za>
Message-ID: <1286524339.79.0.00819288161729.issue10040@psf.upfronthosting.co.za>


Robert Rohde <rohde at robertrohde.com> added the comment:

It's Windows 7 Ultimate (64-bit) on a very high end system.

I don't think it would be very practical to distribute a 2 GB test file.  Though I might be able to get it to a couple people if someone wanted to really study the issue.

Though if it is an integer overflow (or something like that), then I would suspect that GZipFile would show corruption most of the time once the files got large enough.  For example, it might occur for all files expanding to larger than 2^32 bytes (4 GB).  (That's just speculation, I haven't tested it except to note that it failed the very first time I tried to use a file this large.)

Perhaps someone familiar with the code could look for places where integers might overflow?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10040>
_______________________________________

From report at bugs.python.org  Fri Oct  8 11:47:33 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 08 Oct 2010 09:47:33 +0000
Subject: [issue9978] Better wait for slow machine in test_os (_kill_with_event)
In-Reply-To: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>
Message-ID: <1286531253.53.0.618856667254.issue9978@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you. Committed in r85315(py3k), r85318(release27-maint).

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9978>
_______________________________________

From report at bugs.python.org  Fri Oct  8 11:52:45 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 08 Oct 2010 09:52:45 +0000
Subject: [issue9978] Better wait for slow machine in test_os (_kill_with_event)
In-Reply-To: <1285715640.05.0.77400346639.issue9978@psf.upfronthosting.co.za>
Message-ID: <1286531565.18.0.445606642378.issue9978@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I modified the patch slightly to avoid potential hang.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9978>
_______________________________________

From report at bugs.python.org  Fri Oct  8 11:55:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 09:55:04 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286531704.35.0.672412372073.issue10041@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ah, sorry for closing, then. You are right, this is a genuine issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Fri Oct  8 11:59:11 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 08 Oct 2010 09:59:11 +0000
Subject: [issue10047] python-2.6.6 coredump running newspipe
In-Reply-To: <1286491888.31.0.583289344322.issue10047@psf.upfronthosting.co.za>
Message-ID: <1286531951.44.0.387661102803.issue10047@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Can you reproduce it by executing this?

>>> format(0.15256118774414062, ".2f")

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10047>
_______________________________________

From report at bugs.python.org  Fri Oct  8 12:11:57 2010
From: report at bugs.python.org (umaxx)
Date: Fri, 08 Oct 2010 10:11:57 +0000
Subject: [issue1708] improvements for linecache
In-Reply-To: <1199024318.28.0.602984080184.issue1708@psf.upfronthosting.co.za>
Message-ID: <1286532717.95.0.992926263436.issue1708@psf.upfronthosting.co.za>


umaxx <mail at umaxx.net> added the comment:

@BreamoreBoy: what do you man by taking this forward?

The patch is there. Since three years now, no one else seems to be interested.

I personally do not have any interest in this anymore as I just do not use Python for this stuff anymore since a long time now too, so I do not care if Python linecache is going to be improved or not.

IMHO, such things like slow linecache could be the reason for people to switch to languages with faster String-Operations and Caches like Perl.

If you like just close the bug report or commit the patch or whatever - I do not care anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708>
_______________________________________

From report at bugs.python.org  Fri Oct  8 12:19:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 10:19:39 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286533179.13.0.604170635253.issue4661@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There are a couple of things I don't understand:

+* :class:`~email.generator.Generator` will convert message bodies that
+  have a :mailheader:`ContentTransferEncoding` of 8bit and a known charset to
+  instead have a :mailheader:`CotnentTransferEncoding` of ``QuotedPrintable``.

Why so?

+* All operations are on unicode strings.  Text inputs must be strings,
+  text outputs are strings.

This is a rather strange statement given that you are adding bytes-consuming and bytes-producing functions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Fri Oct  8 12:38:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 10:38: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: <1286534301.22.0.251958629396.issue1589@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I wanted to go forward with this and so I've committed the patch in r85321. If you're concerned about the lack of support for IP addresses, you can open a new issue (and even provide a patch!). Thank you.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Fri Oct  8 12:42:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 10:42:29 +0000
Subject: [issue10040] GZipFile failure on large files
In-Reply-To: <1286416633.51.0.196300487006.issue10040@psf.upfronthosting.co.za>
Message-ID: <1286534549.09.0.383119859276.issue10040@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Can you show a snippet of the code (or descrive it in detail) that "processes" the GzipFile? Right now it's not obvious which operations you are doing.

----------
components: +Library (Lib) -Windows
nosy: +pitrou
stage: unit test needed -> 
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10040>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:03:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 11:03:42 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1286535822.66.0.507690191014.issue9003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is the API addition I would suggest for the http.client module:

Add two new keyword arguments `context` and `check_hostname` to HTTPSConnection; `context` would allow to pass a SSLContext instance for certificate checking and other options (default None, meaning no checking); `check_hostname` would specify whether to check the hostname against the URL (default to check only if context is present and context.verify_mode != CERT_NONE).

Here is the API addition I would suggest for the urllib.request module:

- Add constructor arguments `context` and `check_hostname` to HTTPSHandler. They will be passed to the underlying HTTPSConnection.

- Add `ssl_ca_file` and `ssl_ca_path` arguments to the high-level function urlopen(); if at least one of them is present, a custom opener with a custom HTTPSHandler will be created, mandating the checking of server certificates

----------
resolution: accepted -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:06:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 11:06:30 +0000
Subject: [issue10048] urllib.request documentation confusing
In-Reply-To: <1286535990.46.0.129844190964.issue10048@psf.upfronthosting.co.za>
Message-ID: <1286535990.46.0.129844190964.issue10048@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The urllib.request documentation intermingles old 2.x urllib (FancyURLopener, etc.) with urllib2-inherited (*Handler, build_opener, etc.) primitives without making any distinction. This makes it rather confusing for the reader to figure out which ones to use.

Ideally, the use of the old primitives should also be discouraged.

----------
assignee: docs at python
components: Documentation
messages: 118179
nosy: docs at python, orsenthil, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.request documentation confusing
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10048>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:10:42 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 08 Oct 2010 11:10:42 +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: <1286536242.79.0.27722855036.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I've been pondering the idea of adopting a more conservative approach here, since there are actually two issues:

1. Properly quoted URLs are transferred as pure 7-bit ASCII (due to percent-encoding of everything else). However, most of the manipulation functions in urllib.parse can't handle bytes at all, even data that is 7-bit clean.

2. In the real world, just like email, URLs will often contain unescaped (or incorrectly escaped) characters. So assuming the input is actually pure ASCII isn't necessarily a valid assumption.

I'm wondering, since encoding (aside from quoting) isn't urllib.parse's problem, maybe what I should be looking at doing is just handling bytes input via an implicit ascii conversion in strict mode (and then conversion back when the processing is complete).

Then bytes manipulation of properly quoted URLs will "just work", while improperly quoted URLs will fail noisily. This isn't like email or http where the protocol contains encoding information that the library should be trying to interpret - we're just being given raw bytes without any context information.

If any application wants to be more permissive than that, it can do its own conversion to a string and then use the text-based processing. I'll add "encode" methods to the result objects to make it easy to convert their contents from str to bytes and vice-versa.

I'll factor out the implicit encoding/decoding such that if we decide to change the model later (ASCII-strict, ASCII-escape, latin-1) it shouldn't be too difficult.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:13:46 2010
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Fri, 08 Oct 2010 11:13:46 +0000
Subject: [issue10049] Add the null context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>


New submission from Hrvoje Nik?i? <hniksic at gmail.com>:

I find that I frequently need the "null" (no-op) context manager.  For example, in code such as:

with transaction or contextlib.null():
    ...

Since there is no easy expression to create a null context manager, we must resort to workarounds, such as:

if transaction:
    with transaction:
        ... code ...
else:
    ... duplicated code ...

(with the usual options of moving the duplicated code to a function?but still.)

Or by creating ad-hoc null context managers with the help of contextlib.contextmanager:

if transaction is None:
    transaction = contextlib.contextmanager(lambda: iter([None])()
with transaction:
    ...

Adding a "null" context manager would be both practical and elegant.  I have attached a patch for contextlib.py

----------
files: fl
messages: 118181
nosy: hniksic
priority: normal
severity: normal
status: open
title: Add the null context manager to contextlib
Added file: http://bugs.python.org/file19158/fl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:14:22 2010
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Fri, 08 Oct 2010 11:14:22 +0000
Subject: [issue10049] Add the null context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286536462.46.0.161494523374.issue10049@psf.upfronthosting.co.za>


Changes by Hrvoje Nik?i? <hniksic at gmail.com>:


----------
components: +Library (Lib)
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:14:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 11:14:31 +0000
Subject: [issue10050] urllib.request still has old 2.x urllib primitives
In-Reply-To: <1286536471.26.0.454336144311.issue10050@psf.upfronthosting.co.za>
Message-ID: <1286536471.26.0.454336144311.issue10050@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

3.x urllib.request still has a lot of stuff inherited from 2.x urllib: URLopener, FancyURLopener, the urlretrieve implementation (perhaps others?).

Ideally, urlretrieve should be reimplemented using urlopen or build_opener, and the other stuff deprecated.

----------
assignee: orsenthil
components: Library (Lib)
messages: 118182
nosy: jhylton, orsenthil, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: urllib.request still has old 2.x urllib primitives
versions: Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10050>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:17:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Oct 2010 11:17:05 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286536625.42.0.307709679747.issue10049@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Add the null context manager to contextlib -> Add a "no-op" (null) context manager to contextlib

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:20:30 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 08 Oct 2010 11:20:30 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286536830.76.0.480964275536.issue10049@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

+1

Looks like a reasonable use case.

----------
nosy: +michael.foord, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:21:02 2010
From: report at bugs.python.org (Michael Foord)
Date: Fri, 08 Oct 2010 11:21:02 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286536862.73.0.50981430316.issue10049@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Patch is missing tests and documentation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:21:50 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Oct 2010 11:21:50 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286536910.65.0.979112228343.issue10049@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

About your patch:
 - __enter__() might return self instead of None... i don't really know which choice is better. "with Null() as x:" works in both cases
 - __exit__() has no result value, "pass" is enough
 - I don't like "Null" name, I prefer "Noop" (NoOperation, NoOp, ...) or something else

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:32:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Oct 2010 11:32:15 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286537535.8.0.0724258987956.issue10049@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I also find the Null/_null/null affair confusing.

----------
nosy: +eric.araujo
stage:  -> patch review
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:33:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 11:33:55 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286537635.6.0.984753894735.issue10049@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

@contextlib.contextmanager
def null():
    yield

Do we really need to add this to the stdlib?
Previous proposals to add an "identity function" or "no-op function" have always be refused. This one seems even less useful.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:49:39 2010
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Fri, 08 Oct 2010 11:49:39 +0000
Subject: [issue10051] distutils fail to install unicode-encoded files with
	POSIX locale
In-Reply-To: <1286538579.43.0.363477643478.issue10051@psf.upfronthosting.co.za>
Message-ID: <1286538579.43.0.363477643478.issue10051@psf.upfronthosting.co.za>


New submission from Micha? G?rny <mgorny at gentoo.org>:

I was reported an issue where the user was unable to install my package [1] using python3.1. I was able to guess the issue comes from locale being set to POSIX and reproduce it.

It seems that the reasons are utf8-encoded characters in the installed script file. All the project files carry encoding declaration as per PEP-0263. They install fine with python2 but fail both with 3.1 and 3.2.

I think the build system should be locale-agnostic, and work correctly even if LC_ALL=C. If it's necessary to use text mode for scripts, I think a similar encoding guessing method should be used as in python itself.

I'm attaching a complete build log (for multiple versions of Python). Below I'm repasting the backtrace:

Traceback (most recent call last):
  File "setup.py", line 35, in <module>
    'Topic :: System :: Installation/Setup'
  File "/usr/lib64/python3.1/distutils/core.py", line 149, in setup
    dist.run_commands()
  File "/usr/lib64/python3.1/distutils/dist.py", line 919, in run_commands
    self.run_command(cmd)
  File "/usr/lib64/python3.1/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/usr/lib64/python3.1/distutils/command/build.py", line 128, in run
    self.run_command(cmd_name)
  File "/usr/lib64/python3.1/distutils/cmd.py", line 315, in run_command
    self.distribution.run_command(command)
  File "/usr/lib64/python3.1/distutils/dist.py", line 938, in run_command
    cmd_obj.run()
  File "/usr/lib64/python3.1/distutils/command/build_scripts.py", line 51, in run
    self.copy_scripts()
  File "/usr/lib64/python3.1/distutils/command/build_scripts.py", line 83, in copy_scripts
    first_line = f.readline()
  File "/usr/lib64/python3.1/encodings/ascii.py", line 26, in decode
    return codecs.ascii_decode(input, self.errors)[0]
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc5 in position 127: ordinal not in range(128)

[1] http://github.com/mgorny/smart-live-rebuild

----------
assignee: tarek
components: Distutils
files: build.log
messages: 118188
nosy: eric.araujo, mgorny, tarek
priority: normal
severity: normal
status: open
title: distutils fail to install unicode-encoded files with POSIX locale
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19159/build.log

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10051>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:52:04 2010
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Fri, 08 Oct 2010 11:52:04 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286538724.86.0.251036544124.issue10049@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

Thank you for your comments.

@Michael: I will of course write tests and documentation if there is indication that the feature will be accepted for stdlib.

@Antoine: it is true that a null context manager can be easily defined, but it does requires a separate generator definition, often repeated in different modules.  This is markedly less elegant than just using contextlib.null() in an expression.

I'm not acquainted with the history of identity function requests, but note that the identity function can be defined as an expression, using simply lambda x: x.  The equivalent expression that evaluates to a null context manager is markedly more convoluted, as shown in my report.

@?ric: The Null/_null/null distinction is an optimization that avoids creating new objects for something that is effectively a singleton.  It would be perfectly reasonable to define contextlib.null as Antoine did, but, this being stdlib, I wanted the implementation to be as efficient as (reasonably) possible.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:54:20 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 11:54:20 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286538724.86.0.251036544124.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286538855.17666.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> @Antoine: it is true that a null context manager can be easily
> defined, but it does requires a separate generator definition, often
> repeated in different modules.  This is markedly less elegant than
> just using contextlib.null() in an expression.

But you can use mymodule.null() where mymodule is a module gathering
common constructs of yours.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 13:56:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Oct 2010 11:56:36 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286538996.84.0.297813481725.issue4661@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Generator converts 8bit bodies into 7bit bodies by applying an appropriate 7bit CTE.  The reason it does this is that the output of Generator will often be passed to some other Python library function (most often smtplib) that can only handle ASCII unicode input.  That is, Generator now produces a 7bit clean message that can be put on the wire by encoding it to ascii.  This means that RFC-compliant bytes input can be successfully transmitted onward using Generator and smtplib, whereas if Generator produced non-ASCII unicode it would not be possible to pass a message with an 8bit CTE on to smtplib.

The statement about string input and output is a description of email *5.0*, the existing email package in 3.0 and 3.1, before my patch.  The differences between 4.0 and 5.0 were never previously added to the docs, so I had to add them in order to then describe the differences between 5.0 and 5.1.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Fri Oct  8 14:00:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 12:00:22 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1286538996.84.0.297813481725.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286539217.17666.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Generator converts 8bit bodies into 7bit bodies by applying an
> appropriate 7bit CTE.  The reason it does this is that the output of
> Generator will often be passed to some other Python library function
> (most often smtplib) that can only handle ASCII unicode input.

What do you mean, ASCII *unicode* input? Any low-level network library
should accept bytes when arbitrary data is possible.

Enforcing 7-bit means things like binary attachments can grow larger for
no real reason. Also, raw message bodies become less readable (which
obviously is very minor issue).

> The statement about string input and output is a description of email
> *5.0*, the existing email package in 3.0 and 3.1, before my patch.
> The differences between 4.0 and 5.0 were never previously added to the
> docs, so I had to add them in order to then describe the differences
> between 5.0 and 5.1.

Ah, my bad. Sorry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Fri Oct  8 14:03:22 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 08 Oct 2010 12:03:22 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286539402.71.0.997850073548.issue10049@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The difference here is the one pointed out in the original post: for a function, you usually only care about having a value, so if you don't want to call it, you can just swap in a None value instead. If you need an actual callable, then "lambda:None" fits the bill.

The with statement isn't quite so forgiving. You need a genuine context manager in order to preserve the correct structure in the calling code. It isn't intuitively obvious how to do that easily. While not every 3-line function needs to be in the standard library, sometimes they're worth including to aid discoverability as much as anything else.

However, I don't see the point in making it a singleton and the name should include the word "context" so it doesn't becoming ambiguous when referenced without the module name (there's a reason we went with contextlib.contextmanager over contextlib.manager).

Something like:

class nullcontext():
    """No-op context manager, executes block without doing any additional processing.

    Used as a standin if a particular block of code is only sometimes
    used with a normal context manager:

      with optional_cm or nullcontext():
          # Perform operation, using the specified CM if one is given
    """
    def __enter__():
        pass
    def __exit__(*exc_info):
        pass

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 14:04:39 2010
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Fri, 08 Oct 2010 12:04:39 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286539479.65.0.17583535299.issue10049@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

That is what we are using now, but I think a contextlib.null() would be useful to others, i.e. that its use is a useful idiom to adopt.  Specifically I would like to discourage the "duplicated code" idiom from the report, which I've seen all too often.

The "closing" constructor is also trivial to define, but it's there for convenience and to promote the use of with statement over try/finally boilerplate.  The same goes here: you don't miss the null context manager when you don't have it; you invent other solutions.  But when it's already available, it's an elegant pattern.  In my experience, if they have to define it to get it, most people won't bother with the pattern and will retain less elegant solutions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 14:09:43 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 08 Oct 2010 12:09:43 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286539783.53.0.929550353906.issue10049@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Actually, the singleton idea isn't a bad one, but I'd go one step further and skip the factory function as well. So change that to be:

class NullContext():
   ... # as per nullcontext in my last message

nullcontext = NullContext()

(with the example in the docstring adjusted accordingly)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 14:13:28 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 08 Oct 2010 12:13:28 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286540008.63.0.554289126792.issue10049@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

If you can supply a full patch before the end of the month, we should be able to get this in for 3.2beta1 (currently scheduled for 31 October)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 14:16:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Oct 2010 12:16:02 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286540162.6.0.381552765143.issue4661@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Even if smtplib accepted bytes (it currently does not), *Generator* is still producing unicode, and should produce valid unicode and still insofar as possible preserve the meaning of the original message.  This means unicode acts as if it is an SMTP server that does not support the 8bit capability, so we must convert to 7bit clean CTEs.

If smtplib later grows the ability to accept bytes, BytesGenerator can be used to feed it.  I've clarified that BytesGenerator does not do the 7bit transform, and made some other doc tweaks.

----------
Added file: http://bugs.python.org/file19160/email_parse_bytes8.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Fri Oct  8 14:18:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 12:18:18 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1286540162.6.0.381552765143.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286540292.17666.6.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Even if smtplib accepted bytes (it currently does not),

That sounds like a critical failure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Fri Oct  8 14:20:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Oct 2010 12:20:36 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286540436.79.0.351684194786.issue4661@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can only fix one package at a time :)

And in case it isn't clear, the "Generator produces ASCII-only unicode", which is in many ways a rather strange API, is one of the chief motivations for email6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Fri Oct  8 14:48:34 2010
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Fri, 08 Oct 2010 12:48:34 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286542114.49.0.721883402416.issue10049@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

I considered using a variable, but I went with the factory function for two reasons: consistency with the rest of contextlib, and equivalence to the contextmanager-based implementation.

Another reason is that it leaves the option of adding optional parameters at a later point.  I know, optional parameters aren't likely for a "null" constructor, but still... it somehow didn't feel right to relinquish control.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 15:16:15 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 08 Oct 2010 13:16:15 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1286543775.46.0.838983426547.issue5117@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Fri Oct  8 16:02:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Oct 2010 14:02:43 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286546563.73.0.802173987191.issue4661@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is the final pre-alpha patch.  This one includes the BytesFeedParser class and a test.

Unless there are objections I'd like to commit this.  Believing the code needs a more thorough review would be a valid objection :)

----------
Added file: http://bugs.python.org/file19161/email_parse_bytes9.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Fri Oct  8 16:40:38 2010
From: report at bugs.python.org (Jason Baker)
Date: Fri, 08 Oct 2010 14:40:38 +0000
Subject: [issue10046] Correction to atexit documentation
In-Reply-To: <1286487295.44.0.431847380909.issue10046@psf.upfronthosting.co.za>
Message-ID: <1286548838.09.0.0381065752251.issue10046@psf.upfronthosting.co.za>


Jason Baker <amnorvend at gmail.com> added the comment:

I like that phrasing.  I think it would be a good idea to mention that this includes SIGINT by default, just to be explicit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10046>
_______________________________________

From report at bugs.python.org  Fri Oct  8 16:56:46 2010
From: report at bugs.python.org (Thomas Klausner)
Date: Fri, 08 Oct 2010 14:56:46 +0000
Subject: [issue10047] python-2.6.6 coredump running newspipe
In-Reply-To: <1286491888.31.0.583289344322.issue10047@psf.upfronthosting.co.za>
Message-ID: <1286549806.55.0.749170856378.issue10047@psf.upfronthosting.co.za>


Thomas Klausner <tk at giga.or.at> added the comment:

# python2.6
Python 2.6.6 (r266:84292, Sep 23 2010, 08:13:08)
[GCC 4.1.3 20080704 prerelease (NetBSD nb2 20081120)] on netbsd5
Type "help", "copyright", "credits" or "license" for more information.
>>> format(0.15256118774414062, ".2f")
'0.15'
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10047>
_______________________________________

From report at bugs.python.org  Fri Oct  8 18:01:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Oct 2010 16:01:51 +0000
Subject: [issue4661] email.parser: impossible to read messages encoded in a
	different encoding
In-Reply-To: <1229273746.12.0.577914878535.issue4661@psf.upfronthosting.co.za>
Message-ID: <1286553711.67.0.831988258874.issue4661@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

After RM approval on irc, committed in r85322, with some additional doc fixes but no code changes relative to the last patch posted here.

I'm leaving this open because I still want to try to improve the handling of non-ascii bytes in headers when decoding them to unicode.

----------
priority: release blocker -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4661>
_______________________________________

From report at bugs.python.org  Fri Oct  8 18:03:34 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Fri, 08 Oct 2010 16:03:34 +0000
Subject: [issue10047] python-2.6.6 coredump running newspipe
In-Reply-To: <1286491888.31.0.583289344322.issue10047@psf.upfronthosting.co.za>
Message-ID: <1286553814.31.0.158773094916.issue10047@psf.upfronthosting.co.za>


Rodrigo Bernardo Pimentel <rbp at isnomore.net> added the comment:

Does this always happen with a particular feed? Could you provide us with a configuration that reproduces the problem?

Also, as R. David Murray asked, does this happen with 2.7?

----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10047>
_______________________________________

From report at bugs.python.org  Fri Oct  8 18:56:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 16:56:50 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1286557010.22.0.161060408006.issue9003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a preliminary patch for http.client. I think it would be good to have local tests using a custom HTTPS server, too.

----------
keywords: +patch
Added file: http://bugs.python.org/file19162/httpcli.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Fri Oct  8 19:21:05 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 08 Oct 2010 17:21:05 +0000
Subject: [issue6825] Minor documentation bug with os.path.split
In-Reply-To: <1251923724.11.0.872695091666.issue6825@psf.upfronthosting.co.za>
Message-ID: <1286558465.71.0.725419237015.issue6825@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Evan,
all your comments make sense, so I prepared a new patch about it.

I decided to go with the first option and adding a note about the possible different strings.

Regards,
Sandro

----------
versions: +Python 3.2 -Python 2.6
Added file: http://bugs.python.org/file19163/issue6825-py3k-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6825>
_______________________________________

From report at bugs.python.org  Fri Oct  8 19:56:28 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 08 Oct 2010 17:56:28 +0000
Subject: [issue7642] [patch] Minor improvement in os.system doc
In-Reply-To: <1262745991.38.0.384719539781.issue7642@psf.upfronthosting.co.za>
Message-ID: <1286560588.6.0.235236965916.issue7642@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
I took the freedom to refresh this patch, clarifying the first Val's addition (as requested by ?ric) and reformat the whole system() section to wrap a column 80.

Regards,
Sandro

----------
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19164/issue7642.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7642>
_______________________________________

From report at bugs.python.org  Fri Oct  8 19:57:48 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 08 Oct 2010 17:57:48 +0000
Subject: [issue7642] [patch] Minor improvement in os.system doc
In-Reply-To: <1262745991.38.0.384719539781.issue7642@psf.upfronthosting.co.za>
Message-ID: <1286560668.44.0.588886048116.issue7642@psf.upfronthosting.co.za>


Changes by Sandro Tosi <sandro.tosi at gmail.com>:


----------
versions: +Python 3.2 -Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7642>
_______________________________________

From report at bugs.python.org  Fri Oct  8 19:58:47 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Fri, 08 Oct 2010 17:58:47 +0000
Subject: [issue10017] pprint.pprint raises TypeError on dictionaries with
	user-defined types as keys
In-Reply-To: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>
Message-ID: <1286560727.13.0.430970814916.issue10017@psf.upfronthosting.co.za>


Rodrigo Bernardo Pimentel <rbp at isnomore.net> added the comment:

FWIW, the problem still occurs on the most recent release31-maint checkout (as of r85323), and does not happen on py3k (3.2a2).

----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10017>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:04:54 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Fri, 08 Oct 2010 18:04:54 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286561094.7.0.731334149192.issue1553375@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Is that normal to have two methods "test_full_traceback_is_full" at the same place, in full_traceback.patch / r.david.murray / 2010-08-04 02:32 ?

format_exception should have the same semantic as print_exception indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:22:04 2010
From: report at bugs.python.org (Stephen J. Turnbull)
Date: Fri, 08 Oct 2010 18:22:04 +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: <1286562124.37.0.205731581463.issue9873@psf.upfronthosting.co.za>


Changes by Stephen J. Turnbull <stephen at xemacs.org>:


----------
nosy: +sjt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:25:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 08 Oct 2010 18:25:26 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286480237.64.0.444141117326.issue10029@psf.upfronthosting.co.za>
Message-ID: <AANLkTikO4pugmpBuZR=n7NBfMn5fHWPd_d7yh4GDFXQ1@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Oct 7, 2010 at 3:37 PM, Raymond Hettinger
<report at bugs.python.org> wrote:
..
> I'll update the docs with an equivalent that works and that has a comment showing when the
> StopIteration is raised and caught.
>

In this case, I wonder if "equivalent to" code should be added to the
section for enumerate() and map().  Also since any() and all() have
"equivalent to" code, I think min(), max() and sum() deserve it as
well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10029>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:26:41 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 08 Oct 2010 18:26:41 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286562401.42.0.745850315937.issue10049@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/issue10049>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:39:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 08 Oct 2010 18:39:53 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1286563193.96.0.390239984201.issue1777412@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

kiorky,

Thank you for the updated patch, but since it implements a new feature, it cannot be applied to 2.x series.  I am +1 on removing year > 1900 limitation from datetime.strftime in 3.x, but you need to consider how this can be achieved in pure python datetime implementation which is now slated to be released in 3.2.  See msg110792 above.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:49:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 08 Oct 2010 18:49:16 +0000
Subject: [issue1545463] New-style classes fail to cleanup attributes
Message-ID: <1286563756.34.0.120419386464.issue1545463@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Does anyone want to weigh in on this?  I am merging in the issue812369 nosy list.

I would like to either apply gc-import.patch or close this as superseded by issue812369.

----------
keywords: +needs review -patch
nosy: +arigo, brett.cannon, candrea, cburroughs, christian.heimes, glchapman, gregory.p.smith, loewis, nascheme, pitrou -BreamoreBoy
stage:  -> commit review
versions: +Python 3.2 -Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1545463>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:50:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 08 Oct 2010 18:50:25 +0000
Subject: [issue4775] Incorrect documentation - UTC time
In-Reply-To: <1230603442.34.0.985593856271.issue4775@psf.upfronthosting.co.za>
Message-ID: <1286563825.66.0.696936087673.issue4775@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/issue4775>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:51:16 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 08 Oct 2010 18:51:16 +0000
Subject: [issue9866] Inconsistencies in tracing list comprehensions
In-Reply-To: <1284585781.8.0.0490639400631.issue9866@psf.upfronthosting.co.za>
Message-ID: <1286563876.89.0.308782775283.issue9866@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/issue9866>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:51:40 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Fri, 08 Oct 2010 18:51:40 +0000
Subject: [issue10017] pprint.pprint raises TypeError on dictionaries with
	user-defined types as keys
In-Reply-To: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>
Message-ID: <1286563900.05.0.424485161186.issue10017@psf.upfronthosting.co.za>


Rodrigo Bernardo Pimentel <rbp at isnomore.net> added the comment:

If I'm understanding this correctly, this fails on 3.1 and not (although, actually, it does) on py3k/3.2 because:

* pprint._safe_key.__lt__ checks "rv = self.obj.__lt__(other.obj)" and falls back to id comparison if rv is NotImplemented

* If the object passed to _safe_key is a class, self.obj.__lt__ will expect *self* as well as the other object. Therefore the verification above fails with "TypeError: expected 1 arguments, got 0". You can see that pprint works with an instance:

>>> pprint.pprint({A(): 1, 1: 2})
{<__main__.A object at 0x8594d4c>: 1, 1: 2}

* Finally, this works on py3k *for your example* because, for some reason, on py3k the comparison is being based on the 1 key. That is, the comparison on _safe_key.__lt__ happens to be 1.__lt__(A), instead of A.__lt__(1). Perhaps hashing changed after the 3.1 release?

Anyway, py3k still fails when you force the comparison to happen on the class:

>>> class B(object): pass
... 
>>> pprint.pprint({A: 1, B: 2})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 55, in pprint
    printer.pprint(object)
  File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 132, in pprint
    self._format(object, self._stream, 0, 0, {}, 0)
  File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 155, in _format
    rep = self._repr(object, context, level - 1)
  File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 245, in _repr
    self._depth, level)
  File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 257, in format
    return _safe_repr(object, context, maxlevels, level)
  File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 299, in _safe_repr
    items = sorted(object.items(), key=_safe_tuple)
  File "/home/rbp/python/dev/py3k/Lib/pprint.py", line 89, in __lt__
    rv = self.obj.__lt__(other.obj)
TypeError: expected 1 arguments, got 0
>>> 

So, basically, the fix on issue 3976 does't (always) work when there are classes as dict keys. I think switching from

rv = self.obj.__lt__(other.obj)
if rv is NotImplemented:

to something like

try:
    rv = self.obj < other.obj
except TypeError:
    rv = (str(type(self.obj)), id(self.obj)) < \
    (str(type(other.obj)), id(other.obj))

solves this. Or we can check first whether self.obj is a 'type', but I think it gets convoluted.

If anyone can confirm that that's the way to go, I can produce one (though it's a trivial one). Raymond?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10017>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:55:48 2010
From: report at bugs.python.org (Patrick Strawderman)
Date: Fri, 08 Oct 2010 18:55:48 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286564148.28.0.950699955385.issue10045@psf.upfronthosting.co.za>


Patrick Strawderman <patrick at zope.com> added the comment:

Fair enough, but there is a great deal of existing code that already 
uses cStringIO.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:58:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 08 Oct 2010 18:58:13 +0000
Subject: [issue8902] add datetime.time.now() for consistency
In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za>
Message-ID: <1286564293.45.0.380616014579.issue8902@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I need to correct myself: datetime.today() is not an alternative spelling of date.today(), but rather a function returning current datetime which subtly different from datetime.now().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8902>
_______________________________________

From report at bugs.python.org  Fri Oct  8 20:58:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 08 Oct 2010 18:58:42 +0000
Subject: [issue8902] add datetime.time.now() for consistency
In-Reply-To: <1275719789.45.0.168425659941.issue8902@psf.upfronthosting.co.za>
Message-ID: <1286564322.94.0.315827184053.issue8902@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage:  -> needs patch
type:  -> feature request
versions:  -Python 2.7, Python 3.1, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8902>
_______________________________________

From report at bugs.python.org  Fri Oct  8 21:00:40 2010
From: report at bugs.python.org (Rodrigo Bernardo Pimentel)
Date: Fri, 08 Oct 2010 19:00:40 +0000
Subject: [issue3976] pprint._safe_repr is not general enough in one instance
In-Reply-To: <1222445700.05.0.107288672735.issue3976@psf.upfronthosting.co.za>
Message-ID: <1286564440.5.0.0890847632376.issue3976@psf.upfronthosting.co.za>


Rodrigo Bernardo Pimentel <rbp at isnomore.net> added the comment:

Armin: this has the problem that, if the object you're trying to compare is a class, self.obj.__lt__ expects a different number of parameters (i.e., it expects the instance). See issue 10017 . Testing with "<" works.

----------
nosy: +rbp

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3976>
_______________________________________

From report at bugs.python.org  Fri Oct  8 21:00:53 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 08 Oct 2010 19:00:53 +0000
Subject: [issue7771] dict view comparison methods are not documented
In-Reply-To: <1264353566.74.0.804981752433.issue7771@psf.upfronthosting.co.za>
Message-ID: <1286564453.26.0.166556586227.issue7771@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
here attached a patch for this bug. I hope the format "< / <= / == / != / >= / >" is clearly understandable as an alternative sequence of different operations.

Regards,
Sandro

----------
keywords: +patch
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19165/issue7771-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7771>
_______________________________________

From report at bugs.python.org  Fri Oct  8 21:02:33 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 Oct 2010 19:02:33 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286564553.4.0.921126839186.issue10029@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Refuse the temptation to hypergeneralize ;-)

Also refuse the temptation to double the size of the docs (more != better).

In the case of min/max, the pure python versions may add some value in showing that the first match is what is returned.  But the code will also be a bit convoluted because it needs paths for key-argument case and for the screwy interpretation of 1 arg vs multiple args.

The pure python code is there for any() and all() to show the early out feature and to suggest how you could roll-your-own if you want different behavior (such as returning the value of the first exception).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10029>
_______________________________________

From report at bugs.python.org  Fri Oct  8 21:24:58 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Fri, 08 Oct 2010 19:24:58 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1286565898.45.0.390818847969.issue4388@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

FWIW, this still happens on the latest of /branches/py3k, when LANG does not match up to the enforced fs encoding-- which for me happened when I ran the buildslave under launchd.

I was finally able to reproduce it, and after doing so, verified that cmdline_encoding-2.patch on issue9992 fixed it.

----------
nosy: +ixokai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Fri Oct  8 21:25:59 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Fri, 08 Oct 2010 19:25:59 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif
	locale	and fileystem encodings aredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286565959.94.0.241181341093.issue9992@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

This issue seems to be the cause of issue4388 -- and cmdline_encoding-2.patch fixes it, fwiw.

----------
nosy: +ixokai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Fri Oct  8 21:26:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 08 Oct 2010 19:26:14 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286565974.59.0.671830123166.issue1553375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, that would be a bug, thanks.

Also thanks for reminding me about this issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Fri Oct  8 21:59:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 08 Oct 2010 19:59:37 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1286567977.4.0.183124845472.issue4388@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> FWIW, this still happens on the latest of /branches/py3k, 
> when LANG does not match up to the enforced fs encoding
 
ixokai has the bug on Snow Leopard x86.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Fri Oct  8 22:07:28 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 Oct 2010 20:07:28 +0000
Subject: [issue7771] dict view comparison methods are not documented
In-Reply-To: <1264353566.74.0.804981752433.issue7771@psf.upfronthosting.co.za>
Message-ID: <1286568448.28.0.139557165885.issue7771@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

We should probably just make reference to the collections.Set() abstract API instead of listing out all operations.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7771>
_______________________________________

From report at bugs.python.org  Fri Oct  8 22:30:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 20:30:37 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif
	locale	and fileystem encodings aredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286569837.73.0.553212623573.issue9992@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The important point is that we have to use the same encoding to decode 
> and encode command line arguments.

I don't think I agree with this. It's only important when you run a Python interpreter using subprocess, but the point of using subprocess is to run something *else* than Python. This something else generally expects filenames in their correct bytes representation, not in a mojibaked version hand-tuned for Python.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Fri Oct  8 22:36:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 20:36:53 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1286570213.34.0.784440122041.issue4388@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, this can be now reproduced under Linux by forcing different locale and filesystem encodings:

$ PYTHONFSENCODING=utf8 LANG=ISO-8859-1 ./python -m test.regrtest test_cmd_line

[1/1] test_cmd_line
test test_cmd_line failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_cmd_line.py", line 109, in test_run_code
    assert_python_ok('-c', command)
  File "/home/antoine/py3k/__svn__/Lib/test/script_helper.py", line 35, in assert_python_ok
    return _assert_python(True, *args)
  File "/home/antoine/py3k/__svn__/Lib/test/script_helper.py", line 31, in _assert_python
    "stderr follows:\n%s" % (rc, err.decode('ascii', 'ignore')))
AssertionError: Process return code is 1, stderr follows:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: ord() expected a character, but string of length 2 found

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Fri Oct  8 23:38:25 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 08 Oct 2010 21:38:25 +0000
Subject: [issue10017] pprint.pprint raises TypeError on dictionaries with
	user-defined types as keys
In-Reply-To: <1286051720.0.0.33399911329.issue10017@psf.upfronthosting.co.za>
Message-ID: <1286573905.96.0.0564035532056.issue10017@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

A simpler change would to replace:
    rv = self.obj.__lt__(other.obj)
with
    rv = type(self.obj).__lt__(self.obj, other.obj)

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10017>
_______________________________________

From report at bugs.python.org  Fri Oct  8 23:59:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Oct 2010 21:59:47 +0000
Subject: [issue10008] Two links point to same place
In-Reply-To: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>
Message-ID: <1286575187.91.0.362431922311.issue10008@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

You initial link 
I only see one entry, Thread (class in threading), which points to
http://docs.python.org/library/threading.html#threading.Thread
as it should. I do not see a duplicate link nearby.

I have no idea what ', [1]' is supposed to mean.

What does puzzle me is that

Thread [neader, no link]
   module

points to http://docs.python.org/c-api/init.html#index-64
it seems like the entry should have more. This entry is gone in 3.1.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10008>
_______________________________________

From report at bugs.python.org  Sat Oct  9 00:27:40 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 08 Oct 2010 22:27:40 +0000
Subject: [issue7771] dict view comparison methods are not documented
In-Reply-To: <1264353566.74.0.804981752433.issue7771@psf.upfronthosting.co.za>
Message-ID: <1286576860.27.0.0927039784747.issue7771@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello Raymond,
thanks for the review. I've reworked the patch to refer to Collections.Set (but is there a way to make that reference a link to the description of Collections ABCs?) and so I've also removed all the examples, leaving only the one for '^' because I didn't see a Set operator to do that (but I'm happy to be proven wrong :)

Regards,
Sandro

----------
Added file: http://bugs.python.org/file19166/issue7771-py3k-v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7771>
_______________________________________

From report at bugs.python.org  Sat Oct  9 00:30:49 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Oct 2010 22:30:49 +0000
Subject: [issue10011] `except` doesn't use `isinstance`
In-Reply-To: <1285973470.62.0.723186105709.issue10011@psf.upfronthosting.co.za>
Message-ID: <1286577049.1.0.624749290345.issue10011@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Questions should be asked on python-list or other discussion forums, not nere. If this were a feature-request, it would need a realistic use-case. If the implied change were requested, I would think it should be rejected as conflicting with the language definition, which to me stipulates that when an exception is raised, nothing happens until it is caught.

----------
nosy: +terry.reedy
resolution:  -> invalid
status: open -> closed
versions:  -Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10011>
_______________________________________

From report at bugs.python.org  Sat Oct  9 00:34:28 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 08 Oct 2010 22:34:28 +0000
Subject: [issue7771] dict view comparison methods are not documented
In-Reply-To: <1264353566.74.0.804981752433.issue7771@psf.upfronthosting.co.za>
Message-ID: <1286577268.05.0.260651258873.issue7771@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The '^' corresponds to the __xor__ magic method.

snip from _abcoll.py:

    def __xor__(self, other):
        if not isinstance(other, Set):
            if not isinstance(other, Iterable):
                return NotImplemented
            other = self._from_iterable(other)
        return (self - other) | (other - self)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7771>
_______________________________________

From report at bugs.python.org  Sat Oct  9 00:55:20 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Oct 2010 22:55:20 +0000
Subject: [issue10021] Format parser is too permissive
In-Reply-To: <1286209446.65.0.698670214161.issue10021@psf.upfronthosting.co.za>
Message-ID: <1286578520.62.0.554078688413.issue10021@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

This is a bug report in that there is a discrepancy between the grammar in the doc and the behavior. Laxiness can lead to portability problems if CPython is lax compared to a normal reading of the spec and another implementation takes the spec seriously.

I agree that implementation details that lead to an exception here and not there, or vice versa, are best avoided.

For getattr:
'''
getattr(object, name[, default]) 
Return the value of the named attributed of object. name must be a string.
'''
the doc is careful to just say that name must be a string, not specifically an identifier. Given that, I suppose
"attribute_name    ::=  identifier" should be changed to match so that string formats can always (all implementations) also access non-identifier attributes.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10021>
_______________________________________

From report at bugs.python.org  Sat Oct  9 01:07:20 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Oct 2010 23:07:20 +0000
Subject: [issue10025] random.seed not initialized as advertised
In-Reply-To: <1286235186.65.0.07824350342.issue10025@psf.upfronthosting.co.za>
Message-ID: <1286579240.46.0.919621882857.issue10025@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

3.1 has the same problem (and the same results as above)

Assuming behavior is not changed, please suggest a specific rewording that you would be happy with and that is not too verbose.

----------
components: +Documentation
nosy: +terry.reedy
stage:  -> needs patch
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10025>
_______________________________________

From report at bugs.python.org  Sat Oct  9 01:08:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 08 Oct 2010 23:08:29 +0000
Subject: [issue1051] certificate in Lib/test/test_ssl.py expires in February
	2013
In-Reply-To: <1188347976.5.0.452651938293.issue1051@psf.upfronthosting.co.za>
Message-ID: <1286579309.11.0.376971332494.issue1051@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Cert generation script committed in r85327.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1051>
_______________________________________

From report at bugs.python.org  Sat Oct  9 01:27:35 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Oct 2010 23:27:35 +0000
Subject: [issue10018] IDLE not loading in xp pro due to tcl issue
In-Reply-To: <1286079562.42.0.239403513139.issue10018@psf.upfronthosting.co.za>
Message-ID: <1286580455.15.0.805246017478.issue10018@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Please ask for help with installation and usage on the python-list mailing list, which is also mirrored on the gmane.comp.python.general newsgroup at news.gmane.org and the comp.lang.python usenet newsgroup. This issue tracker is for python bugs (and feature requests).

Your problem probably stems from the fact that you have both python22 and python27 on the search path, but I cannot say why or what you need to do. Ask as suggested above, specifying exactly how you installed python.

PS. 2.5 and 2.6 are closed to normal bug reports.

----------
nosy: +terry.reedy
resolution:  -> invalid
status: open -> closed
versions:  -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10018>
_______________________________________

From report at bugs.python.org  Sat Oct  9 01:29:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 08 Oct 2010 23:29:21 +0000
Subject: [issue7642] Minor improvement to os.system doc
In-Reply-To: <1262745991.38.0.384719539781.issue7642@psf.upfronthosting.co.za>
Message-ID: <1286580561.47.0.952785498538.issue7642@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.  (Before committing, one space should be changed to two spaces after a full stop in the first diff hunk.)

----------
assignee: georg.brandl -> docs at python
nosy: +docs at python
stage:  -> patch review
title: [patch] Minor improvement in os.system doc -> Minor improvement to os.system doc
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7642>
_______________________________________

From report at bugs.python.org  Sat Oct  9 01:55:23 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 08 Oct 2010 23:55:23 +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: <1286582123.46.0.60230979674.issue10043@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The usual way to set a module variable by name, rather than
setattr(modules[__name__], 'name', 'value')
is
>>> globals()['name'] = 2
>>> name
2

Issues of working with external names, such as from database columns, has been discussed several times on python-list and the corresponding newsgroups. Please post there is you want to discuss that.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10043>
_______________________________________

From report at bugs.python.org  Sat Oct  9 02:01:35 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Oct 2010 00:01:35 +0000
Subject: [issue10025] random.seed not initialized as advertised
In-Reply-To: <1286235186.65.0.07824350342.issue10025@psf.upfronthosting.co.za>
Message-ID: <1286582495.31.0.702195256329.issue10025@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Perhaps replace equivalent with "based on" or some such.  This is a very minor nit and likely of interest to no one except the OP.

----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10025>
_______________________________________

From report at bugs.python.org  Sat Oct  9 02:11:50 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Sat, 09 Oct 2010 00:11:50 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1286583110.9.0.917036733179.issue8445@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

I'm still getting this error on the release27-maint branch on my Snow Leopard slave, and the issue8445.diff fixes it: will this fix be backported?

I tested issue8445.diff and it applies cleanly, and fixes the issue.

----------
nosy: +ixokai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sat Oct  9 02:41:25 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Sat, 09 Oct 2010 00:41:25 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1286584885.18.0.350874860209.issue8445@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

BTW, release31-maint appears to have the same issue, its fouling up that build on my slave too. I tried applying the ttk3k.patch but it didn't apply cleanly, and I'm completely ignorant of TK so can't really figure out what's different between the 3.1->3.2 version to try to adjust the fix and test it out.

Then again I'm not sure if there's still going to be test-fixes applied to 3.1. So its possible you can just ignore this comment :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sat Oct  9 03:38:12 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 09 Oct 2010 01:38:12 +0000
Subject: [issue10008] Two links point to same place
In-Reply-To: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>
Message-ID: <1286588292.52.0.185874932406.issue10008@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

> You initial link 
> I only see one entry, Thread (class in threading), which points to
> http://docs.python.org/library/threading.html#threading.Thread
> as it should. I do not see a duplicate link nearby.

It used to be there. Please see
http://docs.python.org/release/2.7/genindex-T.html
But ZipFile seems to have same issue, and still there.
Please see
http://docs.python.org/genindex-Z.html

>Thread [neader, no link]
>  module

Hmm, I cannot see this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10008>
_______________________________________

From report at bugs.python.org  Sat Oct  9 05:06:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Oct 2010 03:06:37 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286593597.18.0.684743770544.issue1553375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I like 'allframes', so I changed to that.  The updated patch also adds the allframes parameter to format_exception.

In going over the tests I realized that I'm not sure the output for the case of chain=True is correct.  Opinions?  If it is not correct it is not obvious to me how to fix it.

----------
Added file: http://bugs.python.org/file19167/full_traceback2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 05:08:42 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 09 Oct 2010 03:08:42 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1286593722.1.0.493299815493.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101009.zip is a new version of the regex module.

It appears from a posting in python-list and a closer look at the docs that string positions in the 're' module are limited to 32 bits, even on 64-bit builds. I think it's because of things like:

    Py_BuildValue("i", ...)

where 'i' indicates the size of a C int, which, at least in Windows compilers, is 32-bits in both 32-bit and 64-bit builds.

The regex module shared the same problem. I've changed such code to:

    Py_BuildValue("n", ...)

and so forth, which indicates Py_ssize_t.

Unfortunately I'm not able to confirm myself that this will fix the problem on 64 bits.

----------
Added file: http://bugs.python.org/file19168/issue2636-20101009.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Oct  9 06:49:40 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 09 Oct 2010 04:49:40 +0000
Subject: [issue1545463] New-style classes fail to cleanup attributes
Message-ID: <1286599780.81.0.50462198333.issue1545463@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

looks harmless to me.  though i think issue812369 looks okay as well at first glance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1545463>
_______________________________________

From report at bugs.python.org  Sat Oct  9 06:50:21 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 09 Oct 2010 04:50:21 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1286599821.99.0.504658375515.issue812369@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

0001-update-GC-shutdown-patch.patch looks sane to me at first glance.  any other opinions?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Sat Oct  9 08:58:35 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Sat, 09 Oct 2010 06:58:35 +0000
Subject: [issue2889] curses for windows (alternative patch)
In-Reply-To: <1210919907.42.0.842256015219.issue2889@psf.upfronthosting.co.za>
Message-ID: <1286607515.74.0.128497113807.issue2889@psf.upfronthosting.co.za>


Changes by Christoph Gohlke <cgohlke at uci.edu>:


----------
nosy: +cgohlke

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2889>
_______________________________________

From report at bugs.python.org  Sat Oct  9 09:26:45 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 09 Oct 2010 07:26:45 +0000
Subject: [issue10052] Python/dtoa.c:158: #error "Failed to find an exact-width
	32-bit integer type" (FreeBSD 4.11 + gcc 2.95.4)
In-Reply-To: <1286609205.46.0.0704666326351.issue10052@psf.upfronthosting.co.za>
Message-ID: <1286609205.46.0.0704666326351.issue10052@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

Building Python 2.7 fails on FreeBSD 4.11 with gcc 2.95.4 as below:

"""
gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g  -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Python/dtoa.o Python/dtoa.c
Python/dtoa.c:158: #error "Failed to find an exact-width 32-bit integer type"
gmake: *** [Python/dtoa.o] Error 1
"""

This error occurs when HAVE_UINT32_T or HAVE_INT32_T are not defined.
Those constants are defined in Include/pyport.h as:

"""
#if (defined UINT32_MAX || defined uint32_t)
#ifndef PY_UINT32_T
#define HAVE_UINT32_T 1
#define PY_UINT32_T uint32_t
#endif
#endif
"""

"""
#if (defined INT32_MAX || defined int32_t)
#ifndef PY_INT32_T
#define HAVE_INT32_T 1
#define PY_INT32_T int32_t
#endif
#endif
"""

This doesn't work for FreeBSD 4, where exact-width integer types are defined #typedef and does not provide *_MAX for them.

I don't think this is the right fix but adding following macro to pyport.h fixed the problem.

"""
#define UINT32_MAX 0xffffffff
#define INT32_MAX 0x7fffffff
"""

----------
components: Build
messages: 118246
nosy: akitada
priority: normal
severity: normal
status: open
title: Python/dtoa.c:158: #error "Failed to find an exact-width 32-bit integer type" (FreeBSD 4.11 + gcc 2.95.4)
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From report at bugs.python.org  Sat Oct  9 09:45:43 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 09 Oct 2010 07:45:43 +0000
Subject: [issue7771] dict view comparison methods are not documented
In-Reply-To: <1264353566.74.0.804981752433.issue7771@psf.upfronthosting.co.za>
Message-ID: <1286610343.25.0.92444765053.issue7771@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

gaah, sorry about that. I've prepared another patch that removes the '^' part and adds an example about that.

About the reference to Collections.Set to be a link to the Collections page, do you think it's acceptable to define all the Collection ABCs as :class:`...` ? I looked at http://docs.python.org/documenting/markup.html but didn't find a specific markup for ABC, so I suppose 'class' is fine.

If you think it might worth the effort, I can mark those ABCs up as class, and scan the documentation for references to them and convert to link (if not already done automagically).

----------
Added file: http://bugs.python.org/file19169/issue7771-py3k-v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7771>
_______________________________________

From report at bugs.python.org  Sat Oct  9 09:50:07 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 09 Oct 2010 07:50:07 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1286610607.85.0.469086778511.issue8533@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I noticed fd must be dup-ed before passing to io.open.
And I noticed direct test run like "py3k -m test.test_time"
still produces unicode error. (Maybe this is reasonable
limitation)

I can confirm we can suppress the unicode error in such
case with newly attached patch. "py3k_also_no_unicode_error_on_direct_test_run.patch"

----------
Added file: http://bugs.python.org/file19170/py3k_also_no_unicode_error_on_direct_test_run.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Sat Oct  9 10:08:19 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 09 Oct 2010 08:08:19 +0000
Subject: [issue10053] Probably fd should not be closed when FileIO#__init__
	failed
In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za>
Message-ID: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

I suppose when _io.FileIO(fd) failed, passed fd
should not be closed. Otherwise, we cannot write the
code like this.

     fd = os.open(path, os.O_RDONLY)
     try:
         buf = io.open(fd, "wb")
     except:
         os.close(fd)
         raise

I found some corner case (rarely happens) in FileIO#__init__
Is this patch correct? Thank you.

----------
components: IO
files: py3k_ensure_fd_not_closed_after_fileio_init_failed.patch
keywords: patch
messages: 118249
nosy: ocean-city
priority: normal
severity: normal
stage: patch review
status: open
title: Probably fd should not be closed when FileIO#__init__ failed
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19171/py3k_ensure_fd_not_closed_after_fileio_init_failed.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10053>
_______________________________________

From report at bugs.python.org  Sat Oct  9 10:10:14 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 09 Oct 2010 08:10:14 +0000
Subject: [issue10053] Probably fd should not be closed when FileIO#__init__
	failed
In-Reply-To: <1286611699.72.0.643946384367.issue10053@psf.upfronthosting.co.za>
Message-ID: <1286611814.16.0.978614699982.issue10053@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Here is the test script also run on py2.7.

----------
Added file: http://bugs.python.org/file19172/test_ensure_fd_not_closed_after_fileio_init_failed.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10053>
_______________________________________

From report at bugs.python.org  Sat Oct  9 10:10:54 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 09 Oct 2010 08:10:54 +0000
Subject: [issue10054] select extension does not build on platforms where
	uintptr_t is provided in inttypes.h
In-Reply-To: <1286611853.89.0.308304033443.issue10054@psf.upfronthosting.co.za>
Message-ID: <1286611853.89.0.308304033443.issue10054@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

Some platforms have uintptr_t in inttypes.h but Python bulid system
assumes it's defined in stdint.h and it causes build failure:

"""
building 'select' extension
gcc -pthread -fPIC -fno-strict-aliasing -g -O2 -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -IInclude -I./Include -I/usr/local/include -I/usr/home/akitada/
src/release27-maint/Include -I/usr/home/akitada/src/release27-maint -c /usr/home/akitada/src/release27-maint/Modules/selectmodule.c -o build/temp.freebsd-4.
11-RELEASE-i386-2.7/usr/home/akitada/src/release27-maint/Modules/selectmodule.o
/usr/home/akitada/src/release27-maint/Modules/selectmodule.c:1189: #error uintptr_t does not match void *!
"""

----------
components: Build
messages: 118251
nosy: akitada
priority: normal
severity: normal
status: open
title: select extension does not build on platforms where uintptr_t is provided in inttypes.h
type: compile error
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10054>
_______________________________________

From report at bugs.python.org  Sat Oct  9 10:14:03 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 09 Oct 2010 08:14:03 +0000
Subject: [issue10054] select extension does not build on platforms where
	uintptr_t is provided in inttypes.h
In-Reply-To: <1286611853.89.0.308304033443.issue10054@psf.upfronthosting.co.za>
Message-ID: <1286612043.75.0.120829789993.issue10054@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

This patch fixes this.

----------
keywords: +patch
Added file: http://bugs.python.org/file19173/issue10054.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10054>
_______________________________________

From report at bugs.python.org  Sat Oct  9 10:16:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Oct 2010 08:16:36 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1286612196.81.0.944602202962.issue8533@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

py3k_also_no_unicode_error_on_direct_test_run.patch comes a little bit too late:

$ LANG= ./python Lib/test/regrtest.py -v test_time
== CPython 3.2a2+ (py3k, Oct 8 2010, 01:40:20) [GCC 4.4.5 20100909 (prerelease)]
==   Linux-2.6.32-trunk-686-i686-with-debian-squeeze-sid little-endian
==   Traceback (most recent call last):
  File "Lib/test/regrtest.py", line 1478, in <module>
    main()
  File "Lib/test/regrtest.py", line 454, in main
    print("==  ", os.getcwd())
UnicodeEncodeError: 'ascii' codec can't encode characters in position 20-21: ordinal not in range(128)

My working directory is /home/haypo/prog/SVN/py3k?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Sat Oct  9 10:25:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Oct 2010 08:25:08 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1286570213.34.0.784440122041.issue4388@psf.upfronthosting.co.za>
Message-ID: <201010091024.58758.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> For the record, this can be now reproduced under Linux by forcing different
> locale and filesystem encodings:
> 
> $ PYTHONFSENCODING=utf8 LANG=ISO-8859-1 ./python -m test.regrtest
> test_cmd_line

I opened a separated issue for Linux, #9992, because some Mac OS X users say 
that this issue looks like a Mac OS X bug and the fix may be different.

Extract of msg111432 (#8775): "To be honest, I'd say the behavior of OSX 10.4 
is a bug and we might add a workaround on that platform that uses 
CFStringGetSystemEncoding() to fetch the actual system encoding when LANG=C."

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Sat Oct  9 10:32:04 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 09 Oct 2010 08:32:04 +0000
Subject: [issue10055] C99 code in _json.c
In-Reply-To: <1286613124.83.0.838959560604.issue10055@psf.upfronthosting.co.za>
Message-ID: <1286613124.83.0.838959560604.issue10055@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

I found some C99 code in _json.c.
Attached patch makes it C89.

The C99 part is only used for ucs4 Python. That's probably the reason
it's overlooked.

----------
components: Build
files: _json.c.diff
keywords: patch
messages: 118255
nosy: akitada
priority: normal
severity: normal
status: open
title: C99 code in _json.c
type: compile error
versions: Python 2.7
Added file: http://bugs.python.org/file19174/_json.c.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10055>
_______________________________________

From report at bugs.python.org  Sat Oct  9 10:58:47 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 09 Oct 2010 08:58:47 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1286614727.98.0.0346320199793.issue8533@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Oops, sorry. I'll withdraw my last patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Sat Oct  9 10:59:06 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 09 Oct 2010 08:59:06 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1286614746.48.0.440164912803.issue8533@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file19170/py3k_also_no_unicode_error_on_direct_test_run.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Sat Oct  9 11:14:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 09 Oct 2010 09:14:50 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif
	locale	and fileystem encodings aredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286615690.16.0.96067019245.issue9992@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Antoine: Python cannot possibly know whether a command line argument is meant as a file name or as some other text, and what encoding the receiving application will apply to it (if any).

I agree it's best to have all "IO" encodings being the same in Python, but perhaps there are use cases where you have to use a different encoding for file names, so I don't think it is necessary to rip this feature out.

So perhaps it would be best if Python had two external default encodings: the IO one (command line arguments, environment variables, text files), and the file name encoding (defaulting to the IO encoding if not set). If they differ and you get mojibake in subprocesses: bad luck - it's exactly what you asked for. 

The fsname encoding should *only* be used for file names, not for command line arguments in subprocess.

If we have tests that rely on the fsname encoding and the IO encoding being the same, then those tests should get skipped if the encodings are actually different.

The tricky parts remains determining the IO encoding. If PYTHONIOENCODING can override the locale's encoding, then the tricky question is how command line arguments should get decoded in absence of the codec machinery on Unix. They must get decoded for uniformity with Windows (which received the command line as a Unicode string already).

That problem may be the reason why we need *three* encodings (as it is now), the IOENCODING only applying to file streams.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sat Oct  9 11:15:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 09 Oct 2010 09:15:44 +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: <1286615744.33.0.621734559093.issue10053@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +pitrou
title: Probably fd should not be closed when FileIO#__init__ failed -> Don?t close fd when FileIO.__init__ fails

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10053>
_______________________________________

From report at bugs.python.org  Sat Oct  9 11:45:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 09:45:19 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif
	locale	and fileystem encodings aredifferent
In-Reply-To: <1286615690.16.0.96067019245.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286617506.3177.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine: Python cannot possibly know whether a command line argument
> is meant as a file name or as some other text, and what encoding the
> receiving application will apply to it (if any).

I understand. But practicality seems to suggest that, most of the time,
non-ASCII arguments on a command line will be filenames. We should
probably try to favour the common case (barring implementation issues,
though, and it seems using the filesystem encoding in the interpreter
bootup phase is not easy).

> So perhaps it would be best if Python had two external default
> encodings: the IO one (command line arguments, environment variables,
> text files), and the file name encoding (defaulting to the IO encoding
> if not set).

Looking at environment variables here, they seem to be either:
- integers (pids, port numbers...)
- conventional variables (such as "fr_FR.utf8")
- usernames
- file paths

The most likely values to be non-ASCII are, therefore, file paths. So it
would make sense to also use the filesystem encoding for environment
variables (so as to satisfy the common case).

As for text files, I agree it's different, and the encoding choice
routine in TextIOWrapper already favours locale.getpreferredencoding()
and ignores the filesystem encoding.

> If we have tests that rely on the fsname encoding and the IO encoding
> being the same, then those tests should get skipped if the encodings
> are actually different.

Agreed, but only when this discussion has come to a conclusion :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sat Oct  9 12:01:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 10:01:46 +0000
Subject: [issue812369] module shutdown procedure based on GC
Message-ID: <1286618506.25.0.800319544567.issue812369@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The patch is obviously against 2.x (there are some PyString_Check's on module names, for example). It should be regenerated against 3.x.

Also, it would be nice if a test could be devised to check that the shutdown procedure works as expected (I'm not sure how such a test would look like).

----------
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue812369>
_______________________________________

From report at bugs.python.org  Sat Oct  9 12:18:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 10:18:30 +0000
Subject: [issue10056] Can't build tkinter with libtk 8.6
In-Reply-To: <1286619510.51.0.775607940456.issue10056@psf.upfronthosting.co.za>
Message-ID: <1286619510.51.0.775607940456.issue10056@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is only with 3.1. Following patch allows building:

Index: setup.py
===================================================================
--- setup.py	(r?vision 85336)
+++ setup.py	(copie de travail)
@@ -1450,7 +1450,7 @@
         # The versions with dots are used on Unix, and the versions without
         # dots on Windows, for detection by cygwin.
         tcllib = tklib = tcl_includes = tk_includes = None
-        for version in ['8.5', '85', '8.4', '84', '8.3', '83', '8.2',
+        for version in ['8.6', '86', '8.5', '85', '8.4', '84', '8.3', '83', '8.2',
                         '82', '8.1', '81', '8.0', '80']:
             tklib = self.compiler.find_library_file(lib_dirs, 'tk' + version)
             tcllib = self.compiler.find_library_file(lib_dirs, 'tcl' + version)


However, there is then a test failure:

======================================================================
FAIL: test_tag_configure (tkinter.test.test_ttk.test_widgets.TreeviewTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/31/Lib/tkinter/test/test_ttk/test_widgets.py", line 1116, in test_tag_configure
    'blue')
AssertionError: <color object at 0x202a8f0> != 'blue'

----------
assignee: gpolo
components: Build
messages: 118260
nosy: gpolo, pitrou
priority: normal
severity: normal
status: open
title: Can't build tkinter with libtk 8.6
type: compile error
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10056>
_______________________________________

From report at bugs.python.org  Sat Oct  9 12:26:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 10:26:15 +0000
Subject: [issue10056] Can't build tkinter with libtk 8.6
In-Reply-To: <1286619510.51.0.775607940456.issue10056@psf.upfronthosting.co.za>
Message-ID: <1286619975.38.0.651674480058.issue10056@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r85337.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10056>
_______________________________________

From report at bugs.python.org  Sat Oct  9 12:28:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 10:28:47 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1286620127.52.0.160038181285.issue8445@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I backported the patch to 2.7 (r85335) and to 3.1 (r85338). Hopefully things will be ok now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sat Oct  9 12:47:48 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 09 Oct 2010 10:47:48 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif
	locale	and fileystem encodings aredifferent
In-Reply-To: <1286617506.3177.7.camel@localhost.localdomain>
Message-ID: <4CB04850.4000200@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The most likely values to be non-ASCII are, therefore, file paths. So it
> would make sense to also use the filesystem encoding for environment
> variables (so as to satisfy the common case).

-1. Environment variables are typically set in a text editor or on
the command line, so they will typically have the locale's encoding.

Applications that wish to support the case that fsencoding != locale
can recode the file names if desired, or use environb in the first
place.

If the mere existence of the fsname encoding leads to that much
confusion, I think I also support its removal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sat Oct  9 12:52:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 10:52:26 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif
	locale	and fileystem encodings aredifferent
In-Reply-To: <4CB04850.4000200@v.loewis.de>
Message-ID: <1286621540.3177.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> -1. Environment variables are typically set in a text editor or on
> the command line, so they will typically have the locale's encoding.

Fair enough.

> If the mere existence of the fsname encoding leads to that much
> confusion, I think I also support its removal.

Well, the fsname encoding has a hardwired value under OS X (regardless
of the locale), which kind of justifies its existence, no?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sat Oct  9 13:03:33 2010
From: report at bugs.python.org (Arnon Yaari)
Date: Sat, 09 Oct 2010 11:03:33 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1286622213.73.0.824658136637.issue9951@psf.upfronthosting.co.za>


Changes by Arnon Yaari <wiggin15 at gmail.com>:


Added file: http://bugs.python.org/file19175/bytes.hex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9951>
_______________________________________

From report at bugs.python.org  Sat Oct  9 13:03:41 2010
From: report at bugs.python.org (Arnon Yaari)
Date: Sat, 09 Oct 2010 11:03:41 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1286622221.98.0.430357065601.issue9951@psf.upfronthosting.co.za>


Changes by Arnon Yaari <wiggin15 at gmail.com>:


Removed file: http://bugs.python.org/file19018/bytes.hex.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9951>
_______________________________________

From report at bugs.python.org  Sat Oct  9 13:05:47 2010
From: report at bugs.python.org (Pascal Chambon)
Date: Sat, 09 Oct 2010 11:05:47 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286622347.0.0.856597171326.issue1553375@psf.upfronthosting.co.za>


Pascal Chambon <chambon.pascal at gmail.com> added the comment:

Indeed I don't understand the following part :

+                Traceback (most recent call last):
+                  File "testmod.py", line 16, in <module>
+                    {exception_action}
+                  File "testmod.py", line 6, in foo
+                    bar()
+                  File "testmod.py", line 11, in bar
+                    raise Exception
+                Exception

Why does the f_back of the first exception, when chain=True, leads back to the {exception_action} part, in the except: black, instead of the initial foo() call inside the try: block ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 13:19:50 2010
From: report at bugs.python.org (Eric Smith)
Date: Sat, 09 Oct 2010 11:19:50 +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: <1286623190.47.0.149691745079.issue10052@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From report at bugs.python.org  Sat Oct  9 13:36:25 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Oct 2010 11:36:25 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286624185.28.0.839424767678.issue1553375@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

The regression tests are failing for me, see

http://gist.github.com/618117

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 13:40:08 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Oct 2010 11:40:08 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286624408.39.0.590608390373.issue1553375@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Also, "fullstack" remains in one place in the docs. Should now say "allframes".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 13:49:52 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 09 Oct 2010 11:49:52 +0000
Subject: [issue9992] Command line arguments are not correctly decodedif
	locale	and fileystem encodings aredifferent
In-Reply-To: <1286621540.3177.10.camel@localhost.localdomain>
Message-ID: <4CB056DA.60006@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> If the mere existence of the fsname encoding leads to that much
>> confusion, I think I also support its removal.
> 
> Well, the fsname encoding has a hardwired value under OS X (regardless
> of the locale), which kind of justifies its existence, no?

Perhaps. We could also declare that command line arguments and
environment variables are always UTF-8-encoded on OSX (which I think
would be fairly accurate), and stop relying on the locale to determine
encodings on OSX (which Apple didn't like as a mechanism, anyway).
I think OSX converges faster to UTF-8 than the other Unices.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sat Oct  9 14:01:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Oct 2010 12:01:47 +0000
Subject: [issue9992] Command line arguments are not correctly
	decodediflocale	and fileystem encodingsaredifferent
In-Reply-To: <4CB056DA.60006@v.loewis.de>
Message-ID: <201010091401.37415.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Perhaps. We could also declare that command line arguments and
> environment variables are always UTF-8-encoded on OSX (which I think
> would be fairly accurate)

Python uses the filesystem encoding to encode/decode environment variables, 
and OSX, fs encoding is utf-8. For the command line, it would mean that we 
introduced a new encoding: "command line encoding", which will be utf-8 on 
OSX.

----------
title: Command line arguments are not correctly decodedif locale	and fileystem encodings aredifferent -> Command line arguments are not correctly decodediflocale	and fileystem encodingsaredifferent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sat Oct  9 14:07:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 12:07:19 +0000
Subject: [issue9992] Command line arguments are not correctly
	decodediflocale	and fileystem encodingsaredifferent
In-Reply-To: <201010091401.37415.victor.stinner@haypocalc.com>
Message-ID: <1286626022.3177.12.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> For the command line, it would mean that we 
> introduced a new encoding: "command line encoding", which will be utf-8 on 
> OSX.

Or more generally "environment encoding", if it's also used for env
vars. This could solve the subprocess issue neatly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sat Oct  9 14:28:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 09 Oct 2010 12:28:20 +0000
Subject: [issue9992] Command line arguments are not correctly
	decodediflocale	and fileystem encodingsaredifferent
In-Reply-To: <1286615690.16.0.96067019245.issue9992@psf.upfronthosting.co.za>
Message-ID: <201010091428.08437.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> So perhaps it would be best if Python had two external default encodings:
> the IO one (command line arguments, environment variables, text files),
> and the file name encoding (defaulting to the IO encoding if not set)

Hum, I prefer to consider the FS encoding as an *internal* encoding. ... But 
it's not completly true: it is used for the environment variables.

Let's consider that FS encoding is only an internal encoding. Wee need 3 
encodings:
 - FS encoding: any operation on the filesystem
 - IO encoding: text file contents (included stdin, stdout, stderr which are 
text files)
 - a 3rd encoding (let's call it the "command line encoding"): used for the 
command line arguments and the environment variables

For technical reasons ("bootstrap": Python initialization issues), I would 
like that the 3rd encoding is set using the locale encoding. The user can only 
control it using the classical locale variables (LC_ALL, LC_CTYPE, LANG).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sat Oct  9 15:01:00 2010
From: report at bugs.python.org (Arnon Yaari)
Date: Sat, 09 Oct 2010 13:01:00 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1286629260.02.0.795216990119.issue9951@psf.upfronthosting.co.za>


Arnon Yaari <wiggin15 at gmail.com> added the comment:

fixed to Py_UNICODE

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9951>
_______________________________________

From report at bugs.python.org  Sat Oct  9 16:34:42 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Sat, 09 Oct 2010 14:34:42 +0000
Subject: [issue8445] buildbot: test_ttk_guionly failures (test_traversal,
	test_tab_identifiers, test_identify, test_heading_callback)
In-Reply-To: <1271626152.34.0.828330480725.issue8445@psf.upfronthosting.co.za>
Message-ID: <1286634882.89.0.0740554432017.issue8445@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

For the record, everything (2.7, 3.1, and 3.x) runs this test successfully now. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8445>
_______________________________________

From report at bugs.python.org  Sat Oct  9 16:36:48 2010
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Sat, 09 Oct 2010 14:36:48 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286635008.48.0.447286215881.issue10049@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

Here is a more complete patch that includes input from Nick, as well as the patch to test_contextlib.py and the documentation.

For now I've retained the function-returning-singleton approach for consistency and future extensibility.

----------
keywords: +patch
Added file: http://bugs.python.org/file19176/nullcontext.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Sat Oct  9 16:56:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Oct 2010 14:56:12 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286636172.44.0.82156489121.issue1553375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Pascal: my question exactly.  The question is whether the code is accurately reflecting the state of the python stack at exception time (which it seems like it ought to), in which case I don't understand how Python handles the chained exception, or it doesn't, in which case (more likely) I'm not understanding how the stack frame is put together.

Vinay: so in your run the subprocess call is not producing the final 'exception detail' line...it looks like the last line of the output from subprocess is getting lost.  I've updated the patch to add a p.wait() before the assert...can you see if that fixes it?  I also fixed the doc nit, thanks.

----------
Added file: http://bugs.python.org/file19177/full_traceback3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 17:09:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 15:09:42 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1286636982.19.0.505753334351.issue9003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is another patch for http.client containing more tests, including with a mismatching cert. Comments welcome.

----------
Added file: http://bugs.python.org/file19178/httpcli2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Sat Oct  9 17:29:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 15:29:42 +0000
Subject: [issue10055] C99 code in _json.c
In-Reply-To: <1286613124.83.0.838959560604.issue10055@psf.upfronthosting.co.za>
Message-ID: <1286638182.84.0.155420588126.issue10055@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in 3.2 (r85342), 3.1 (r85343) and 2.7 (r85344). Thank you!

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10055>
_______________________________________

From report at bugs.python.org  Sat Oct  9 18:58:30 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Oct 2010 16:58:30 +0000
Subject: [issue9951] introduce bytes.hex method
In-Reply-To: <1285457928.18.0.422778723123.issue9951@psf.upfronthosting.co.za>
Message-ID: <1286643510.24.0.684269543503.issue9951@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
Removed message: http://bugs.python.org/msg117862

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9951>
_______________________________________

From report at bugs.python.org  Sat Oct  9 19:11:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 09 Oct 2010 17:11:29 +0000
Subject: [issue9992] Command line arguments are not correctly	decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <1286626022.3177.12.camel@localhost.localdomain>
Message-ID: <4CB0A23D.8010909@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 09.10.2010 14:07, schrieb Antoine Pitrou:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> For the command line, it would mean that we 
>> introduced a new encoding: "command line encoding", which will be utf-8 on 
>> OSX.
> 
> Or more generally "environment encoding", if it's also used for env
> vars. This could solve the subprocess issue neatly.

Please no. We run into problems because we have two inconsistent
encodings, and now you propose to introduce another one, allowing
for even more inconsistencies???

----------
title: Command line arguments are not correctly decodediflocale	and fileystem encodingsaredifferent -> Command line arguments are not correctly	decodediflocale and fileystem encodingsaredifferent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sat Oct  9 19:32:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 17:32:48 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <4CB0A23D.8010909@v.loewis.de>
Message-ID: <1286645561.3177.13.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Please no. We run into problems because we have two inconsistent
> encodings, and now you propose to introduce another one, allowing
> for even more inconsistencies???

It would not really be a "third encoding", since it would replace the
locale encoding for all pratical purposes, if I understand Victor's
proposal correctly.

----------
title: Command line arguments are not correctly	decodediflocale and fileystem encodingsaredifferent -> Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sat Oct  9 19:56:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 09 Oct 2010 17:56:08 +0000
Subject: [issue10008] Two links point to same place
In-Reply-To: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>
Message-ID: <1286646968.72.0.0980725530183.issue10008@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

*Your initial post* only lists one index entry, and *does not* describe a problem.

Thread
   module

is in the file you have pointed to twice, in its alphabetical position.

I have no idea what you think is wrong with the z section.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10008>
_______________________________________

From report at bugs.python.org  Sat Oct  9 20:02:00 2010
From: report at bugs.python.org (Jan Kratochvil)
Date: Sat, 09 Oct 2010 18:02:00 +0000
Subject: [issue10057] Unclear if exception should be set
In-Reply-To: <1286647320.48.0.566967627744.issue10057@psf.upfronthosting.co.za>
Message-ID: <1286647320.48.0.566967627744.issue10057@psf.upfronthosting.co.za>


New submission from Jan Kratochvil <jan.kratochvil at redhat.com>:

http://docs.python.org/py3k/c-api/object.html
PyObject_GetItem
Return element [...] or NULL on failure.

Found element => return its pointer.
Found no element => return NULL (with no exception set).

But it is unclear whether the function can also:
Error happened => return NULL with an exception set.

It affects multiple versions of the doc, did not check which all.

----------
assignee: docs at python
components: Documentation
messages: 118281
nosy: docs at python, jankratochvil
priority: normal
severity: normal
status: open
title: Unclear if exception should be set
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10057>
_______________________________________

From report at bugs.python.org  Sat Oct  9 20:17:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 09 Oct 2010 18:17:12 +0000
Subject: [issue10057] Unclear if exception should be set
In-Reply-To: <1286647320.48.0.566967627744.issue10057@psf.upfronthosting.co.za>
Message-ID: <1286648232.88.0.827710073832.issue10057@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I find it quite clear. "failure" not only means that no item was found, but also that the operation failed, i.e. raised an exception. In general, a NULL pointer returned from a function that returns PyObject* *always* means that there is an exception. There is no need to repeat that every time.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10057>
_______________________________________

From report at bugs.python.org  Sat Oct  9 20:30:38 2010
From: report at bugs.python.org (Jan Kratochvil)
Date: Sat, 09 Oct 2010 18:30:38 +0000
Subject: [issue10057] Unclear if exception should be set
In-Reply-To: <1286647320.48.0.566967627744.issue10057@psf.upfronthosting.co.za>
Message-ID: <1286649038.62.0.732237880991.issue10057@psf.upfronthosting.co.za>


Jan Kratochvil <jan.kratochvil at redhat.com> added the comment:

OK, I am not used to Python, thanks.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10057>
_______________________________________

From report at bugs.python.org  Sat Oct  9 20:37:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Oct 2010 18:37:48 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286649468.42.0.760592809483.issue1553375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

After giving this some thought, I'm sure that the observed results are not what we want, so I've changed the test to be the result that we want.  I haven't been able to figure out what is causing it, and am starting to wonder if it represents an actual bug in exception handling.

----------
Added file: http://bugs.python.org/file19179/full_traceback4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 20:40:29 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Oct 2010 18:40:29 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286649629.34.0.507323482815.issue1553375@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

It's still failing - the existing gist has been updated with the output from the new run:

http://gist.github.com/618117

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 20:44:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 09 Oct 2010 18:44:36 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286649876.16.0.696491643685.issue1553375@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

vinay: duh.  I'm using a debug build and my test is slicing off the refount line.  I think there's a helping in test.support for that...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 21:04:11 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Oct 2010 19:04:11 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286651051.45.0.355648146933.issue1553375@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

David, I don't think it's that - I think it's the subprocess comms. This works:

    def _do_test(self, program, exc_text):
        with open(self.testfn, 'w') as testmod:
            testmod.writelines(program.format(
                exception_action=self.exception_action))
        p = subprocess.Popen([sys.executable, 'testmod.py'],
                              stderr=subprocess.PIPE)
        streams = p.communicate()
        v1 = streams[1].decode('utf-8') # this shouldn't be hardcoded!
        v2 = exc_text.format(exception_action=self.exception_action)
        self.assertEqual(v1, v2)

But I don't think the 'utf-8' encoding should be hardcoded. Not sure what to use - sys.getfilesystemencoding()? locale.getpreferredencoding()? 

Decisions, decisions :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 21:05:48 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Oct 2010 19:05:48 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286651148.61.0.0503180691852.issue1553375@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Also, the use of literal 'testmod.py' in _do_test should probably be replaced by self.testfn.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 21:12:39 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Oct 2010 19:12:39 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286651559.91.0.94772772684.issue1553375@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

On reflection, perhaps we should use sys.stdin.encoding to decode the value received from the subprocess. What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 22:13:00 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 09 Oct 2010 20:13:00 +0000
Subject: [issue1553375] Add traceback.print_full_exception()
Message-ID: <1286655180.88.0.554497840471.issue1553375@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Attached a patch which works on my machine.

----------
Added file: http://bugs.python.org/file19180/full_traceback5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1553375>
_______________________________________

From report at bugs.python.org  Sat Oct  9 23:34:18 2010
From: report at bugs.python.org (geremy condra)
Date: Sat, 09 Oct 2010 21:34:18 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <1286636982.19.0.505753334351.issue9003@psf.upfronthosting.co.za>
Message-ID: <AANLkTikebDzT0xCJ+8k8McSr2Mf-v7ZAPYo6rv2Fc6wm@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

Any chance on folding the HTTPSServer class into http.server?

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Sat Oct  9 23:56:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 09 Oct 2010 21:56:57 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <AANLkTikebDzT0xCJ+8k8McSr2Mf-v7ZAPYo6rv2Fc6wm@mail.gmail.com>
Message-ID: <1286661411.3177.15.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Any chance on folding the HTTPSServer class into http.server?

Its API and implementation would first have to be cleaned up.
I'd prefer if it were the subject of a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Sun Oct 10 00:21:58 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 09 Oct 2010 22:21:58 +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: <1286662918.19.0.963331237634.issue10052@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Thanks for the report.  Some questions:

1. Have you tested this with Python 3.x at all?  I'd expect the same issues to show up for Python 3.1 and 3.2.

2. Also, do you have the relevant configure output to hand?  On my machine, the output from './configure' includes:

checking for uint32_t... yes
checking for uint64_t... yes
checking for int32_t... no
checking for int64_t... no
checking for ssize_t... yes

what do you get here?  (Aside:  those .... 'no's look odd to me;  I think there may be an autoconf bug here.)

3. Do you know which header file declares uint32_t on FreeBSD 4?

IIRC, the theory is that if stdint.h or inttypes.h #defines/typedefs uint32_t, then the UINT32_T_MAX macro should also be #defined somewhere in one of those header files;  OTOH if neither stdint nor inttypes includes declarations for uint32_t then the configure script should find something suitable, and #define uint32_t.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From report at bugs.python.org  Sun Oct 10 01:37:58 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 09 Oct 2010 23:37:58 +0000
Subject: [issue10058] Unclear PyString_AsStringAndSize return value
In-Reply-To: <1286667477.81.0.428824967814.issue10058@psf.upfronthosting.co.za>
Message-ID: <1286667477.81.0.428824967814.issue10058@psf.upfronthosting.co.za>


New submission from Nikolaus Rath <Nikolaus at rath.org>:

http://docs.python.org/c-api/string.html says about the return value of AsStringAndSize:

"If length is NULL, the resulting buffer may not contain NUL characters; if it does, the function returns -1 and a TypeError is raised."

"If string is not a string object at all, PyString_AsStringAndSize() returns -1 and raises TypeError."

This makes me wonder what the return code is if a) the function succeeds and b) it encounteres some other problem (i.e. out of memory when it tries to encode a unicode string into its default encoding).

I guess that the return value is 0 on success and -1 on all errors, but it would be nice if the documentation would be clear about this.

----------
assignee: docs at python
components: Documentation
messages: 118294
nosy: Nikratio, docs at python
priority: normal
severity: normal
status: open
title: Unclear PyString_AsStringAndSize return value
type: feature request
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10058>
_______________________________________

From report at bugs.python.org  Sun Oct 10 02:06:30 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 10 Oct 2010 00:06:30 +0000
Subject: [issue10008] Two links point to same place
In-Reply-To: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>
Message-ID: <1286669190.0.0.757225138291.issue10008@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, please see r85262 (10/6). This issue seems to be
recently solved in release27-maint. And http://docs.python.org/
was updated after that, so when I posted this issue, the issue was
actually there, but when you saw that site, (probably after
10/6, the issue was gone)

http://docs.python.org/release/2.7/
was created when officially Python2.7 was released,
so we can see this issue still there. Like time machine. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10008>
_______________________________________

From report at bugs.python.org  Sun Oct 10 02:23:47 2010
From: report at bugs.python.org (Simon Liedtke)
Date: Sun, 10 Oct 2010 00:23:47 +0000
Subject: [issue10059] add the method `index` to collections.deque
In-Reply-To: <1286670227.45.0.57597987933.issue10059@psf.upfronthosting.co.za>
Message-ID: <1286670227.45.0.57597987933.issue10059@psf.upfronthosting.co.za>


New submission from Simon Liedtke <liedtke.simon at googlemail.com>:

I'd like to have the method `index` not only for list, but also for collections.deque.

Here is my attempt: http://bitbucket.org/derdon/hodgepodge/src/tip/extended_deque.py

I'm looking forward to see this method implemented in the stdlib!

----------
components: Library (Lib)
messages: 118296
nosy: Simon.Liedtke
priority: normal
severity: normal
status: open
title: add the method `index` to collections.deque
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10059>
_______________________________________

From report at bugs.python.org  Sun Oct 10 03:37:59 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Oct 2010 01:37:59 +0000
Subject: [issue10059] add the method `index` to collections.deque
In-Reply-To: <1286670227.45.0.57597987933.issue10059@psf.upfronthosting.co.za>
Message-ID: <1286674679.68.0.869262377976.issue10059@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Since you are requesting adding a method to an existing data type, you should probably raise this issue first on the python-ideas mailing list and be prepared to justify use cases for it.

http://mail.python.org/mailman/listinfo/python-ideas

----------
nosy: +ned.deily, rhettinger, stutzbach
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10059>
_______________________________________

From report at bugs.python.org  Sun Oct 10 04:03:47 2010
From: report at bugs.python.org (Dev Player)
Date: Sun, 10 Oct 2010 02:03:47 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>


New submission from Dev Player <devplayer at gmail.com>:

2010-10-10 python.exe crashes or hangs on help() modules 
when bad modules found

#######################################################################
SUMMARY

The python.exe command line interpreter crashes or hangs when
typing first >>>help() then >modules and a corrupt module is found.

Python 2.7 WinXP SP3 see version details in OUTPUT sections
#######################################################################
EXPLANATION

# -----------------------
I have a workaround as a user. However it appears to be a bug 
from previous Python versions, 2.5 and 2.6 from what I've seen 
through Google and other help() module tickets. 

The workaround is simply remove the corrupt package.

# -----------------------
I've noticed when there is a corrupt package on my PC in the 
Q:\Python27\Lib\site-packages folder that seems to cause 
a problem when issuing >>>help() then >modules in Python. 

Python command line interperter doesn't gracefully exit the 
assertion, it crashes or hangs.

When entering python.exe, idle.exe or pycrust.bat (runs pycrust.py),
typing help(), then typing modules, the help routine runs most of 
the "search-for-packages" routine fine (see OUTPUT SECTION below) 
and seems to find all the installed modules but when it's 
finished it does the following:

- python.exe either crashes, or puts up a help> prompt window and 
  then drops to the DOS command prompt as seen below.

  MS window error:
  python.exe has encountered a problem and needs to clos.
  We are sorry for the inconvienience
  AppName: python.exe
  AppVer: 0.0.0.0
  ModName: unknown
  ModVer: 0.0.0.0
  Offset: 00a20fdf

- IDLE.py doesn't crash but after the >>>help() >modules it shows
  the errors in .py files

- PyCrust.py runs the >>>help() > modules it then shows errors 
  in .py files, it then crashes


In my case you will note the problem occurs on my install of the 
pythonwin package. On my system pythonwin will work until I exit. 

I installed a new version pythonwin just after installing Python 2.7.
The pythonwin version always crashed on exit since it was installed. 
The old pythonwin was deinstalled before installation of the new.

However, having a corrupt installed package shouldn't crash python.

pythonwin version: pywin32 build214

# -----------------------
Something of note:
    All my development, including Python 2.7 installation and 
    packages and projects are on my Q: drive, which is 
    a mapped drive pointing to a sub-folder on a 
    networked-shared folder in WinXP.

    Actual Folder:
        D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT
    Net-shared Folder:
       \\Mycomp\D$\Subst_drives
    Mapped Folder:
        Q: = \\Mycomp\D$\Subst_drives\DRIVE_Q_DEVELOPMENT

    Although not directly used by the user (me) I also have 
    subst'd drives attached to sub-folders of:
    D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT
    such as:
    U: = D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT\Projects\Python27\current

    I only mention this in case the >>>help() >modules routine, 
    while seeking modules, can traverse folder structure attached 
    to soft and hard link combos, symbolic links and junction points 
    or whether they have an effect on traversing the folder structure 
    while searching for packages.

However, I went directly to the folder holding python.exe
at D:\SUBST_DRIVES\DRIVE_Q_DEVELOPMENT\Python27\python.exe
When doing help() modules .\python.exe crashed at the end of 
executing "modules" as well.

# -----------------------
So far, I personally have not come across any other issues 
with my installation and python programs and demo code run 
with Python 2.7 except the previously noted exiting-of-pythonwin

# -----------------------
Further details and output from running help() modules below for each
of python.exe, pycrust and idle.


#######################################################################
OUTPUT 
(3 Sections for 3 programs packaged with Python distribution)
#######################################################################
#######################################################################
#######################################################################
SECTION 1 OF 3 
python.exe
#----------------------------------------------------------------------

Q:\Projects\Python27>python.exe
Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> help()

Welcome to Python 2.7!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help> modules

Please wait a moment while I gather a list of all available modules...

AutoComplete        _threading_local    itertools           sspi
AutoCompleteWindow  _tkinter            json                sspicon
AutoExpand          _warnings           keybindingDialog    stat
BaseHTTPServer      _weakref            keyword             statvfs
Bastion             _weakrefset         lib                 string
Bindings            _win32sysloader     lib2to3             stringold
CGIHTTPServer       _winreg             linecache           stringprep
CallTipWindow       _winxptheme         locale              strop
CallTips            abc                 logging             struct
Canvas              aboutDialog         macosxSupport       subprocess
ClassBrowser        adodbapi            macpath             sunau
CodeContext         afxres              macurl2path         sunaudio
ColorDelegator      aifc                mailbox             symbol
ConfigParser        antigravity         mailcap             symtable
Cookie              anydbm              markupbase          sys
CreateBatchFiles    app                 marshal             sysconfig
CreateMacScripts    argparse            math                tabbedpages
Debugger            array               md5                 tabnanny
Delegator           ast                 media               tarfile
Dialog              asynchat            mhlib               telnetlib
DocXMLRPCServer     asyncore            mimetools           tempfile
EditorWindow        atexit              mimetypes           test
Enums               audiodev            mimify              testcode
FileDialog          audioop             mmap                tests
FileList            base64              mmapfile            text
FixTk               bdb                 mmsystem            textView
FormatParagraph     binascii            modulefinder        textwrap
GrepDialog          binhex              msilib              this
HTMLParser          bisect              msvcrt              thread
HyperParser         bsddb               multifile           threading
ID_NS               bz2                 multiprocessing     time
IOBinding           cPickle             mutex               timeit
IdleHistory         cProfile            netbios             timer
MOCK_WX             cStringIO           netrc               tkColorChooser
MimeWriter          calendar            new                 tkCommonDialog
MultiCall           cgi                 nntplib             tkFileDialog
MultiStatusBar      cgitb               nt                  tkFont
ObjectBrowser       chunk               ntpath              tkMessageBox
ObjectListView      clock               ntsecuritycon       tkSimpleDialog
OutputWindow        cmath               nturl2path          toaiff
ParenMatch          cmd                 numbers             token
PathBrowser         code                odbc                tokenize
Percolator          codecs              opcode              trace
PyParse             codeop              operator            traceback
PyShell             collections         optparse            ttk
PythonOgreConfig    colorsys            os                  tty
Queue               com                 os2emxpath          turtle
RemoteDebugger      commands            parser              types
RemoteObjectBrowser commctrl            pdb                 unicodedata
ReplaceDialog       compileall          perfmon             unittest
ReportVersion       compiler            pickle              urllib
RstripExtension     configDialog        pickletools         urllib2
SampleFramework     configHandler       pipes               urlparse
ScriptBinding       configHelpSourceEdit pkgutil             user
ScrolledList        configSectionNameDialog platform            utils
ScrolledText        contextlib          plistlib            uu
SearchDialog        convert_to_PANP     popen2              uuid
SearchDialogBase    cookielib           poplib              warnings
SearchEngine        copy                posixfile           wave
SimpleDialog        copy_reg            posixpath           weakref
SimpleHTTPServer    core                pprint              webbrowser
SimpleXMLRPCServer  csv                 profile             whichdb
SocketServer        ctypes              pstats              win2kras
StackViewer         curses              pty                 win32api
StringIO            datetime            pub                 win32clipboard
Tix                 dbhash              pubsub              win32com
Tkconstants         dbi                 pubsub1             win32con
Tkdnd               dde                 pubsubconf          win32console
Tkinter             decimal             py_compile          win32cred
ToolTip             difflib             pyclbr              win32crypt
TreeWidget          dircache            pycrust_c           win32cryptcon
UndoDelegator       dis                 pycrust_gdir        win32event
UserDict            distutils           pydoc               win32evtlog
UserList            doctest             pydoc_data          win32evtlogutil
UserString          dprint              pyexpat             win32file
WidgetRedirector    dumbdbm             pyglet              win32gui
WindowList          dummy_thread        pythoncom           win32gui_struct
ZoomHeight          dummy_threading     pythonstartup       win32help
_LWPCookieJar       dynOptionMenuWidget pywin               win32inet
_MozillaCookieJar   email               pywin32_postinstall win32inetcon
__builtin__         encodings           pywin32_testutil    win32job
__future__          errno               pywintypes          win32lz
_abcoll             event               quopri              win32net
_ast                exceptions          random              win32netcon
_autosetuppubsubv1  filecmp             rasutil             win32pdh
_bisect             fileinput           re                  win32pdhquery
_bsddb              fnmatch             regcheck            win32pdhutil
_codecs             font                regutil             win32pipe
_codecs_cn          formatter           repr                win32print
_codecs_hk          fpformat            resource            win32process
_codecs_iso2022     fractions           rexec               win32profile
_codecs_jp          ftplib              rfc822              win32ras
_codecs_kr          functools           rlcompleter         win32rcparser
_codecs_tw          future_builtins     robotparser         win32security
_collections        gc                  rpc                 win32service
_csv                genericpath         run                 win32serviceutil
_ctypes             getopt              runpy               win32timezone
_ctypes_test        getpass             sched               win32trace
_elementtree        gettext             select              win32traceutil
_functools          gl                  servicemanager      win32transaction
_hashlib            glob                sets                win32ts
_heapq              graphics            setup               win32ui
_hotshot            gzip                setuparg1           win32uiole
_io                 hashlib             setupkwargs         win32verstamp
_json               heapq               setupv1             win32wnet
_locale             hmac                setupv2             window
_lsprof             hotshot             sgmllib             winerror
_md5                htmlentitydefs      sha                 winioctlcon
_msi                htmllib             shelve              winnt
_multibytecodec     httplib             shlex               winperf
_multiprocessing    idle                shutil              winsound
_pyio               idlelib             signal              winxpgui
_random             idlever             singletonmixin      winxptheme
_sha                ihooks              site                wsgiref
_sha256             image               smtpd               wx
_sha512             imageop             smtplib             wxPython
_socket             imaplib             sndhdr              wxversion
_sqlite3            imghdr              socket              xdrlib
_sre                imp                 sprite              xml
_ssl                importlib           sqlite3             xmllib
_strptime           imputil             sre                 xmlrpclib
_struct             info                sre_compile         xxsubtype
_subprocess         inspect             sre_constants       zipfile
_symtable           io                  sre_parse           zipimport
_testcapi           isapi               ssl                 zlib

Enter any module name to get more help.  Or, type "modules spam" to search
for modules whose descriptions contain the word "spam".


Q:\Projects\Python27>

#----------------------------------------------------------------------
WHAT YOU SEE ABOVE a copy and past:
python.exe either crashes, or puts up a help> prompt window and then 
drops to the DOS command prompt as seen above without indicating
there was a corrupt package.

#######################################################################
#######################################################################
#######################################################################
SECTION 2 OF 3 
IDLE
#----------------------------------------------------------------------

Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "copyright", "credits" or "license()" for more information.

>>> help()

Welcome to Python 2.7!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help> modules

Please wait a moment while I gather a list of all available modules...

AutoComplete        _threading_local    itertools           sspi
AutoCompleteWindow  _tkinter            json                sspicon
AutoExpand          _warnings           keybindingDialog    stat
BaseHTTPServer      _weakref            keyword             statvfs
Bastion             _weakrefset         lib                 string
Bindings            _win32sysloader     lib2to3             stringold
CGIHTTPServer       _winreg             linecache           stringprep
CallTipWindow       _winxptheme         locale              strop
CallTips            abc                 logging             struct
Canvas              aboutDialog         macosxSupport       subprocess
ClassBrowser        adodbapi            macpath             sunau
CodeContext         afxres              macurl2path         sunaudio
ColorDelegator      aifc                mailbox             symbol
ConfigParser        antigravity         mailcap             symtable
Cookie              anydbm              markupbase          sys
CreateBatchFiles    app                 marshal             sysconfig
CreateMacScripts    argparse            math                tabbedpages
Debugger            array               md5                 tabnanny
Delegator           ast                 media               tarfile
Dialog              asynchat            mhlib               telnetlib
DocXMLRPCServer     asyncore            mimetools           tempfile
EditorWindow        atexit              mimetypes           test
Enums               audiodev            mimify              testcode
FileDialog          audioop             mmap                tests
FileList            base64              mmapfile            text
FixTk               bdb                 mmsystem            textView
FormatParagraph     binascii            modulefinder        textwrap
GrepDialog          binhex              msilib              this
HTMLParser          bisect              msvcrt              thread
HyperParser         bsddb               multifile           threading
ID_NS               bz2                 multiprocessing     time
IOBinding           cPickle             mutex               timeit
IdleHistory         cProfile            netbios             timer
MOCK_WX             cStringIO           netrc               tkColorChooser
MimeWriter          calendar            new                 tkCommonDialog
MultiCall           cgi                 nntplib             tkFileDialog
MultiStatusBar      cgitb               nt                  tkFont
ObjectBrowser       chunk               ntpath              tkMessageBox
ObjectListView      clock               ntsecuritycon       tkSimpleDialog
OutputWindow        cmath               nturl2path          toaiff
ParenMatch          cmd                 numbers             token
PathBrowser         code                odbc                tokenize
Percolator          codecs              opcode              trace
PyParse             codeop              operator            traceback
PyShell             collections         optparse            ttk
PythonOgreConfig    colorsys            os                  tty
Queue               com                 os2emxpath          turtle
RemoteDebugger      commands            parser              types
RemoteObjectBrowser commctrl            pdb                 unicodedata
ReplaceDialog       compileall          perfmon             unittest
ReportVersion       compiler            pickle              urllib
RstripExtension     configDialog        pickletools         urllib2
SampleFramework     configHandler       pipes               urlparse
ScriptBinding       configHelpSourceEdit pkgutil             user
ScrolledList        configSectionNameDialog platform            utils
ScrolledText        contextlib          plistlib            uu
SearchDialog        convert_to_PANP     popen2              uuid
SearchDialogBase    cookielib           poplib              warnings
SearchEngine        copy                posixfile           wave
SimpleDialog        copy_reg            posixpath           weakref
SimpleHTTPServer    core                pprint              webbrowser
SimpleXMLRPCServer  csv                 profile             whichdb
SocketServer        ctypes              pstats              win2kras
StackViewer         curses              pty                 win32api
StringIO            datetime            pub                 win32clipboard
Tix                 dbhash              pubsub              win32com
Tkconstants         dbi                 pubsub1             win32con
Tkdnd               dde                 pubsubconf          win32console
Tkinter             decimal             py_compile          win32cred
ToolTip             difflib             pyclbr              win32crypt
TreeWidget          dircache            pycrust_c           win32cryptcon
UndoDelegator       dis                 pycrust_gdir        win32event
UserDict            distutils           pydoc               win32evtlog
UserList            doctest             pydoc_data          win32evtlogutil
UserString          dprint              pyexpat             win32file
WidgetRedirector    dumbdbm             pyglet              win32gui
WindowList          dummy_thread        pythoncom           win32gui_struct
ZoomHeight          dummy_threading     pythonstartup       win32help
_LWPCookieJar       dynOptionMenuWidget pywin               win32inet
_MozillaCookieJar   email               pywin32_postinstall win32inetcon
__builtin__         encodings           pywin32_testutil    win32job
__future__          errno               pywintypes          win32lz
_abcoll             event               quopri              win32net
_ast                exceptions          random              win32netcon
_autosetuppubsubv1  filecmp             rasutil             win32pdh
_bisect             fileinput           re                  win32pdhquery
_bsddb              fnmatch             regcheck            win32pdhutil
_codecs             font                regutil             win32pipe
_codecs_cn          formatter           repr                win32print
_codecs_hk          fpformat            resource            win32process
_codecs_iso2022     fractions           rexec               win32profile
_codecs_jp          ftplib              rfc822              win32ras
_codecs_kr          functools           rlcompleter         win32rcparser
_codecs_tw          future_builtins     robotparser         win32security
_collections        gc                  rpc                 win32service
_csv                genericpath         run                 win32serviceutil
_ctypes             getopt              runpy               win32timezone
_ctypes_test        getpass             sched               win32trace
_elementtree        gettext             select              win32traceutil
_functools          gl                  servicemanager      win32transaction
_hashlib            glob                sets                win32ts
_heapq              graphics            setup               win32ui
_hotshot            gzip                setuparg1           win32uiole
_io                 hashlib             setupkwargs         win32verstamp
_json               heapq               setupv1             win32wnet
_locale             hmac                setupv2             window
_lsprof             hotshot             sgmllib             winerror
_md5                htmlentitydefs      sha                 winioctlcon
_msi                htmllib             shelve              winnt
_multibytecodec     httplib             shlex               winperf
_multiprocessing    idle                shutil              winsound
_pyio               idlelib             signal              winxpgui
_random             idlever             singletonmixin      winxptheme
_sha                ihooks              site                wsgiref
_sha256             image               smtpd               wx
_sha512             imageop             smtplib             wxPython
_socket             imaplib             sndhdr              wxversion
_sqlite3            imghdr              socket              xdrlib
_sre                imp                 sprite              xml
_ssl                importlib           sqlite3             xmllib
_strptime           imputil             sre                 xmlrpclib
_struct             info                sre_compile         xxsubtype
_subprocess         inspect             sre_constants       zipfile
_symtable           io                  sre_parse           zipimport
_testcapi           isapi               ssl                 zlib

Enter any module name to get more help.  Or, type "modules spam" to search
for modules whose descriptions contain the word "spam".


Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    help()
  File "Q:\Python27\lib\site.py", line 453, in __call__
    return pydoc.help(*args, **kwds)
  File "Q:\Python27\lib\pydoc.py", line 1723, in __call__
    self.interact()
  File "Q:\Python27\lib\pydoc.py", line 1735, in interact
    request = self.getline('help> ')
  File "Q:\Python27\lib\pydoc.py", line 1746, in getline
    return raw_input(prompt)
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py", line 367, in Win32RawInput
    ret=dialog.GetSimpleInput(prompt)
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 223, in GetSimpleInput
    if title is None: title=win32ui.GetMainFrame().GetWindowText()
error: The frame does not exist
>>> 

#----------------------------------------------------------------------
IDLE doesn't crash

#######################################################################
#######################################################################
#######################################################################
SECTION 3 OF 3 
PyCrust
#----------------------------------------------------------------------

PyCrust 0.9.8 - The Flakiest Python Shell
Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Startup script executed: C:\Documents and Settings\User\Application Data\pycrust\startup
help()

Welcome to Python 2.7!  This is the online help utility.

If this is your first time using Python, you should definitely check out
the tutorial on the Internet at http://docs.python.org/tutorial/.

Enter the name of any module, keyword, or topic to get help on writing
Python programs and using Python modules.  To quit this help utility and
return to the interpreter, just type "quit".

To get a list of available modules, keywords, or topics, type "modules",
"keywords", or "topics".  Each module also comes with a one-line summary
of what it does; to list the modules whose summaries contain a given word
such as "spam", type "modules spam".

help> modules

Please wait a moment while I gather a list of all available modules...

AutoComplete        _threading_local    itertools           sspi
AutoCompleteWindow  _tkinter            json                sspicon
AutoExpand          _warnings           keybindingDialog    stat
BaseHTTPServer      _weakref            keyword             statvfs
Bastion             _weakrefset         lib                 string
Bindings            _win32sysloader     lib2to3             stringold
CGIHTTPServer       _winreg             linecache           stringprep
CallTipWindow       _winxptheme         locale              strop
CallTips            abc                 logging             struct
Canvas              aboutDialog         macosxSupport       subprocess
ClassBrowser        adodbapi            macpath             sunau
CodeContext         afxres              macurl2path         sunaudio
ColorDelegator      aifc                mailbox             symbol
ConfigParser        antigravity         mailcap             symtable
Cookie              anydbm              markupbase          sys
CreateBatchFiles    app                 marshal             sysconfig
CreateMacScripts    argparse            math                tabbedpages
Debugger            array               md5                 tabnanny
Delegator           ast                 media               tarfile
Dialog              asynchat            mhlib               telnetlib
DocXMLRPCServer     asyncore            mimetools           tempfile
EditorWindow        atexit              mimetypes           test
Enums               audiodev            mimify              testcode
FileDialog          audioop             mmap                tests
FileList            base64              mmapfile            text
FixTk               bdb                 mmsystem            textView
FormatParagraph     binascii            modulefinder        textwrap
GrepDialog          binhex              msilib              this
HTMLParser          bisect              msvcrt              thread
HyperParser         bsddb               multifile           threading
ID_NS               bz2                 multiprocessing     time
IOBinding           cPickle             mutex               timeit
IdleHistory         cProfile            netbios             timer
MOCK_WX             cStringIO           netrc               tkColorChooser
MimeWriter          calendar            new                 tkCommonDialog
MultiCall           cgi                 nntplib             tkFileDialog
MultiStatusBar      cgitb               nt                  tkFont
ObjectBrowser       chunk               ntpath              tkMessageBox
ObjectListView      clock               ntsecuritycon       tkSimpleDialog
OutputWindow        cmath               nturl2path          toaiff
ParenMatch          cmd                 numbers             token
PathBrowser         code                odbc                tokenize
Percolator          codecs              opcode              trace
PyParse             codeop              operator            traceback
PyShell             collections         optparse            ttk
PythonOgreConfig    colorsys            os                  tty
Queue               com                 os2emxpath          turtle
RemoteDebugger      commands            parser              types
RemoteObjectBrowser commctrl            pdb                 unicodedata
ReplaceDialog       compileall          perfmon             unittest
ReportVersion       compiler            pickle              urllib
RstripExtension     configDialog        pickletools         urllib2
SampleFramework     configHandler       pipes               urlparse
ScriptBinding       configHelpSourceEdit pkgutil             user
ScrolledList        configSectionNameDialog platform            utils
ScrolledText        contextlib          plistlib            uu
SearchDialog        convert_to_PANP     popen2              uuid
SearchDialogBase    cookielib           poplib              warnings
SearchEngine        copy                posixfile           wave
SimpleDialog        copy_reg            posixpath           weakref
SimpleHTTPServer    core                pprint              webbrowser
SimpleXMLRPCServer  csv                 profile             whichdb
SocketServer        ctypes              pstats              win2kras
StackViewer         curses              pty                 win32api
StringIO            datetime            pub                 win32clipboard
Tix                 dbhash              pubsub              win32com
Tkconstants         dbi                 pubsub1             win32con
Tkdnd               dde                 pubsubconf          win32console
Tkinter             decimal             py_compile          win32cred
ToolTip             difflib             pyclbr              win32crypt
TreeWidget          dircache            pycrust_c           win32cryptcon
UndoDelegator       dis                 pycrust_gdir        win32event
UserDict            distutils           pydoc               win32evtlog
UserList            doctest             pydoc_data          win32evtlogutil
UserString          dprint              pyexpat             win32file
WidgetRedirector    dumbdbm             pyglet              win32gui
WindowList          dummy_thread        pythoncom           win32gui_struct
ZoomHeight          dummy_threading     pythonstartup       win32help
_LWPCookieJar       dynOptionMenuWidget pywin               win32inet
_MozillaCookieJar   email               pywin32_postinstall win32inetcon
__builtin__         encodings           pywin32_testutil    win32job
__future__          errno               pywintypes          win32lz
_abcoll             event               quopri              win32net
_ast                exceptions          random              win32netcon
_autosetuppubsubv1  filecmp             rasutil             win32pdh
_bisect             fileinput           re                  win32pdhquery
_bsddb              fnmatch             regcheck            win32pdhutil
_codecs             font                regutil             win32pipe
_codecs_cn          formatter           repr                win32print
_codecs_hk          fpformat            resource            win32process
_codecs_iso2022     fractions           rexec               win32profile
_codecs_jp          ftplib              rfc822              win32ras
_codecs_kr          functools           rlcompleter         win32rcparser
_codecs_tw          future_builtins     robotparser         win32security
_collections        gc                  rpc                 win32service
_csv                genericpath         run                 win32serviceutil
_ctypes             getopt              runpy               win32timezone
_ctypes_test        getpass             sched               win32trace
_elementtree        gettext             select              win32traceutil
_functools          gl                  servicemanager      win32transaction
_hashlib            glob                sets                win32ts
_heapq              graphics            setup               win32ui
_hotshot            gzip                setuparg1           win32uiole
_io                 hashlib             setupkwargs         win32verstamp
_json               heapq               setupv1             win32wnet
_locale             hmac                setupv2             window
_lsprof             hotshot             sgmllib             winerror
_md5                htmlentitydefs      sha                 winioctlcon
_msi                htmllib             shelve              winnt
_multibytecodec     httplib             shlex               winperf
_multiprocessing    idle                shutil              winsound
_pyio               idlelib             signal              winxpgui
_random             idlever             singletonmixin      winxptheme
_sha                ihooks              site                wsgiref
_sha256             image               smtpd               wx
_sha512             imageop             smtplib             wxPython
_socket             imaplib             sndhdr              wxversion
_sqlite3            imghdr              socket              xdrlib
_sre                imp                 sprite              xml
_ssl                importlib           sqlite3             xmllib
_strptime           imputil             sre                 xmlrpclib
_struct             info                sre_compile         xxsubtype
_subprocess         inspect             sre_constants       zipfile
_symtable           io                  sre_parse           zipimport
_testcapi           isapi               ssl                 zlib

Enter any module name to get more help.  Or, type "modules spam" to search
for modules whose descriptions contain the word "spam".

Traceback (most recent call last):
  File "<input>", line 1, in <module>
  File "Q:\Python27\lib\site.py", line 453, in __call__
    return pydoc.help(*args, **kwds)
  File "Q:\Python27\lib\pydoc.py", line 1723, in __call__
    self.interact()
  File "Q:\Python27\lib\pydoc.py", line 1735, in interact
    request = self.getline('help> ')
  File "Q:\Python27\lib\pydoc.py", line 1746, in getline
    return raw_input(prompt)
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py", line 367, in Win32RawInput
    ret=dialog.GetSimpleInput(prompt)
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 223, in GetSimpleInput
    if title is None: title=win32ui.GetMainFrame().GetWindowText()
error: The frame does not exist

#----------------------------------------------------------------------
Then after doing anything in PyCrust it crashes

#######################################################################
#######################################################################
#######################################################################

----------
components: IDLE
messages: 118298
nosy: devplayer
priority: normal
severity: normal
status: open
title: python.exe crashes or hangs on help() modules when bad modules found
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Sun Oct 10 04:21:15 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 10 Oct 2010 02:21:15 +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: <1286677275.73.0.222962849259.issue10052@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

> 1. Have you tested this with Python 3.x at all?  I'd expect the same issues to show up for Python 3.1 and 3.2.

Yes, I can reproduce this in 2.7, 3.1 and 3.2.

> 2. Also, do you have the relevant configure output to hand?  On my machine, the output from './configure' includes:
> 
> checking for uint32_t... yes
> checking for uint64_t... yes
> checking for int32_t... no
> checking for int64_t... no
> checking for ssize_t... yes
>
> what do you get here?  (Aside:  those .... 'no's look odd to me;  I think there may be an autoconf bug here.)

Same here. It looks like a bug in autoconf:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560105

My output is below:

"""
checking for uint32_t... yes
checking for uint64_t... yes
checking for int32_t... no
checking for int64_t... no
checking for ssize_t... yes
"""

> 3. Do you know which header file declares uint32_t on FreeBSD 4?

They are declared in inttypes.h.

"""
/*
 * This file is in the public domain.
 * $FreeBSD: src/sys/sys/inttypes.h,v 1.2 1999/08/28 00:51:47 peter Exp $
 */

#ifndef _SYS_INTTYPES_H_
#define _SYS_INTTYPES_H_

#include <machine/ansi.h>

typedef __int8_t        int8_t;
typedef __int16_t       int16_t;
typedef __int32_t       int32_t;
typedef __int64_t       int64_t;

typedef __uint8_t       uint8_t;
typedef __uint16_t      uint16_t;
typedef __uint32_t      uint32_t;
typedef __uint64_t      uint64_t;

typedef __intptr_t      intptr_t;
typedef __uintptr_t     uintptr_t;

#endif /* !_SYS_INTTYPES_H_ */
"""

----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From orsenthil at gmail.com  Sun Oct 10 05:49:35 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Sun, 10 Oct 2010 09:19:35 +0530
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <AANLkTikO4pugmpBuZR=n7NBfMn5fHWPd_d7yh4GDFXQ1@mail.gmail.com>
References: <1286480237.64.0.444141117326.issue10029@psf.upfronthosting.co.za>
	<AANLkTikO4pugmpBuZR=n7NBfMn5fHWPd_d7yh4GDFXQ1@mail.gmail.com>
Message-ID: <20101010034935.GA3487@remy>

On Fri, Oct 08, 2010 at 06:25:26PM +0000, Alexander Belopolsky wrote:
> In this case, I wonder if "equivalent to" code should be added to the
> section for enumerate() and map().  Also since any() and all() have
> "equivalent to" code, I think min(), max() and sum() deserve it as
> well.

I think, you are asking for consistency in docs, right?

As a sidenote those explanations should be okay, but merging it with
the explanation of the functions may add to confusion (like the zip
example did in this case). 

Even I am +1 on removing that complex equivalent code in the zip
documentation, as it can confusing to the newcomer. But I am also okay
with moving that 'equivalent to code' further down in the
explanation.

From report at bugs.python.org  Sun Oct 10 05:49:46 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Oct 2010 03:49:46 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <AANLkTikO4pugmpBuZR=n7NBfMn5fHWPd_d7yh4GDFXQ1@mail.gmail.com>
Message-ID: <20101010034935.GA3487@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Fri, Oct 08, 2010 at 06:25:26PM +0000, Alexander Belopolsky wrote:
> In this case, I wonder if "equivalent to" code should be added to the
> section for enumerate() and map().  Also since any() and all() have
> "equivalent to" code, I think min(), max() and sum() deserve it as
> well.

I think, you are asking for consistency in docs, right?

As a sidenote those explanations should be okay, but merging it with
the explanation of the functions may add to confusion (like the zip
example did in this case). 

Even I am +1 on removing that complex equivalent code in the zip
documentation, as it can confusing to the newcomer. But I am also okay
with moving that 'equivalent to code' further down in the
explanation.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10029>
_______________________________________

From report at bugs.python.org  Sun Oct 10 06:06:58 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 10 Oct 2010 04:06:58 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286683618.79.0.595213422294.issue10049@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Sun Oct 10 06:10:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Oct 2010 04:10:19 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1286683819.13.0.222249636896.issue10060@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There isn't much that Python can do if there is a sufficiently broken C-based module in sys.path.  All you report about the problematic module is that it is 'bad' or 'corrupt'.  Can you give more information about what makes it bad?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Sun Oct 10 06:18:24 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 10 Oct 2010 04:18:24 +0000
Subject: [issue10054] select extension does not build on platforms where
	uintptr_t is provided in inttypes.h
In-Reply-To: <1286611853.89.0.308304033443.issue10054@psf.upfronthosting.co.za>
Message-ID: <1286684304.71.0.199855292209.issue10054@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

It seems this problem was introduced by a patch in issue7211.
3.1 branch does not have this problem because that patch was not applied to release31-maint. Is this intentional?

----------
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10054>
_______________________________________

From report at bugs.python.org  Sun Oct 10 07:12:18 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 10 Oct 2010 05:12:18 +0000
Subject: [issue10008] Two links point to same place
In-Reply-To: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>
Message-ID: <1286687537.95.0.977934080685.issue10008@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

If I understand, the issue you were concerned about has been fixed. If so, please close this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10008>
_______________________________________

From report at bugs.python.org  Sun Oct 10 07:30:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Oct 2010 05:30:09 +0000
Subject: [issue10059] add the method `index` to collections.deque
In-Reply-To: <1286670227.45.0.57597987933.issue10059@psf.upfronthosting.co.za>
Message-ID: <1286688609.63.0.373131407804.issue10059@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The absence of index() from collections deque wasn't an oversight.  Deques are not really about indexed access, they are about appending and popping from the ends.  I'm curious about your use case and whether it is a good match for this data structure.

----------
assignee:  -> rhettinger
components: +Extension Modules -Library (Lib)
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10059>
_______________________________________

From report at bugs.python.org  Sun Oct 10 07:36:33 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 10 Oct 2010 05:36:33 +0000
Subject: [issue10059] add the method `index` to collections.deque
In-Reply-To: <1286670227.45.0.57597987933.issue10059@psf.upfronthosting.co.za>
Message-ID: <1286688993.83.0.746678748165.issue10059@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Hello Simon,

Accessing an arbitrary element of a deque takes O(n) time, making your .index implementation O(n**2).

If you describe the kinds of operations that you need to perform efficiently, we may be able to suggest a better data structure for you to use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10059>
_______________________________________

From report at bugs.python.org  Sun Oct 10 07:57:14 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Oct 2010 05:57:14 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286690234.07.0.896769863116.issue10029@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Max, thanks for reporting this.  I've replaced the sample code, making it work correctly and more clearly showing the logic.

See r85345 and r85346.

Daniel, we need to sync-up on the meaning of marking a report as "accepted".  Traditionally it denotes an approved patch, not a agreement that the bug is valid.

----------
resolution: accepted -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10029>
_______________________________________

From report at bugs.python.org  Sun Oct 10 07:58:20 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Oct 2010 05:58:20 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286690300.15.0.365308006237.issue10029@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/issue10029>
_______________________________________

From report at bugs.python.org  Sun Oct 10 08:18:54 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Oct 2010 06:18:54 +0000
Subject: [issue7285] multiprocessing module, example code error
In-Reply-To: <1257647520.68.0.169575152715.issue7285@psf.upfronthosting.co.za>
Message-ID: <1286691534.91.0.293248812559.issue7285@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in r85347 and r85348.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7285>
_______________________________________

From report at bugs.python.org  Sun Oct 10 08:22:21 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 10 Oct 2010 06:22:21 +0000
Subject: [issue10008] Two links point to same place
In-Reply-To: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>
Message-ID: <1286691741.42.0.860197208608.issue10008@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Yes, but http://docs.python.org/genindex-Z.html

  ZipFile (class in zipfile), [1]

still has same issue, no? [1] (and [2], [3], if exist)
should suggest alternatives, but it doesn't now.

I'll attach the patch to detect this kind of duplication.

I you say, probably this happens when same directive appears
in rst file. For example, 

.. module:: zipfile

.. class:: ZipFile

.. class:: ZipFile(file, mode='r', compression=ZIP_STORED, allowZip64=False)

Maybe I should have posted this issue to Sphinx tracker.

----------
Added file: http://bugs.python.org/file19181/search_pydoc.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10008>
_______________________________________

From report at bugs.python.org  Sun Oct 10 08:28:42 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 10 Oct 2010 06:28:42 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286692122.8.0.412844015573.issue10029@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

> Daniel, we need to sync-up on the meaning of marking a report as 
> "accepted".  Traditionally it denotes an approved patch, not a agreement > that the bug is valid.

Woops!  Thanks for the correction.  For what it's worth, a quick search of issues with Resolution: accepted and Stage: needs patch suggests that ?ric Araujo has perhaps been using the same misinterpretation as I have.  I'm not sure if I got the behavior from him, if he got it from me, or if we both arrived there independently. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10029>
_______________________________________

From report at bugs.python.org  Sun Oct 10 08:34:54 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 10 Oct 2010 06:34:54 +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: <1286692494.91.0.784373201567.issue10052@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

Forgot to mention that there's no _MAX macro for exact-width integer types.

$ egrep -r 'INT[0-9].*_MAX' /usr/include/ | wc -l
       0

How about adding those macros when the system does not provide them?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From report at bugs.python.org  Sun Oct 10 08:41:21 2010
From: report at bugs.python.org (eswar s)
Date: Sun, 10 Oct 2010 06:41:21 +0000
Subject: [issue10061] ** operator yielding wrong result for negative numbers
In-Reply-To: <1286692880.84.0.509145728664.issue10061@psf.upfronthosting.co.za>
Message-ID: <1286692880.84.0.509145728664.issue10061@psf.upfronthosting.co.za>


New submission from eswar s <eswar_js at yahoo.com>:

-5 ** 4 results as -625. It should be 625

----------
components: None
messages: 118311
nosy: eswar.s
priority: normal
severity: normal
status: open
title: ** operator yielding wrong result for negative numbers
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10061>
_______________________________________

From report at bugs.python.org  Sun Oct 10 08:44:58 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 10 Oct 2010 06:44:58 +0000
Subject: [issue10008] Two links point to same place
In-Reply-To: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>
Message-ID: <1286693098.63.0.492712690639.issue10008@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Umm, I tried, but I couldn't post new issue with error.
I believe Sphinx guys also look at this tracker.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10008>
_______________________________________

From report at bugs.python.org  Sun Oct 10 08:49:36 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Oct 2010 06:49:36 +0000
Subject: [issue10061] ** operator yielding wrong result for negative numbers
In-Reply-To: <1286692880.84.0.509145728664.issue10061@psf.upfronthosting.co.za>
Message-ID: <1286693376.04.0.564546864198.issue10061@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

It's to do with operator precedence.
** takes higher precedence than negative.

http://docs.python.org/reference/expressions.html#Summary


(-5) ** 4 will give what you are looking for.

----------
nosy: +orsenthil
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10061>
_______________________________________

From report at bugs.python.org  Sun Oct 10 08:53:47 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 10 Oct 2010 06:53:47 +0000
Subject: [issue10054] select extension does not build on platforms where
	uintptr_t is provided in inttypes.h
In-Reply-To: <1286611853.89.0.308304033443.issue10054@psf.upfronthosting.co.za>
Message-ID: <1286693627.58.0.495163948671.issue10054@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10054>
_______________________________________

From report at bugs.python.org  Sun Oct 10 09:10:25 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Oct 2010 07:10:25 +0000
Subject: [issue10029] "Equivalent to" code for zip is wrong in Python 3
In-Reply-To: <1286303206.24.0.0440700795071.issue10029@psf.upfronthosting.co.za>
Message-ID: <1286694625.26.0.220118184236.issue10029@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Please pass the word along if you get a chance :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10029>
_______________________________________

From report at bugs.python.org  Sun Oct 10 09:51:20 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 10 Oct 2010 07:51:20 +0000
Subject: [issue10062] Python 3.2 does not build on systems which do not have
	sem_timedwait
In-Reply-To: <1286697079.97.0.278086766223.issue10062@psf.upfronthosting.co.za>
Message-ID: <1286697079.97.0.278086766223.issue10062@psf.upfronthosting.co.za>


New submission from Akira Kitada <akitada at gmail.com>:

Build fails on FreeBSD 4 due to the lack of sem_timedwait.

"""
gcc -pthread   -Wl,--export-dynamic -o python Modules/python.o libpython3.2.a -lutil   -lm  
libpython3.2.a(thread.o): In function `PyThread_acquire_lock_timed':
/home/akitada/src/py3k/Python/thread_pthread.h:315: undefined reference to `sem_timedwait'
gmake: *** [python] Error 1
"""

----------
components: Build
messages: 118315
nosy: akitada
priority: normal
severity: normal
status: open
title: Python 3.2 does not build on systems which do not have sem_timedwait
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10062>
_______________________________________

From report at bugs.python.org  Sun Oct 10 10:04:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Oct 2010 08:04:18 +0000
Subject: [issue10062] Python 3.2 does not build on systems which do not have
	sem_timedwait
In-Reply-To: <1286697079.97.0.278086766223.issue10062@psf.upfronthosting.co.za>
Message-ID: <1286697858.04.0.456340678632.issue10062@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What happens if you comment out "#  define USE_SEMAPHORES" in Python/thread_pthread.h?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10062>
_______________________________________

From report at bugs.python.org  Sun Oct 10 10:12:19 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 10 Oct 2010 08:12:19 +0000
Subject: [issue10062] Python 3.2 does not build on systems which do not have
	sem_timedwait
In-Reply-To: <1286697079.97.0.278086766223.issue10062@psf.upfronthosting.co.za>
Message-ID: <1286698339.01.0.185453537478.issue10062@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

It works fine with USE_SEMAPHORES commented out.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10062>
_______________________________________

From report at bugs.python.org  Sun Oct 10 10:19:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Oct 2010 08:19:31 +0000
Subject: [issue10062] Python 3.2 does not build on systems which do not have
	sem_timedwait
In-Reply-To: <1286697079.97.0.278086766223.issue10062@psf.upfronthosting.co.za>
Message-ID: <1286698771.41.0.65612831259.issue10062@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

What about this patch?

Index: Python/thread_pthread.h
===================================================================
--- Python/thread_pthread.h	(r?vision 85348)
+++ Python/thread_pthread.h	(copie de travail)
@@ -64,7 +64,8 @@
 /* Whether or not to use semaphores directly rather than emulating them with
  * mutexes and condition variables:
  */
-#if defined(_POSIX_SEMAPHORES) && !defined(HAVE_BROKEN_POSIX_SEMAPHORES)
+#if (defined(_POSIX_SEMAPHORES) && !defined(HAVE_BROKEN_POSIX_SEMAPHORES) && \
+     defined(HAVE_SEM_TIMEDWAIT))
 #  define USE_SEMAPHORES
 #else
 #  undef USE_SEMAPHORES

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10062>
_______________________________________

From report at bugs.python.org  Sun Oct 10 10:22:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Oct 2010 08:22:16 +0000
Subject: [issue10054] select extension does not build on platforms where
	uintptr_t is provided in inttypes.h
In-Reply-To: <1286611853.89.0.308304033443.issue10054@psf.upfronthosting.co.za>
Message-ID: <1286698936.01.0.68167927562.issue10054@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> 3.1 branch does not have this problem because that patch was not
> applied to release31-maint. Is this intentional?

I don't remember, I suppose it feared it could be an incompatible change or perhaps cause build problems.

Anyway, I committed your patch in 3.2 (r85349), 2.7 (r85350) and even 3.1 (r85351). Thank you!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10054>
_______________________________________

From report at bugs.python.org  Sun Oct 10 10:27:41 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 10 Oct 2010 08:27:41 +0000
Subject: [issue10062] Python 3.2 does not build on systems which do not have
	sem_timedwait
In-Reply-To: <1286697079.97.0.278086766223.issue10062@psf.upfronthosting.co.za>
Message-ID: <1286699261.76.0.234637325629.issue10062@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

The patch does fix the build error.
Thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10062>
_______________________________________

From report at bugs.python.org  Sun Oct 10 10:37:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Oct 2010 08:37:45 +0000
Subject: [issue10062] Python 3.2 does not build on systems which do not have
	sem_timedwait
In-Reply-To: <1286697079.97.0.278086766223.issue10062@psf.upfronthosting.co.za>
Message-ID: <1286699865.39.0.708991231431.issue10062@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r85352, thanks.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10062>
_______________________________________

From report at bugs.python.org  Sun Oct 10 10:41:45 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 10 Oct 2010 08:41:45 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1286700105.68.0.334288200018.issue9921@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

That doesn't cover the os.path.join('', 'x') case, and I'm not sure it makes os.path.join('x//', 'y') clear - though that doesn't matter as much.

How about making (2) "the result is simply path2 when path1 is empty or path2 is an absolute path?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Sun Oct 10 11:30:08 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Oct 2010 09:30:08 +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: <1286703008.69.0.896207887845.issue8746@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This can be solved after 3.2a3.

----------
assignee:  -> ronaldoussoren
nosy: +georg.brandl, ronaldoussoren
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Sun Oct 10 11:32:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 10 Oct 2010 09:32:58 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1286703178.71.0.192676115517.issue8611@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Deferring once again.

----------
priority: release blocker -> deferred blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Sun Oct 10 11:33:51 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 10 Oct 2010 09:33:51 +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: <1286703231.98.0.406814710512.issue10052@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

FreeBSD 5.0 has stdint.h, which includes machine/_stdint.h. In the
latter file the *_MAX constants are defined.

It looks like FreeBSD has had the correct setup for more than 7 years:

http://svn.freebsd.org/viewvc/base/release/5.0.0/sys/i386/include/


I would be moderately against making changes in Python for dated systems.
Could you perhaps just copy the files from 5.0?

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From report at bugs.python.org  Sun Oct 10 11:37:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Oct 2010 09:37:55 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1286703475.82.0.513032015039.issue9437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed to 3.x in r85353.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Sun Oct 10 11:40:24 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 10 Oct 2010 09:40:24 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <orsenthil at gmail.com>:

file:// scheme should not be allowed to access a file on remote machines.  RFC 1738, says that host, if present should be the FQDN of the machine, but relaxing on that I thinking that localhost and its variants should okay as long as it is the local machine.

What is going to break in 3.2 is file:// trying to access resources on remote machine via FTP, which it is currently trying to do.

Attached is patch to accomplish this.(NEWS and Docs will be added).

This would introduce a regression, so this may not be backported.

----------
assignee: orsenthil
components: Library (Lib)
files: file_scheme.diff
keywords: patch
messages: 118327
nosy: orsenthil
priority: normal
severity: normal
stage: patch review
status: open
title: file:// scheme will stop accessing via ftp protocol
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19182/file_scheme.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Sun Oct 10 11:46:19 2010
From: report at bugs.python.org (kiorky)
Date: Sun, 10 Oct 2010 09:46:19 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1286703979.8.0.728096934679.issue1777412@psf.upfronthosting.co.za>


kiorky <kiorky at cryptelium.net> added the comment:

We must not have the same point of view about new features and bugfixes...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Sun Oct 10 11:55:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Oct 2010 09:55:39 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1286704539.32.0.639520152489.issue9437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Backported to 2.7 in r85358.

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Sun Oct 10 12:02:21 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 10 Oct 2010 10:02:21 +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: <1286704941.03.0.151872889528.issue10052@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

I understand FreeBSD 4.x is old platform (4.11, the last 4.x series, is released 5 years ago) but, in my opinion, as long as it does not make Python code cluttered, supporting old platforms is not that bad idea.

Anyway, I would like to leave the decision to the core developers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From report at bugs.python.org  Sun Oct 10 12:08:44 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 10 Oct 2010 10:08:44 +0000
Subject: [issue1777412] Python's strftime dislikes years before 1900
Message-ID: <1286705324.69.0.941497110185.issue1777412@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

kiorky: see my msg55157. Python behaves correctly as it stands - raising the exception is fully intentional. It's not a bug that it gets raised; dates before 1900 are just not supported. Adding support for them is a new feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777412>
_______________________________________

From report at bugs.python.org  Sun Oct 10 12:28:53 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 10 Oct 2010 10:28:53 +0000
Subject: [issue9189] Improve CFLAGS handling
In-Reply-To: <1278517873.84.0.191654592449.issue9189@psf.upfronthosting.co.za>
Message-ID: <1286706533.81.0.00736038363415.issue9189@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

r85358 fixes the failures in test_sysconfig. The duplicate LDFLAGS are
still present, but if it is generally accepted that make-LDFLAGS should
be appended to configure-LDFLAGS, then I don't see any way around that.

As for me, this could be closed again. Did Antoine's patch fix any
of the other issues mentioned here?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9189>
_______________________________________

From report at bugs.python.org  Sun Oct 10 12:57:32 2010
From: report at bugs.python.org (Simon Liedtke)
Date: Sun, 10 Oct 2010 10:57:32 +0000
Subject: [issue10059] add the method `index` to collections.deque
In-Reply-To: <1286670227.45.0.57597987933.issue10059@psf.upfronthosting.co.za>
Message-ID: <1286708252.92.0.145958923998.issue10059@psf.upfronthosting.co.za>


Simon Liedtke <liedtke.simon at googlemail.com> added the comment:

I see that adding this method to a deque is useless. A list is better for this kind of operation. I just wrote it for fun and realized that it was implemented rather slow.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10059>
_______________________________________

From report at bugs.python.org  Sun Oct 10 16:55:59 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 10 Oct 2010 14:55:59 +0000
Subject: [issue10064] link to page with documentation bugs
In-Reply-To: <1286722559.84.0.874686130461.issue10064@psf.upfronthosting.co.za>
Message-ID: <1286722559.84.0.874686130461.issue10064@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Link to bugtracker on http://docs.python.org/dev/bugs.html leads to main roundup page. It make more sense to redirect to a page that lists only documentation bugs.

Extra points:
- sort the landing page that Easy, then issues with Patches come first
- provide a link to Documentation HOWTO from an issue page

----------
assignee: docs at python
components: Documentation
messages: 118334
nosy: docs at python, techtonik
priority: normal
severity: normal
status: open
title: link to page with documentation bugs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10064>
_______________________________________

From report at bugs.python.org  Sun Oct 10 17:49:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 10 Oct 2010 15:49:41 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286725781.22.0.398775772043.issue10063@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Does it also need a deprecation cycle?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Sun Oct 10 17:51:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Oct 2010 15:51:28 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286725888.95.0.846762557387.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> We run into problems because we have two inconsistent
> encodings, ...

What? No. We have problems because we don't use the same encoding to decode and to encode the same data type. It's not a problem to use a different encoding for each data type (stdout, filenames, environment variables, ...).

--

About the 3rd encoding: it will be just the locale encoding. Use the locale encoding to encode/decode command line arguments and environment variables is complelty compatible with Python 3.1, because Python 3.1 initializes the filesystem encoding with the locale encoding. Use the locale encoding helps the interoperability because other programs use the same encoding.

Mac OS X is a special case. Filesystem encoding is utf-8 on this OS, whereas the locale encoding depends on LANG variable. If I understood MvL proposition correctly, we should not rely on the locale on Mac OS X. So the "3rd encoding" and the filesystem encodings should be hardcoded to utf-8?

--

The "third encoding" is no more controlable by a special environment variable, only by classic locale environment variables (LC_ALL, LC_CTYPE, LANG). Is it a problem? I remember a comment from MAL saying that it may be a problem for CGI for the environment variables because some (all?) variables are not encoded with the locale encoding (but the HTML encoding?). I don't know if Python should workaround CGI specific issues. In Python 3.2, we have now os.environb: it's now possible to use a different encoding for each variable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sun Oct 10 18:22:28 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 10 Oct 2010 16:22:28 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <1286725888.95.0.846762557387.issue9992@psf.upfronthosting.co.za>
Message-ID: <4CB1E83E.9050003@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 10.10.2010 17:51, schrieb STINNER Victor:
> 
> STINNER Victor <victor.stinner at haypocalc.com> added the comment:
> 
>> We run into problems because we have two inconsistent encodings,
>> ...
> 
> What? No. We have problems because we don't use the same encoding to
> decode and to encode the same data type. It's not a problem to use a
> different encoding for each data type (stdout, filenames, environment
> variables, ...).

This is exactly the very problem that we face. In particular, the
question is what encoding to use if something is *both* a filename
and an environment variable value, or both a filename and a command
line argument.

> Mac OS X is a special case. Filesystem encoding is utf-8 on this OS,
> whereas the locale encoding depends on LANG variable. If I understood
> MvL proposition correctly, we should not rely on the locale on Mac OS
> X.

"Not rely on" is perhaps a bit harsh. It's not clear (to me) under what
conditions the locale's encoding will be more correct than just assuming
UTF-8 - there may actually be use cases for it.

However, with the surrogate escapes, we could just always decode using
UTF-8, and leave any mojibake problems that may arise from this from
this to the application. I do think that these problems will be rare,
since a) many OSX installations use UTF-8, anyway, and b) those that
don't likely experience the proper round-tripping of the escape mechanism.

> So the "3rd encoding" and the filesystem encodings should be
> hardcoded to utf-8?

That's an option to consider, yes - I'd like an OSX expert to
comment.

> The "third encoding" is no more controlable by a special environment
> variable, only by classic locale environment variables (LC_ALL,
> LC_CTYPE, LANG). Is it a problem? I remember a comment from MAL
> saying that it may be a problem for CGI for the environment variables
> because some (all?) variables are not encoded with the locale
> encoding (but the HTML encoding?). I don't know if Python should
> workaround CGI specific issues. In Python 3.2, we have now
> os.environb: it's now possible to use a different encoding for each
> variable.

I think these problems are sufficiently resolved now: either by
PEP 3333, PEP 444, PEP 383, or os.environb.

I think you misunderstood MAL's comment, though: the environment
variables are not encoded in *any* specific encoding. Instead,
they are copied literally from the HTTP request, using whatever
bytes the browser originally put in there - which may or may
not have followed a particular encoding. HTTP is silent on
this most of the time, and HTML is out of scope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sun Oct 10 18:42:44 2010
From: report at bugs.python.org (MunSic JEONG)
Date: Sun, 10 Oct 2010 16:42:44 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1286728964.37.0.506036157994.issue7980@psf.upfronthosting.co.za>


MunSic JEONG <ruseel at gmail.com> added the comment:

> Do you have a patch to fix the issue?
no, I don't. I just wanted to move stage from "unittest needed" to "needs patch" :)

After reading issue8098, now I realized that this is broad issue as belopolsky said in msg110095. 


For new reader of this issue after me, I would like to share my understanding.

Patch like below can solve this ticket. (changing "ImportModuleNoBlock" call to "ImportNoBlock")

 static PyObject *
 time_strptime(PyObject *self, PyObject *args)
 {
-    PyObject *strptime_module = PyImport_ImportModuleNoBlock("_strptime");
+    PyObject *strptime_module = PyImport_ImportModule("_strptime");


But "the function PyImport_ImportModuleNoBlock() was introduced and used in modules such as the time module to supposedly avoid deadlocks when using threads." 

So we could not apply that patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Sun Oct 10 19:59:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 10 Oct 2010 17:59:25 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <4CB1E83E.9050003@v.loewis.de>
Message-ID: <201010101959.15671.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > What? No. We have problems because we don't use the same encoding to
> > decode and to encode the same data type. It's not a problem to use a
> > different encoding for each data type (stdout, filenames, environment
> > variables, ...).
> 
> This is exactly the very problem that we face. In particular, the
> question is what encoding to use if something is *both* a filename
> and an environment variable value, or both a filename and a command
> line argument.

The question is: what is the best default encoding for a specific data type? 
There is no perfect answer (well, except maybe using byte strings :-)). Each 
solution has its own use cases and disadvantages.

If an application knows exactly the encoding of a data, and it is not the 
default encoding, it can still redecode the data. Using os.environb, it's a 
little bit better: the application just has to decode (don't have to encode 
and to know which encoding was used to decode initially the data). For 
sys.argv, I still want to create sys.argvb (bytes version) ;-)

For the command line arguments and environment variables, we don't have a lot 
of choices: locale or filesystem encodings. So Antoine and Martin: which 
encoding do you prefer? We should maybe try to find some use cases

Here is a dummy script bla.py:
---
import sys
print(sys.argv)
try:
    open(sys.argv[1]).close()
except Exception as err:
    print("open error: %s" % err)
else:
    print("open ok")
---

Locale encoding = FS encoding = utf-8:

$ ./python bla.py xxx?.txt 
['bla.py', 'xxx?.txt']
open ok

Locale encoding = utf8, FS encoding = ascii:

$ PYTHONFSENCODING=ascii ./python bla.py xxx?.txt 
['bla.py', 'xxx?.txt']
open error: 'ascii' codec can't encode character '\xe9' ...

The filename is displayed correctly, but we are unable to open the file if 
PYTHONFSENCODING is used :-/ Should the filename be displayed differently if 
PYTHONFSENCODING is used?

> I think these problems are sufficiently resolved now: either by
> PEP 3333, PEP 444, PEP 383, or os.environb.

Ok, cool :-)

> I think you misunderstood MAL's comment, though: the environment
> variables are not encoded in *any* specific encoding. Instead,
> they are copied literally from the HTTP request, using whatever
> bytes the browser originally put in there - which may or may
> not have followed a particular encoding. HTTP is silent on
> this most of the time, and HTML is out of scope.

Ah yes, thanks for you explaination. I was unable to find its comment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sun Oct 10 20:23:36 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 10 Oct 2010 18:23:36 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <201010101959.15671.victor.stinner@haypocalc.com>
Message-ID: <4CB20496.9070108@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> For the command line arguments and environment variables, we don't have a lot 
> of choices: locale or filesystem encodings. So Antoine and Martin: which 
> encoding do you prefer?

I still propose to drop the fsname encoding. Then this question goes away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sun Oct 10 20:33:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 10 Oct 2010 18:33:15 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <4CB20496.9070108@v.loewis.de>
Message-ID: <1286735589.3155.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le dimanche 10 octobre 2010 ? 18:23 +0000, Martin v. L?wis a ?crit :
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> > For the command line arguments and environment variables, we don't have a lot 
> > of choices: locale or filesystem encodings. So Antoine and Martin: which 
> > encoding do you prefer?
> 
> I still propose to drop the fsname encoding. Then this question goes away.

I don't know what you mean by dropping, since OS X by construction needs
a filesystem encoding (utf-8) different from the locale encoding; and
Windows hardwires the decoding/encoding of bytes filenames using mbcs
regardless of the current codepage, IIRC.

So do you just mean the filesystem encoding should be hidden from the
user? What would be the benefit?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sun Oct 10 21:23:43 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Oct 2010 19:23:43 +0000
Subject: [issue10061] ** operator yielding wrong result for negative numbers
In-Reply-To: <1286692880.84.0.509145728664.issue10061@psf.upfronthosting.co.za>
Message-ID: <1286738623.18.0.999354158633.issue10061@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Python's order of operations runs the exponentation before the unary minus.  This convention makes the unary minus behave more like the subtraction operator so that:  -x**n == 0 - x**n.

This convention is somewhat common but there are exceptions such as MS Excel where the unary minus binds first.  See http://en.wikipedia.org/wiki/Order_of_operations#Examples

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10061>
_______________________________________

From report at bugs.python.org  Sun Oct 10 21:31:48 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sun, 10 Oct 2010 19:31:48 +0000
Subject: [issue10065] future_builtins' docstring lacks some functions
In-Reply-To: <1286739108.25.0.226461556953.issue10065@psf.upfronthosting.co.za>
Message-ID: <1286739108.25.0.226461556953.issue10065@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

Title says all, attached is a patch against release27-maint that adds them.

----------
assignee: docs at python
components: Documentation
files: future_builtins_docstring.patch
keywords: patch
messages: 118343
nosy: Trundle, docs at python
priority: normal
severity: normal
status: open
title: future_builtins' docstring lacks some functions
versions: Python 2.7
Added file: http://bugs.python.org/file19183/future_builtins_docstring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10065>
_______________________________________

From report at bugs.python.org  Sun Oct 10 21:44:22 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 10 Oct 2010 19:44:22 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <1286735589.3155.4.camel@localhost.localdomain>
Message-ID: <4CB21793.4010209@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't know what you mean by dropping, since OS X by construction needs
> a filesystem encoding (utf-8) different from the locale encoding;

See above. I propose to stop using the locale encoding for command line
arguments and environment variables on OSX, and use UTF-8 instead.

> and
> Windows hardwires the decoding/encoding of bytes filenames using mbcs
> regardless of the current codepage, IIRC.

I wish byte-oriented file names could be dropped on Windows. But that
is probably too incompatible.

> So do you just mean the filesystem encoding should be hidden from the
> user? What would be the benefit?

That the very issue that this bug report (re-read the title) is about
would go away.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Sun Oct 10 21:55:19 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 10 Oct 2010 19:55:19 +0000
Subject: [issue10008] Two links point to same place
In-Reply-To: <1285958709.04.0.778307485723.issue10008@psf.upfronthosting.co.za>
Message-ID: <1286740519.53.0.509694486664.issue10008@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

When I initially wrote "I have no idea what ', [1]' is supposed to mean.
", you should have believed that and explained ;-). I now understand that most index entries have one link, which we might call the [0] link. When the entry should have more than one link, the index entry text is followed by '[1]' and, if needed, '[2]', '[3]', and so on. These place-holder labels should each have different links, or should not be there at all.

So "ZipFile (class in zipfile" and "[1]" are two separate texts that should have two different links, but the two links are the same, and that, I agree, is wrong. Another example with duplicate links:
  tracer() (in module turtle), [1]

3.1.2 and 3.2a2 indexes have Zipfile error but not tracer error (because '[1]' is not present).

Doc people: the attached patch is a diagnostic patch rather than a fixup patch. I do not know whether the problem is in .rst sources or Sphinx.

----------
assignee: docs at python -> 
keywords: +patch
nosy: +georg.brandl
stage:  -> needs patch
type:  -> behavior
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10008>
_______________________________________

From report at bugs.python.org  Sun Oct 10 23:09:06 2010
From: report at bugs.python.org (Vinay Sajip)
Date: Sun, 10 Oct 2010 21:09:06 +0000
Subject: [issue9948] findCaller is slow and loses case information on Windows
In-Reply-To: <1285425150.17.0.662006958911.issue9948@psf.upfronthosting.co.za>
Message-ID: <1286744946.36.0.300768088032.issue9948@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Partial fix checked into py3k and release27-maint branches (for losing filename case information) - r85361.

Regarding performance changes - awaiting feedback from Armin re. my performance measurements showing only marginal differences.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9948>
_______________________________________

From report at bugs.python.org  Sun Oct 10 23:50:47 2010
From: report at bugs.python.org (Matthew Woodcraft)
Date: Sun, 10 Oct 2010 21:50:47 +0000
Subject: [issue4106] multiprocessing occasionally spits out exception during
	shutdown
In-Reply-To: <1223695822.85.0.145044917765.issue4106@psf.upfronthosting.co.za>
Message-ID: <1286747447.94.0.243431597864.issue4106@psf.upfronthosting.co.za>


Changes by Matthew Woodcraft <matthew at woodcraft.me.uk>:


----------
nosy: +mattheww

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4106>
_______________________________________

From report at bugs.python.org  Mon Oct 11 08:32:26 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 11 Oct 2010 06:32:26 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286725781.22.0.398775772043.issue10063@psf.upfronthosting.co.za>
Message-ID: <20101011063213.GB6783@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Sun, Oct 10, 2010 at 03:49:42PM +0000, R. David Murray wrote:
> Does it also need a deprecation cycle?

I think, adding a deprecation cycle might just delay this change.
So, I would prefer if we make it in the 3.2 itself.

- This is not a user-facing API change and I did not see any
  references where people relied upon this behavior. (No bugs / usage
  cases)
- It is actually a bug, because one may not be sure if the ftp service
  is running the machine in the first place and user may not intend
  that ftp service be used for accessing local resources.

We had python-dev discussion on this sometime back when fixing another
bug and conclusion was that we raise a ValueError when file:// scheme
was used in non-local url. Instead of ValueError, I think the generic
URLError is okay too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Mon Oct 11 12:07:41 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 11 Oct 2010 10:07:41 +0000
Subject: [issue9055] test_issue_8959_b fails when run from a service
In-Reply-To: <1277159969.39.0.181729867437.issue9055@psf.upfronthosting.co.za>
Message-ID: <1286791661.81.0.977211875847.issue9055@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Hello. I've been finding the way to determine whether
the process is running as service or not. Does this way
work? On my environment, True is returned. I hope False
will be returned in service environment.

http://msdn.microsoft.com/en-us/library/d56de412%28v=VS.80%29.aspx
http://msdn.microsoft.com/en-us/library/ms683225%28VS.85%29.aspx

/////////////////////////////////////////

from __future__ import print_function
import ctypes
from ctypes.wintypes import *

UOI_FLAGS = 1
WSF_VISIBLE = 0x0001

class USEROBJECTFLAGS(ctypes.Structure):
    _fields_ = [("fInherit", BOOL),
                ("fReserved", BOOL),
                ("dwFlags", DWORD)]

def window_station_has_display_surfaces():
    dll = ctypes.windll.user32
    h = dll.GetProcessWindowStation()
    if not h:
        raise ctypes.WinError()
    uof = USEROBJECTFLAGS()
    needed = DWORD()
    res = dll.GetUserObjectInformationW(h,
        UOI_FLAGS, 
        ctypes.byref(uof),
        ctypes.sizeof(uof),
        ctypes.byref(needed))
    if not res:
        raise ctypes.WinError()
    return bool(uof.dwFlags & WSF_VISIBLE)

def main():
    print(window_station_has_display_surfaces())

if __name__ == '__main__':
    main()

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9055>
_______________________________________

From report at bugs.python.org  Mon Oct 11 12:10:39 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 11 Oct 2010 10:10:39 +0000
Subject: [issue9055] test_issue_8959_b fails when run from a service
In-Reply-To: <1277159969.39.0.181729867437.issue9055@psf.upfronthosting.co.za>
Message-ID: <1286791839.26.0.594417589948.issue9055@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Oh, I forgot to mention this. I think it can be possible
to disable "gui" resource on regrtest.py when this function
returns False. (I hope #9931 also can be fixed by this)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9055>
_______________________________________

From report at bugs.python.org  Mon Oct 11 12:12:28 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 11 Oct 2010 10:12:28 +0000
Subject: [issue9055] test_issue_8959_b fails when run from a service
In-Reply-To: <1277159969.39.0.181729867437.issue9055@psf.upfronthosting.co.za>
Message-ID: <1286791948.33.0.988034390562.issue9055@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I'm planning to try it on buildbot XP-5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9055>
_______________________________________

From report at bugs.python.org  Mon Oct 11 12:49:01 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 11 Oct 2010 10:49:01 +0000
Subject: [issue9931] test_ttk_guionly hangs on XP5
In-Reply-To: <1285273632.39.0.298869124825.issue9931@psf.upfronthosting.co.za>
Message-ID: <1286794141.02.0.791684375135.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  Mon Oct 11 12:52:56 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 11 Oct 2010 10:52:56 +0000
Subject: [issue9055] test_issue_8959_b fails when run from a service
In-Reply-To: <1277159969.39.0.181729867437.issue9055@psf.upfronthosting.co.za>
Message-ID: <1286794376.53.0.840350987163.issue9055@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I confirmed window_station_has_display_surfaces() returned False
on XP-5 which is running as service.

See
http://www.python.org/dev/buildbot/builders/x86%20XP-5%203.x/builds/1453/steps/test/logs/stdio
(It ran r85362)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9055>
_______________________________________

From report at bugs.python.org  Mon Oct 11 14:15:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2010 12:15:22 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <4CB20496.9070108@v.loewis.de>
Message-ID: <201010111415.12700.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> > ... So Antoine and Martin: which encoding do you prefer?
> 
> I still propose to drop the fsname encoding. Then this question goes away.

You mean that we should use the following encoding for the command line 
arguments, environment variables and all filenames/paths:
 - Mac OS X: utf-8
 - Windows: unicode for command line/env, mbcs to decode filenames
 - others OSes: locale encoding

To do that, we have to:
 - "others OSes": delete the PYTHONFSENCODING variable
 - Mac OS X: use utf-8 to decode the command line arguments (we can use 
PyUnicode_DecodeUTF8()+PyUnicode_AsWideCharString() before Python is 
initialized)

On "others OSes", we continue to use the FS encoding to encode command 
line/env vars, because the FS encoding will always be the locale encoding. And 
it's more pratical to use sys.getfilesystemencoding() than mbstowcs(), 
wcstombs(), _Py_wchar2char(), _Py_char2wchar(), etc. because the FS encoding 
doesn't depend on the current locale, and it uses Python codecs which support 
more error handlers.

I like this solution because it doesn't change a lot of things. I agree to 
drop PYTHONFSENCODING because it looks like PYTHONFSENCODING introduced more 
inconsistencies than it solved.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 14:48:09 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 11 Oct 2010 12:48:09 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286801289.92.0.056131765746.issue10045@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/issue10045>
_______________________________________

From report at bugs.python.org  Mon Oct 11 14:53:06 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 11 Oct 2010 12:53:06 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286801586.36.0.511942424588.issue10045@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Causing perfectly good Python 2 applications to degrade in performance is bad, even if something else is available.

This should be fixed as a regression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Mon Oct 11 14:57:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Oct 2010 12:57:25 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286801845.53.0.476352774778.issue10045@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This should be fixed as a regression.

As far as I understand, this is not a regression. I don't think the cStringIO code has changed in years.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Mon Oct 11 15:01:17 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 11 Oct 2010 13:01:17 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286802077.53.0.667429291605.issue10045@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Ok, reading more carefully, it's not a regression.  But it's certainly a bug, and should be fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Mon Oct 11 15:04:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Oct 2010 13:04:22 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286802077.53.0.667429291605.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286802254.3148.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Ok, reading more carefully, it's not a regression.  But it's certainly
> a bug, and should be fixed.

Right. The patch looks straightforward, but I'm not familiar with the
cStringIO code. Could you take a look?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Mon Oct 11 15:06:13 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 11 Oct 2010 13:06:13 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286802373.59.0.214304241703.issue10045@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Assigning to myself for review.

----------
assignee:  -> fdrake
keywords: +needs review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Mon Oct 11 15:45:45 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 11 Oct 2010 13:45:45 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <201010111415.12700.victor.stinner@haypocalc.com>
Message-ID: <4CB31502.2060606@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

STINNER Victor wrote:
> 
> I like this solution because it doesn't change a lot of things. I agree to 
> drop PYTHONFSENCODING because it looks like PYTHONFSENCODING introduced more 
> inconsistencies than it solved.

If you remove the PYTHONFSENCODING, then we have to reconsider
removal of sys.setfilesystemencoding().

The main argument for removal of the sys function was having
the environment variable.

If you remove both, Python will get very poor grades for OS
interoperability on platforms that often deal with multiple
different encodings for file names.

I am repeating myself, but please keep in mind that the locale
is an application scope setting. It doesn't have anything
to do with what's actually stored in file systems or what the
OS uses internally.

Python therefore has to provide a way to customize the file system
encoding and allow to override the locale guessing that's currently
happening.

You can't just tell people to go with whatever encoding setup
you prefer to make Python's guessing easier or more correct. Python
has to adapt to what the users actually use, not the other way
around. Where that's not easily possible, there have to be ways
to explicitly tell Python what to use... telling the user to adjust
his or her locale settings just to be able to run Python is not
an option.

The world is still moving towards Unicode - it's not 100% there
yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 15:54:37 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 11 Oct 2010 13:54:37 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <201010111415.12700.victor.stinner@haypocalc.com>
Message-ID: <4CB31719.8000403@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> You mean that we should use the following encoding for the command line 
> arguments, environment variables and all filenames/paths:
>  - Mac OS X: utf-8
>  - Windows: unicode for command line/env, mbcs to decode filenames

No: unicode for filenames also.

>  - others OSes: locale encoding

Yes, that is my proposal.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 15:56:29 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 11 Oct 2010 13:56:29 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <4CB31502.2060606@egenix.com>
Message-ID: <4CB3178A.30107@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> If you remove both, Python will get very poor grades for OS
> interoperability on platforms that often deal with multiple
> different encodings for file names.

Why that? It will work very well in such a setting, much better
than, say, Java.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 16:17:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Oct 2010 14:17:26 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286806646.52.0.607652662304.issue10063@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If it's been reviewed on python-dev and the consensus was to turn it into an error in 3.2, then I'm fine with it.  But I'll bet we'll get at least a few bug reports :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Mon Oct 11 16:23:50 2010
From: report at bugs.python.org (Dev Player)
Date: Mon, 11 Oct 2010 14:23:50 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1286807030.82.0.135549195268.issue10060@psf.upfronthosting.co.za>


Dev Player <devplayer at gmail.com> added the comment:

I believe that a 3rd party package is corrupt. Whether it is or not I don't know. However whether or not a package is corrupt or not is not what I am reporting as a bug.

I am reporting that python.exe crashes when I do help() modules.


In GUI wrappers around python.exe, such as idle and pycrust, I get more information to the problem then when just in python.exe command line interpreter. As per the first post the errors I get in pycrust and idle are:
...
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\framework\app.py", line 367, in Win32RawInput
    ret=dialog.GetSimpleInput(prompt)
  File "Q:\Python27\Lib\site-packages\pythonwin\pywin\mfc\dialog.py", line 223, in GetSimpleInput
    if title is None: title=win32ui.GetMainFrame().GetWindowText()
error: The frame does not exist

To be honest the meaning of these errors is beyond my expertise, or lack of thereof. I attempted to give as much info on what I experienced with running python.exe help() modules as I saw.

If there is a direction you can point me to that I can gather more information then what I've already given, I'll give that a go as well.

Other pointers to reported problems of a similar nature:
http://mail.python.org/pipermail/pythonmac-sig/2008-November/020712.html
https://bugs.launchpad.net/ubuntu/+source/python2.5/+bug/137210

Again this is not a report of a corrupt package. 

It is a report of python.exe crashing using commands considered part of Python.exe; that being help() then modules.

An external library may be the cause or may not. But if it is an external library that is corrupt I would hope python.exe would not fail because of it, but instead just either ignore the package or report an error. Another reason why I think python.exe shouldn't crash because of external library integrity is what if there is a file or some such thing in one's Python path that looks like and smells like a Python module/package but isn't? Should python.exe fail because of such a file?

I do not know the structure of a Python package or whether pythonwin on my PC is corrupt. However I imaging that if a fake package can be made so that IT is corrupt (perhaps make a missing file) that testing would be relatively easy.

Sorry I don't have more information for you. But hearing from others who have tried their python.exe help() modules works or fails would be a start.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Mon Oct 11 16:27:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Oct 2010 14:27:42 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1286807262.05.0.461301964948.issue9437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There are now failures on the FreeBSD 7.2 buildbot:

======================================================================
ERROR: test_build_ext (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/unixccompiler.py", line 254, in link
    self.spawn(linker + ld_args)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/spawn.py", line 138, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'gcc' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/tests/test_build_ext.py", line 65, in test_build_ext
    cmd.run()
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py", line 347, in run
    self.build_extensions()
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py", line 456, in build_extensions
    self.build_extension(ext)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py", line 543, in build_extension
    target_lang=language)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/ccompiler.py", line 719, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/unixccompiler.py", line 256, in link
    raise LinkError(msg)
distutils.errors.LinkError: command 'gcc' failed with exit status 1

======================================================================
ERROR: test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/unixccompiler.py", line 254, in link
    self.spawn(linker + ld_args)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/spawn.py", line 138, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'gcc' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/tests/test_build_ext.py", line 321, in test_get_outputs
    cmd.run()
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py", line 347, in run
    self.build_extensions()
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py", line 456, in build_extensions
    self.build_extension(ext)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/command/build_ext.py", line 543, in build_extension
    target_lang=language)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/ccompiler.py", line 719, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/distutils/unixccompiler.py", line 256, in link
    raise LinkError(msg)
distutils.errors.LinkError: command 'gcc' failed with exit status 1


Of course since distutils doesn't tell us what the gcc error message is, it's hard to do anything.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Mon Oct 11 16:31:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Oct 2010 14:31:11 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1286807471.69.0.824301666417.issue9437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently, the error message is:

gcc: ${LDFLAGS}: No such file or directory

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Mon Oct 11 16:32:34 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Mon, 11 Oct 2010 14:32:34 +0000
Subject: [issue9992] Command line arguments are not correctly
	decodediflocale	and fileystem encodingsaredifferent
In-Reply-To: <1286626022.3177.12.camel@localhost.localdomain>
Message-ID: <70b6a53c-7aee-c2c0-b567-b3fd31ca1052@me.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 09 Oct, 2010,at 02:07 PM, Antoine Pitrou <report at bugs.python.org> wrote:

Antoine Pitrou <pitrou at free.fr> added the comment:

> For the command line, it would mean that we 
> introduced a new encoding: "command line encoding", which will be utf-8 on 
> OSX.

Or more generally "environment encoding", if it's also used for env
vars. This could solve the subprocess issue neatly.
??

Note that the command-line and environment encoding on OSX is generally UTF-8, even if that is not always reflected in the locale settings.

On recent OSX releases LANG will be set to a UTF-8 aware locale ("en_US.UTF-8" on my machine) when you start a shell using Terminal.app.

The correct locale environment variables are AFAIK not set in two important situations: on OSX 10.4 and when running code from an application bundle, in both cases the environment/command-line encoding should be treated as UTF-8.

There is one reason for not wanting to assume that the encoding is always UTF-8: the user might access the system from a non-UTF8 terminal (such as when logging in with an SSH session from a system not using UTF-8, or using an alternate terminal application). IMHO these are minor enough use-cases that we could just enforce that the encoding is UTF-8 on OSX.??

That would ensure that the filesystem encoding and environment/command-line encoding are consistent and we'd no longer run into the problem that triggered this issue.

Ronald

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

----------
title: Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent -> Command line arguments are not correctly decodediflocale	and fileystem encodingsaredifferent
Added file: http://bugs.python.org/file19184/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________
-------------- next part --------------
<html><body><div><br><br>On 09 Oct, 2010,at 02:07 PM, Antoine Pitrou &lt;report at bugs.python.org&gt; wrote:<br><br></div><div><blockquote type="cite"><div><div class="_stretch"><br>
Antoine Pitrou &lt;pitrou at free.fr&gt; added the comment:<br>
<br>
&gt; For the command line, it would mean that we <br>
&gt; introduced a new encoding: "command line encoding", which will be utf-8 on <br>
&gt; OSX.<br>
<br>
Or more generally "environment encoding", if it's also used for env<br>
vars. This could solve the subprocess issue neatly.</div></div></blockquote><span>&nbsp;</span></div><div><br></div><div><span></span>Note that the command-line and environment encoding on OSX is generally UTF-8, even if that is not always reflected in the locale settings.</div><div><br></div><div>On recent OSX releases LANG will be set to a UTF-8 aware locale ("en_US.UTF-8" on my machine) when you start a shell using Terminal.app.</div><div><br></div><div>The correct locale environment variables are AFAIK not set in two important situations: on OSX 10.4 and when running code from an application bundle, in both cases the environment/command-line encoding should be treated as UTF-8.</div><div><br></div><div>There is one reason for not wanting to assume that the encoding is always UTF-8: the user might access the system from a non-UTF8 terminal (such as when logging in with an SSH session from a system not using UTF-8, or using an alternate terminal application). IMHO these are
  minor enough use-cases that we could just enforce that the encoding is UTF-8 on OSX.&nbsp;</div><div><br></div><div>That would ensure that the filesystem encoding and environment/command-line encoding are consistent and we'd no longer run into the problem that triggered this issue.</div><div><br></div><div>Ronald</div><div><blockquote type="cite"><div><div class="_stretch"><br>
<br>
----------<br>
<br>
_______________________________________<br>
Python tracker &lt;report at bugs.python.org&gt;<br>
&lt;<a href="http://bugs.python.org/issue9992" _mce_href="http://bugs.pythonorg/issue9992">http://bugs.python.org/issue9992</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div></body></html>

From report at bugs.python.org  Mon Oct 11 16:34:49 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 11 Oct 2010 14:34:49 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1286807689.92.0.604390342272.issue9437@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Notice that the error shows further up in the output, at the point where the test was actually run:

gcc: ${LDFLAGS}: No such file or directory

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Mon Oct 11 16:38:40 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 11 Oct 2010 14:38:40 +0000
Subject: [issue9992] Command line arguments are not correctly	decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <70b6a53c-7aee-c2c0-b567-b3fd31ca1052@me.com>
Message-ID: <4CB3216D.4020804@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> There is one reason for not wanting to assume that the encoding is
> always UTF-8: the user might access the system from a non-UTF8
> terminal (such as when logging in with an SSH session from a system
> not using UTF-8, or using an alternate terminal application). IMHO
> these are minor enough use-cases that we could just enforce that the
> encoding is UTF-8 on OSX.

Ok, that's enough of an expert statement for me to settle the OSX
case: we will always assume that environment data is UTF-8 on OSX
(leaving the rest to the surrogate escape handler).

----------
title: Command line arguments are not correctly decodediflocale	and fileystem encodingsaredifferent -> Command line arguments are not correctly	decodediflocale and fileystem encodingsaredifferent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 16:41:32 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 11 Oct 2010 14:41:32 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <4CB3178A.30107@v.loewis.de>
Message-ID: <4CB32217.5010609@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:
> 
>> If you remove both, Python will get very poor grades for OS
>> interoperability on platforms that often deal with multiple
>> different encodings for file names.
> 
> Why that? It will work very well in such a setting, much better
> than, say, Java.

Well, Java pretty much fails completely in this respect, so being
better than Java is not exactly the benchmark I had in mind :-)

I think the proper benchmark would be a Python2 application that
has no problems with these things, since file names are just
bytes that refer to files on the disk, with no associated encoding -
at least on Unix and related platforms.

Being pedantic about forcing some encoding onto things that don't
have an encoding won't really work out in practice. Dealing with
file names, OS environments, pipes and sockets is dirty work, so
I think we should go with the 80-20 approach in making 80% easy
and 20% harder, but still possible.

----------
title: Command line arguments are not correctly	decodediflocale and fileystem encodingsaredifferent -> Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 17:34:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Oct 2010 15:34:47 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1286811287.76.0.200161520558.issue9437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The cause for the failure seems to be a bug in the dreaded _parse_makefile(). When you give it a Makefile such as:

LDFLAGS=-foo
PY_LDFLAGS=-bar
LDSHARED=$(CC) -shared ${LDFLAGS} $(PY_LDFLAGS)

It outputs the following variables:

{'CC': '',
 'LDFLAGS': '-foo',
 'LDSHARED': '-shared ${LDFLAGS} -bar',
 'PY_LDFLAGS': '-bar'}

That is, ${LDFLAGS} isn't expanded.

However, since the Makefile now explicitly appends PY_LDFLAGS to LDSHARED, we could also stop doing so in ./configure.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Mon Oct 11 17:36:35 2010
From: report at bugs.python.org (Rafe H. Kettler)
Date: Mon, 11 Oct 2010 15:36:35 +0000
Subject: [issue4758] Python 3.x internet documentation needs work
In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>
Message-ID: <1286811395.2.0.37939241937.issue4758@psf.upfronthosting.co.za>


Rafe H. Kettler <rafe.kettler at gmail.com> added the comment:

I stumbled upon this issue and I feel similarly about the documentation for a particular module, ftplib. I think that the documentation is a bit too concise and assumes that the reader in an expert in the protocol when the point of the module is to abstract out such details.

For example, for the error documentation, the exceptions are only explained by the error code the server can return to trigger them. So, while the explanation of error_perm, for example, should say something about permissions, it just says "raised when an error code in the range 500?599 is received." This is particularly unclear for those with no knowledge of the internals of the protocol.

Also, in the documentation for RetrLines(), the documentation mentions the options LIST, NLST, and MLSD without explaining what they are. I know that when I first started using ftplib I had to experiment with each option to determine what they do, and I think it would be better if this was clear in the docs from the start.

I can propose a patch to the documentation if needed.

----------
nosy: +Rafe.H..Kettler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4758>
_______________________________________

From report at bugs.python.org  Mon Oct 11 17:49:05 2010
From: report at bugs.python.org (Rafe H. Kettler)
Date: Mon, 11 Oct 2010 15:49:05 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1286812145.54.0.592904954887.issue9921@psf.upfronthosting.co.za>


Rafe H. Kettler <rafe.kettler at gmail.com> added the comment:

I think Brian's second solution ("the result is simply path2 when path1 is empty or path2 is an absolute path?") is a strong one. If that were tacked on towards the end it would add some clarity to the docs for people who will end up using this behavior or want a more in-depth explanation. At the same time, I think putting it towards the end (as more of a side note, like the bit about behavior on Windows with drive names) lets less sophisticated users (like me) ignore that piece of documentation.

----------
nosy: +Rafe.H..Kettler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Mon Oct 11 17:58:07 2010
From: report at bugs.python.org (Radu Grigore)
Date: Mon, 11 Oct 2010 15:58:07 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1286812687.1.0.477203999734.issue9921@psf.upfronthosting.co.za>


Radu Grigore <radugrigore at gmail.com> added the comment:

posixpath.py's comment says

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Mon Oct 11 18:01:04 2010
From: report at bugs.python.org (Radu Grigore)
Date: Mon, 11 Oct 2010 16:01:04 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1286812864.97.0.116057405068.issue9921@psf.upfronthosting.co.za>


Radu Grigore <radugrigore at gmail.com> added the comment:

Realizing I still don't know what os.join.path does, I looked at the source. The comment in posixpath.py is:

# Ignore the previous parts if a part is absolute.
# Insert a '/' unless the first part is empty or already ends in '/'.

I find this clear and it directly corresponds to the implementation.

On the other hand, the source of ntpath.join() is a nightmare, and there's no similarly simple comment there.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Mon Oct 11 18:01:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 11 Oct 2010 16:01:59 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <4CB32217.5010609@egenix.com>
Message-ID: <4CB334F4.1070106@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Being pedantic about forcing some encoding onto things that don't
> have an encoding won't really work out in practice. Dealing with
> file names, OS environments, pipes and sockets is dirty work, so
> I think we should go with the 80-20 approach in making 80% easy
> and 20% harder, but still possible.

Unix applications can always use the byte-oriented file name APIs
if they need to. Then you are back to the state that things have
in Python 2. No need to have a user-tunable file system encoding
there.

However, I completely fail to see the advantage that the
PYTHONFSENCODING variable has over the LANG variable. If it's
possible to set PTHONFSENCODING in some application, it surely
is also possible to set LANG (or LC_CTYPE), no? Setting the
latter also gives you the advantage that environment variables
and command line arguments use the same encoding as file names.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 18:08:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Oct 2010 16:08:56 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <4CB334F4.1070106@v.loewis.de>
Message-ID: <1286813327.3148.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> However, I completely fail to see the advantage that the
> PYTHONFSENCODING variable has over the LANG variable. If it's
> possible to set PTHONFSENCODING in some application, it surely
> is also possible to set LANG (or LC_CTYPE), no? Setting the
> latter also gives you the advantage that environment variables
> and command line arguments use the same encoding as file names.

I guess LANG and LC_CTYPE can be used for other purposes such as
internationalization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 18:16:41 2010
From: report at bugs.python.org (Peter Gyorko)
Date: Mon, 11 Oct 2010 16:16:41 +0000
Subject: [issue10066] xmlrpclib does not handle some non-printable characters
	properly
In-Reply-To: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>
Message-ID: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>


New submission from Peter Gyorko <gyorkop at balabit.hu>:

If I add a string to the response, which contains non-printable characters, the output will not be parsed by the most of the XML parsers (I tried with XML-RPC for PHP).

Here is my quick and dirty fix:

--- a/Lib/xmlrpclib.py
+++ b/Lib/xmlrpclib.py
@@ -165,9 +165,18 @@ def _decode(data, encoding, is8bit=re.compile("[\x80-\xff]").search):
     return data
 
 def escape(s, replace=string.replace):
-    s = replace(s, "&", "&amp;")
-    s = replace(s, "<", "&lt;")
-    return replace(s, ">", "&gt;",)
+    res = ''
+    for char in s:
+        char_code = ord(char)
+        if (char_code < 32 and char_code not in (9, 10, 13)) or char_code > 126:
+            res += '\\x%02x' % ord(char)
+        else:
+            res += char
+
+    res = replace(res, "&", "&amp;")
+    res = replace(res, "<", "&lt;")
+    res = replace(res, ">", "&gt;")
+    return res
 
 if unicode:
     def _stringify(string):

----------
components: XML
messages: 118376
nosy: gyorkop
priority: normal
severity: normal
status: open
title: xmlrpclib does not handle some non-printable characters properly
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10066>
_______________________________________

From report at bugs.python.org  Mon Oct 11 18:26:35 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 11 Oct 2010 16:26:35 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <4CB334F4.1070106@v.loewis.de>
Message-ID: <4CB33AB3.9070900@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:
> 
>> Being pedantic about forcing some encoding onto things that don't
>> have an encoding won't really work out in practice. Dealing with
>> file names, OS environments, pipes and sockets is dirty work, so
>> I think we should go with the 80-20 approach in making 80% easy
>> and 20% harder, but still possible.
> 
> Unix applications can always use the byte-oriented file name APIs
> if they need to. Then you are back to the state that things have
> in Python 2. No need to have a user-tunable file system encoding
> there.

Right and if you take the position of refusing to guess
which we usually do in Python, then interfacing to file names
using bytes would be the appropriate way to handle the situation.

However, since Python3 has chosen to regard file names as
text regardless of platform, we're now in the situation that
we have to come up with some educated guess on the encoding.

> However, I completely fail to see the advantage that the
> PYTHONFSENCODING variable has over the LANG variable. If it's
> possible to set PTHONFSENCODING in some application, it surely
> is also possible to set LANG (or LC_CTYPE), no? Setting the
> latter also gives you the advantage that environment variables
> and command line arguments use the same encoding as file names.

The advantage is that you can change the Python files system
encoding *without* having to change your locale settings.

You can't possibly expect a user to switch to using UTF-8 for
all his/her applications just because Python needs this to
properly decode file names.

Users of applications written in Python will most likely not
even know how to change the locale encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 18:33:12 2010
From: report at bugs.python.org (Rafe H. Kettler)
Date: Mon, 11 Oct 2010 16:33:12 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1286814792.06.0.851080035144.issue9921@psf.upfronthosting.co.za>


Rafe H. Kettler <rafe.kettler at gmail.com> added the comment:

Radu, while the comments are not as clear for ntpath, the behavior is the same. So, the comment you detailed from posixpath could be adapted to Windows by replacing '/' with 'a separator' or something of that nature.

That said, the comment in posixpath could be adapted to clear english like so:

join() inserts a separator unless the first part is empty or already ends in a separator. If a part is absolute, join() ignores the previous parts.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Mon Oct 11 18:34:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Oct 2010 16:34:23 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1286814863.61.0.908537783094.issue9003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch which also adds 'cafile' and 'capath' keyword arguments to urlopen().

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19185/httpcli+urllib.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Mon Oct 11 18:51:24 2010
From: report at bugs.python.org (Radu Grigore)
Date: Mon, 11 Oct 2010 16:51:24 +0000
Subject: [issue9921] os.path.join('x','') behavior
In-Reply-To: <1285168977.46.0.728141650864.issue9921@psf.upfronthosting.co.za>
Message-ID: <1286815884.46.0.112113871675.issue9921@psf.upfronthosting.co.za>


Changes by Radu Grigore <radugrigore at gmail.com>:


----------
nosy:  -rgrig

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9921>
_______________________________________

From report at bugs.python.org  Mon Oct 11 19:43:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 11 Oct 2010 17:43:23 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1286819003.83.0.794680548358.issue10060@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

What I am saying is that if an extension module (one that provides non-python code in a load module) is corrupt, then it can totally screw up Python's internal bookkeeping, and there is nothing Python can do to protect itself against that.

If the "corrupt" module in question is pure Python, then you are correct, 'help' should not fail.  If, however, the corrupt module is not pure Python, then there may be nothing that can be done by Python to prevent the failure.

Can you reproduce the problem using a pure Python 'corrupt' module?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Mon Oct 11 19:47:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Oct 2010 17:47:21 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1286819241.48.0.989628309871.issue9003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch with doc updates for urllib.request.

----------
Added file: http://bugs.python.org/file19186/httpcli+urllib2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Mon Oct 11 19:51:34 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 11 Oct 2010 17:51:34 +0000
Subject: [issue5870] subprocess.DEVNULL
In-Reply-To: <1240946644.39.0.609275389725.issue5870@psf.upfronthosting.co.za>
Message-ID: <1286819494.43.0.735211103202.issue5870@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/issue5870>
_______________________________________

From report at bugs.python.org  Mon Oct 11 21:13:59 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Mon, 11 Oct 2010 19:13:59 +0000
Subject: [issue10045] poor cStringIO.StringO seek performance
In-Reply-To: <1286473069.73.0.766959244837.issue10045@psf.upfronthosting.co.za>
Message-ID: <1286824439.33.0.99826315733.issue10045@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Committed with minor changes in r85366 (release27-maint branch).

----------
keywords:  -needs review
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10045>
_______________________________________

From report at bugs.python.org  Mon Oct 11 21:48:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Oct 2010 19:48:55 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1286826535.38.0.806718380724.issue9003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch should fix the test hanging issues witnessed on some machines.

----------
Added file: http://bugs.python.org/file19187/httpcli+urllib3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Mon Oct 11 21:56:27 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Oct 2010 19:56:27 +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: <1286826987.17.0.988216104336.issue10052@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Anyway, I would like to leave the decision to the core developers.

You mean the core developers other than Stefan? ;-)

I don't have any objection to a patch for this problem, provided that that patch is specifically targeted at FreeBSD 4, and clearly doesn't change behaviour on any other platform.

On one hand I agree that FreeBSD 4 isn't a high priority platform;  on the other, it's not *that* obscure, and failure to build the Python core (rather than the extension modules) is quite a big deal.  It's also a regression from 2.6, IIUC.  And it should be easy to fix, with a single block of code in pyport.h.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From report at bugs.python.org  Mon Oct 11 21:58:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2010 19:58:51 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286827131.37.0.57750947951.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

MvL> >  - Windows: unicode for command line/env, mbcs to decode filenames
MvL> No: unicode for filenames also.

Yes, I mean unicode for everything, but decode bytes data from the mbcs encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 22:03:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2010 20:03:28 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286827408.63.0.508097499262.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

MAL> If you remove the PYTHONFSENCODING, then we have to reconsider
MAL> removal of sys.setfilesystemencoding().

Pleeeeeeeease, Marc, read my comments. You never consider technical problems, you just propose to ensure that "Python just works", without answering to my technical questions. I already explained 2 or 3 times that sys.setfilesystemencoding() was completly buggy and not usable in pratical. You proposed PYTHONFSENCODING and I implemented it. But then I explained in an email to python-dev and in this issue, that this environment variable introduced many problems.

I don't see how sys.setfilesystemencoding() would solve this issue, it's out of scope.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 22:06:26 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 11 Oct 2010 20:06:26 +0000
Subject: [issue3865] explain that profilers should be used for profiling,
	not benchmarking
In-Reply-To: <1221392860.21.0.302367581665.issue3865@psf.upfronthosting.co.za>
Message-ID: <1286827586.69.0.658575833232.issue3865@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
Here's a patch that implement what's request by Fredrik.

Regards,
Sandro

----------
keywords: +patch
nosy: +sandro.tosi
Added file: http://bugs.python.org/file19188/issue3865-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3865>
_______________________________________

From report at bugs.python.org  Mon Oct 11 22:07:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 11 Oct 2010 20:07:47 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <4CB33AB3.9070900@egenix.com>
Message-ID: <4CB36E90.6020402@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> You can't possibly expect a user to switch to using UTF-8 for
> all his/her applications just because Python needs this to
> properly decode file names.

If the user hasn't switched to UTF-8, why would Python need that
to properly decode file names?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 22:17:28 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2010 20:17:28 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286828248.41.0.92651321294.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

MAL> You can't just tell people to go with whatever encoding setup
MAL> you prefer to make Python's guessing easier or more correct.

Python doesn't really *guess* the encoding, it just reads the encoding from the locale.

What do you mean by "more correct"? How can Python knowns the right encoding better than the user? Python should not guess anything. If the environment is not correctly configured, it's not Python's fault. The user has to fix its environment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 22:19:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2010 20:19:31 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286828371.53.0.0655559117276.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I guess LANG and LC_CTYPE can be used for other purposes
> such as internationalization.

That's why there are different environement variables:
 * LC_MESSAGES for i18n (messages)
 * LC_CTYPE for the encoding
 * LC_TIME for time and date
 * etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 22:35:41 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 11 Oct 2010 20:35:41 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <1286826535.38.0.806718380724.issue9003@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=yNGchCAiyXZHpP8a40zWpo-W-SuoH477b38+X@mail.gmail.com>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Yes, it does solve the problem of httplib and urllib2_localnet tests which
were hanging with the earlier patch on certain machines..

----------
Added file: http://bugs.python.org/file19189/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________
-------------- next part --------------
Yes, it does solve the problem of httplib and urllib2_localnet tests which were hanging with the earlier patch on certain machines..<div><br>
</div>

From report at bugs.python.org  Mon Oct 11 23:16:39 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2010 21:16:39 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286831799.27.0.449485792072.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

issue9992.patch:
 - Remove PYTHONFSENCODING environment variable
 - Mac OS X: Use utf-8 to decode command line arguments
 - Fix issue #9992 (this issue): attached test, locale_fs_encoding.py, pass
 - Fix issue #9988
 - Fix issue #10014
 - Fix issue #10039

$ diffstat issue9992.patch 
 Doc/using/cmdline.rst       |   12 ------------
 Doc/whatsnew/3.2.rst        |    6 ------
 Lib/test/test_os.py         |   30 ------------------------------
 Lib/test/test_subprocess.py |    4 ----
 Lib/test/test_sys.py        |   29 -----------------------------
 Modules/main.c              |    3 ---
 Modules/python.c            |   10 +++++++++-
 Python/pythonrun.c          |   22 ++++++----------------
 8 files changed, 15 insertions(+), 101 deletions(-)

I like such patch: it removes more code than it adds, but it fixes 4 different issues!

I didn't tested the patch specific to OSX (use utf8 to decode command line arguments).

----------
Added file: http://bugs.python.org/file19190/issue9992.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 23:36:55 2010
From: report at bugs.python.org (Jesse Kaukonen)
Date: Mon, 11 Oct 2010 21:36:55 +0000
Subject: [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>
Message-ID: <1286833015.8.0.586754850146.issue9991@psf.upfronthosting.co.za>


Jesse Kaukonen <jesse.kaukonen at gmail.com> added the comment:

This problem also occurs with our service at www.renderfarm.fi with Blender. I tested the included patch, and can confirm that it works. I'm very interested in the possibility of seeing this included in the official release ASAP!

----------
nosy: +gekko

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9991>
_______________________________________

From report at bugs.python.org  Mon Oct 11 23:42:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2010 21:42:17 +0000
Subject: [issue9992] Command line arguments are not correctly decodediflocale
	and fileystem encodingsaredifferent
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286833337.09.0.258678224032.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I think that issue9992.patch fixes also #4388 because it uses the same encoding (FS encoding, utf8) on OSX to encode and to decode command line arguments.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Mon Oct 11 23:44:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Oct 2010 21:44:19 +0000
Subject: [issue9991] xmlrpc client ssl check faulty
In-Reply-To: <1285798534.22.0.74771320533.issue9991@psf.upfronthosting.co.za>
Message-ID: <1286833459.95.0.734953597555.issue9991@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9991>
_______________________________________

From report at bugs.python.org  Mon Oct 11 23:50:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 11 Oct 2010 21:50:51 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1286833851.36.0.922758851219.issue8533@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Oops, sorry. I'll withdraw my last patch.

Why? Your patch is useful to run a single test outside regrtest. But you should not remove the hack on regrtest.py, only keep your patch on unittest/runner.py. There are not exclusive.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Tue Oct 12 02:24:07 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 12 Oct 2010 00:24:07 +0000
Subject: [issue8533] regrtest: use backslashreplace error handler for stdout
In-Reply-To: <1272278593.97.0.387479540648.issue8533@psf.upfronthosting.co.za>
Message-ID: <1286843047.41.0.62784890003.issue8533@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you. I'll reattach the patch only for Lib/unittest/runner.py

----------
Added file: http://bugs.python.org/file19191/py3k_also_no_unicode_error_on_direct_test_run.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8533>
_______________________________________

From report at bugs.python.org  Tue Oct 12 02:47:32 2010
From: report at bugs.python.org (Dev Player)
Date: Tue, 12 Oct 2010 00:47:32 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286819003.83.0.794680548358.issue10060@psf.upfronthosting.co.za>
Message-ID: <AANLkTik+mucNU4jewfeuESSjkwZYeuCNfR76Pt3tuepc@mail.gmail.com>


Dev Player <devplayer at gmail.com> added the comment:

> On Mon, Oct 11, 2010 at 1:43 PM, R. David Murray <report at bugs.python.org>wrote:
> R. David Murray <rdmurray at bitdance.com> added the comment:
> Can you reproduce the problem using a pure Python 'corrupt' module?
> ----------
>

When in python.exe, and you type help() then modules, aren't you really
asking for packages?
I don't know how to make a package let alone a corrupt one.

If help() modules is in fact looking for just a Python module file with
extension _.py in lib\site-packages I don't know what Python help() modules
looks for in that source code _.py file to be considered a module worth
reporting back to the user. Certain module attributes?

I do not know enough atm about how PythonWin is packaged. I'll look into it
but I'm a newbie here and hopes for well informed facts on PythonWin may be
... well leave it at that.

Perhaps an idea here too: If python.exe help() modules crashes when it
passes control to a module or package that is not pure Python (source code
or byte code) but some kind of C SWIG thing, then perhaps to make python.exe
more robust it should simulate what idle does, as idle does not crash and it
reports error when finished with calling python.exe help() modules.

In other words, perhaps the Python interpreter can call an external routine
(another program) that behaves like help() modules, perhaps using something
like os.system() or subprocess.Popen(). Call it help.py or help.exe or
something. If help.exe returns, all is good. If help crashes just like
Python did at least Python can handle the crashing of help.exe gracefully.
This idea is purely with the interest to make python.exe more robust.

----------
Added file: http://bugs.python.org/file19192/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________
-------------- next part --------------
<br>
<div class="gmail_quote">
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">
<div class="im">On Mon, Oct 11, 2010 at 1:43 PM, R. David Murray <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>R. David Murray &lt;<a href="mailto:rdmurray at bitdance.com">rdmurray at bitdance.com</a>&gt; added the comment:<br>
Can you reproduce the problem using a pure Python &#39;corrupt&#39; module?<br>----------<br></div></blockquote>
<div>??</div>
<div>When in python.exe, and you type help() then modules, aren&#39;t you really asking for packages? </div>
<div>I don&#39;t know how to make a package let alone a corrupt one.</div>
<div>??</div>
<div>If help() modules is in fact looking for just a Python module file with extension _.py in lib\site-packages I don&#39;t know what Python help() modules looks for in that source code _.py file to be considered a module worth reporting back to the user. Certain module attributes?</div>

<div>??</div>
<div>I do not know enough atm about how PythonWin is packaged. I&#39;ll look into it but I&#39;m a newbie here and hopes for??well informed facts on PythonWin may be ... well leave it at that.</div>
<div>??</div>
<div>Perhaps an idea here too: If python.exe help() modules crashes when it passes control to a module or package that is not pure Python (source code or byte code) but some kind of C SWIG thing, then perhaps to make python.exe more robust it should simulate what idle does, as idle does not crash and it reports error when finished with calling python.exe help() modules.</div>

<div>??</div>
<div>In other words, perhaps the Python interpreter can call an external routine (another program) that behaves like help() modules, perhaps using something like os.system() or subprocess.Popen(). Call it help.py or help.exe or something. If help.exe returns, all is good. If help crashes just like Python did at least Python can handle the crashing of help.exe gracefully. This idea is purely with the interest to make python.exe more robust.</div>

<div>??</div></div>

From report at bugs.python.org  Tue Oct 12 03:46:22 2010
From: report at bugs.python.org (kai zhu)
Date: Tue, 12 Oct 2010 01:46:22 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286847982.09.0.49693258235.issue10041@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

np antoine :)

this 2 line patch will match socket.makefile() signature with open().
any chance it can b committed b4 python3.2 beta?

i rely on this patch in order to forward-port redis to python3

----------
Added file: http://bugs.python.org/file19193/makefile.errors.newline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Tue Oct 12 04:30:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Oct 2010 02:30:22 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286850622.73.0.296901536604.issue10041@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Kai: could you write a unit test for this?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Tue Oct 12 05:28:59 2010
From: report at bugs.python.org (Tangaroa)
Date: Tue, 12 Oct 2010 03:28:59 +0000
Subject: [issue1028] Tkinter binding involving Control-spacebar raises unicode
	error
In-Reply-To: <1188161311.7.0.864205774814.issue1028@psf.upfronthosting.co.za>
Message-ID: <1286854139.58.0.016185280581.issue1028@psf.upfronthosting.co.za>


Tangaroa <jsprunck at yahoo.com> added the comment:

Python 3.1.2, Ubuntu (Lucid)

Caused by Control + Shift + Spacebar 

Debugger output from terminal: 

Traceback (most recent call last):
  File "/usr/bin/idle-python3.1", line 5, in <module>
    main()
  File "/usr/lib/python3.1/idlelib/PyShell.py", line 1420, in main
    root.mainloop()
  File "/usr/lib/python3.1/tkinter/__init__.py", line 1012, in mainloop
    self.tk.mainloop(n)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-1: illegal encoding

Will try the patch.

----------
nosy: +jsprunck -amaury.forgeotdarc, doko, ezio.melotti, gpolo, kbk, nnorwitz, ocean-city, terry.reedy, wplappert
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1028>
_______________________________________

From report at bugs.python.org  Tue Oct 12 05:50:20 2010
From: report at bugs.python.org (kai zhu)
Date: Tue, 12 Oct 2010 03:50:20 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286855420.95.0.101875969555.issue10041@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

added unittest to patch
tested test.test_socket on debian colinux running under winxp



i get 2 unrelated errors (in both patched and unpatched version) from testRDM and testStream about socket.AF_TIPC being unsupported:



public at colinux 3 ~/build/py3k.patch: ./python -m unittest test.test_socket
..................................................................s..........................................EE....................
======================================================================
ERROR: testRDM (test.test_socket.TIPCTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/public/build/py3k.patch/Lib/test/test_socket.py", line 1683, in testRDM
    srv = socket.socket(socket.AF_TIPC, socket.SOCK_RDM)
  File "/home/public/build/py3k.patch/Lib/socket.py", line 94, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
socket.error: [Errno 97] Address family not supported by protocol

======================================================================
ERROR: testStream (test.test_socket.TIPCThreadableTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/public/build/py3k.patch/Lib/test/test_socket.py", line 131, in _setUp
    self.__setUp()
  File "/home/public/build/py3k.patch/Lib/test/test_socket.py", line 1707, in setUp
    self.srv = socket.socket(socket.AF_TIPC, socket.SOCK_STREAM)
  File "/home/public/build/py3k.patch/Lib/socket.py", line 94, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
socket.error: [Errno 97] Address family not supported by protocol

----------------------------------------------------------------------
Ran 131 tests in 15.960s

FAILED (errors=2, skipped=1)

----------
Added file: http://bugs.python.org/file19194/socket.makefile.with.unittest.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Tue Oct 12 06:50:30 2010
From: report at bugs.python.org (kai zhu)
Date: Tue, 12 Oct 2010 04:50:30 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286859030.21.0.910006130082.issue10041@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

updated unittest patch

----------
Added file: http://bugs.python.org/file19195/socket.makefile.with.unittest.v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Tue Oct 12 07:04:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 05:04:21 +0000
Subject: [issue2953] _zip_directory_cache untested and undocumented
In-Reply-To: <1211574365.23.0.256921758457.issue2953@psf.upfronthosting.co.za>
Message-ID: <1286859861.2.0.129998569772.issue2953@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file13625/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2953>
_______________________________________

From report at bugs.python.org  Tue Oct 12 07:04:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 05:04:33 +0000
Subject: [issue2953] _zip_directory_cache untested and undocumented
In-Reply-To: <1211574365.23.0.256921758457.issue2953@psf.upfronthosting.co.za>
Message-ID: <1286859873.7.0.603887116057.issue2953@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file13638/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2953>
_______________________________________

From report at bugs.python.org  Tue Oct 12 07:05:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 05:05:54 +0000
Subject: [issue2953] _zip_directory_cache untested and undocumented
In-Reply-To: <1211574365.23.0.256921758457.issue2953@psf.upfronthosting.co.za>
Message-ID: <1286859954.99.0.458259330455.issue2953@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Could the recently-added functools.lru_cache help here?

----------
components:  -Distutils
nosy: +eric.araujo
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2953>
_______________________________________

From report at bugs.python.org  Tue Oct 12 07:11:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 05:11:48 +0000
Subject: [issue4758] Python 3.x internet documentation needs work
In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>
Message-ID: <1286860308.34.0.529683521645.issue4758@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Rafe, thank you for your message and willingness to contribute.  I feel what you?re reporting is another bug: the original report talks about bytes/str confusion only, not about the simplicity of the APIs.   Could you open another bug with component ?Documentation? and add orsenthil to the nosy list?  Thanks in advance.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4758>
_______________________________________

From report at bugs.python.org  Tue Oct 12 09:17:53 2010
From: report at bugs.python.org (Shashank)
Date: Tue, 12 Oct 2010 07:17:53 +0000
Subject: [issue10030] Patch for zip decryption speedup
In-Reply-To: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>
Message-ID: <1286867873.76.0.355861900126.issue10030@psf.upfronthosting.co.za>


Shashank <shashank.sunny.singh at gmail.com> added the comment:

Attached is a patch with changes in Lib/test/test_zipfile.py to test both C and pure-py impls (on systems where the C impl is present).

Admittedly, this approach to emulating the absence of C impl is a bit hacky. This is primarily because the changed class is not a part of the public API and hence not being tested directly.

David, could you verify that the approach is ok?

----------
Added file: http://bugs.python.org/file19196/zipdecrypt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10030>
_______________________________________

From report at bugs.python.org  Tue Oct 12 09:34:34 2010
From: report at bugs.python.org (=?utf-8?b?SHJ2b2plIE5pa8WhacSH?=)
Date: Tue, 12 Oct 2010 07:34:34 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286868874.15.0.570448837983.issue10049@psf.upfronthosting.co.za>


Hrvoje Nik?i? <hniksic at gmail.com> added the comment:

Is there anything else I need to do to have the patch reviewed and applied?

I am in no hurry since we're still using 2.x, I'd just like to know if more needs to be done on my part to move the issue forward.  My last Python patch was accepted quite some years ago, so I'm not closely familiar with the current approval process.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Tue Oct 12 09:56:36 2010
From: report at bugs.python.org (Shashank)
Date: Tue, 12 Oct 2010 07:56:36 +0000
Subject: [issue10030] Patch for zip decryption speedup
In-Reply-To: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>
Message-ID: <1286870196.85.0.415004822937.issue10030@psf.upfronthosting.co.za>


Changes by Shashank <shashank.sunny.singh at gmail.com>:


Added file: http://bugs.python.org/file19197/zipdecrypt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10030>
_______________________________________

From report at bugs.python.org  Tue Oct 12 11:20:14 2010
From: report at bugs.python.org (Daniel Abel)
Date: Tue, 12 Oct 2010 09:20:14 +0000
Subject: [issue10067] itertools' docs put izip_longest in the "terminating on
	the shortest input sequence" section
In-Reply-To: <1286875214.59.0.114835470036.issue10067@psf.upfronthosting.co.za>
Message-ID: <1286875214.59.0.114835470036.issue10067@psf.upfronthosting.co.za>


New submission from Daniel Abel <abeld at hal.elte.hu>:

Both the 2.x and 3.x documentation for itertools has izip_longest (zip_longest for 3.x)  in the "Iterators terminating on the shortest input sequence" section. However, according to izip_longest's documentation, it terminates when the _longest_ iterator is exhausted.

Possible fixes might be:
- put izip_longest in a new "Iterators terminating on the longest input sequence" section
- rename section to "Iterators terminating on one of the input sequences"

----------
assignee: docs at python
components: Documentation
messages: 118407
nosy: abeld, docs at python
priority: normal
severity: normal
status: open
title: itertools' docs put izip_longest in the "terminating on the shortest input sequence" section
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10067>
_______________________________________

From report at bugs.python.org  Tue Oct 12 12:09:28 2010
From: report at bugs.python.org (Valery Lesin)
Date: Tue, 12 Oct 2010 10:09:28 +0000
Subject: [issue10068] global objects created in some module are not destroyed
	when last reference to that module is released
In-Reply-To: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>
Message-ID: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>


New submission from Valery Lesin <valery.lesin at gmail.com>:

Interpreter: Python 3.1.2

Sample:

===== first.py =====
import sys
import second 

if 'second' in sys.modules:
  print ('in sys modules')
  del sys.modules['second']

del second

===== second.py =====
class A:
 def __init__(self):
   print('created')

 def __del__(self):
   print('destroyed')

a = A()
---------------------------------------------

Result: 'destroyed' isn't printed
With Python 2.6.5 it worked fine

----------
components: Interpreter Core
messages: 118408
nosy: Valery.Lesin
priority: normal
severity: normal
status: open
title: global objects created in some module are not destroyed when last reference to that module is released
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10068>
_______________________________________

From report at bugs.python.org  Tue Oct 12 12:40:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Oct 2010 10:40:04 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286880004.13.0.536188233684.issue10049@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Unless Nick has further feedback I think you've done all you need to, thanks.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:16:48 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 12 Oct 2010 11:16:48 +0000
Subject: [issue10069] 2to3 crash in fix_urllib.py
In-Reply-To: <1286882208.41.0.35723041656.issue10069@psf.upfronthosting.co.za>
Message-ID: <1286882208.41.0.35723041656.issue10069@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

This line:

from urllib import quote as quote_url, urlencode

makes 2to3 on Python 3.2a2 crash.
At lib2to3/fixes/fix_urllib.py line 124, member = None.

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 118410
nosy: hfuru
priority: normal
severity: normal
status: open
title: 2to3 crash in fix_urllib.py
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10069>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:24:21 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 12 Oct 2010 11:24:21 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

It would be nice with some official way to tell 2to3, "Leave
this code chunk alone.  This is 2.* code, that is 3.* code":

try:                      # Python 2.6
    from urlparse         import urlparse, urlunparse
except ImportError:       # Python 3
    from urllib.parse     import urlparse, urlunparse

Could 2to3 without -p notice more cases of print(single argument),
to avoid slapping another () around them?  For example:

print(2*3)
print(", ".join(dir))

----------
components: 2to3 (2.x to 3.0 conversion tool)
messages: 118411
nosy: hfuru
priority: normal
severity: normal
status: open
title: 2to3 wishes for already-2to3'ed files
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:24:43 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 12 Oct 2010 11:24:43 +0000
Subject: [issue10068] global objects created in some module are not destroyed
	when last reference to that module is released
In-Reply-To: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>
Message-ID: <1286882683.74.0.411756029905.issue10068@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This also reproduces in 2.7.
2.6 and 2.7 have a different behaviour.

----------
nosy: +amaury.forgeotdarc
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10068>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:25:32 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 12 Oct 2010 11:25:32 +0000
Subject: [issue10069] 2to3 crash in fix_urllib.py
In-Reply-To: <1286882208.41.0.35723041656.issue10069@psf.upfronthosting.co.za>
Message-ID: <1286882732.68.0.40103727115.issue10069@psf.upfronthosting.co.za>


Changes by Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:


----------
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10069>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:43:24 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 12 Oct 2010 11:43:24 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
In-Reply-To: <1286883804.1.0.981912449546.issue10071@psf.upfronthosting.co.za>
Message-ID: <1286883804.1.0.981912449546.issue10071@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Currently, PC/winreg.c releases GIL while calling registry
API, but I found this in Remarks section of RegEnumValue.

http://msdn.microsoft.com/en-us/library/ms724865%28VS.85%29.aspx

> While using RegEnumValue, an application should not call any registry
> functions that might change the key being queried.

Maybe we shouldn't release GIL in PC/winreg.c? Thank you.

# I sometimes experienced crash of test_changing_value(test_winreg)
# on release27-maint. It happens when 2 threads calls PyEnumValue and
# PySetValue simultaneously. And I could stop it by following patch.
# I'll attach the stack trace of crash.

Index: PC/_winreg.c
===================================================================
--- PC/_winreg.c	(revision 85344)
+++ PC/_winreg.c	(working copy)
@@ -1219,7 +1219,6 @@
     }
 
     while (1) {
-        Py_BEGIN_ALLOW_THREADS
         rc = RegEnumValue(hKey,
                   index,
                   retValueBuf,
@@ -1228,7 +1227,6 @@
                   &typ,
                   (BYTE *)retDataBuf,
                   &retDataSize);
-        Py_END_ALLOW_THREADS
 
         if (rc != ERROR_MORE_DATA)
             break;
@@ -1577,9 +1575,7 @@
         if (subKey == NULL)
             return NULL;
     }
-    Py_BEGIN_ALLOW_THREADS
     rc = RegSetValue(hKey, subKey, REG_SZ, str, len+1);
-    Py_END_ALLOW_THREADS
     if (rc != ERROR_SUCCESS)
         return PyErr_SetFromWindowsErrWithFunction(rc, "RegSetValue");
     Py_INCREF(Py_None);

----------
components: Extension Modules
files: py27_test_winreg_crash_stack_trace.txt
messages: 118413
nosy: ocean-city
priority: normal
severity: normal
status: open
title: Should not release GIL while running RegEnumValue
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19198/py27_test_winreg_crash_stack_trace.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:46:17 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 12 Oct 2010 11:46:17 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
Message-ID: <1286883977.65.0.560230605814.issue10071@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
Removed message: http://bugs.python.org/msg118413

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:48:35 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 12 Oct 2010 11:48:35 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
In-Reply-To: <1286884115.46.0.809960786814.issue10071@psf.upfronthosting.co.za>
Message-ID: <1286884115.46.0.809960786814.issue10071@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Currently, PC/winreg.c releases GIL while calling registry
API, but I found this in Remarks section of RegEnumValue.

http://msdn.microsoft.com/en-us/library/ms724865%28VS.85%29.aspx

> While using RegEnumValue, an application should not call any registry
> functions that might change the key being queried.

Maybe we shouldn't release GIL in PC/winreg.c? Thank you.

# I sometimes experienced crash of test_changing_value(test_winreg)
# on release27-maint. It happens when 2 threads calls PyEnumValue and
# PySetValue simultaneously. And I could stop it by following patch.
# I'll attach the stack trace of crash.

Index: PC/_winreg.c
===================================================================
--- PC/_winreg.c	(revision 85344)
+++ PC/_winreg.c	(working copy)
@@ -1219,7 +1219,6 @@
     }
 
     while (1) {
-        Py_BEGIN_ALLOW_THREADS
         rc = RegEnumValue(hKey,
                   index,
                   retValueBuf,
@@ -1228,7 +1227,6 @@
                   &typ,
                   (BYTE *)retDataBuf,
                   &retDataSize);
-        Py_END_ALLOW_THREADS
 
         if (rc != ERROR_MORE_DATA)
             break;
@@ -1577,9 +1575,7 @@
         if (subKey == NULL)
             return NULL;
     }
-    Py_BEGIN_ALLOW_THREADS
     rc = RegSetValue(hKey, subKey, REG_SZ, str, len+1);
-    Py_END_ALLOW_THREADS
     if (rc != ERROR_SUCCESS)
         return PyErr_SetFromWindowsErrWithFunction(rc, "RegSetValue");
     Py_INCREF(Py_None);

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:54:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 12 Oct 2010 11:54:15 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1286884455.97.0.259933277388.issue10070@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't understand. If the code is already Python 3 code, why are you running 2to3 on it?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:56:16 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 12 Oct 2010 11:56:16 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
In-Reply-To: <1286884115.46.0.809960786814.issue10071@psf.upfronthosting.co.za>
Message-ID: <1286884576.7.0.609777004123.issue10071@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file19198/py27_test_winreg_crash_stack_trace.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:56:28 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 12 Oct 2010 11:56:28 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
Message-ID: <1286884588.71.0.25754197998.issue10071@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
Removed message: http://bugs.python.org/msg118414

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:56:58 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 12 Oct 2010 11:56:58 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
Message-ID: <1286884618.71.0.164895598724.issue10071@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Tue Oct 12 13:57:31 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 12 Oct 2010 11:57:31 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
In-Reply-To: <1286884651.82.0.158483399845.issue10071@psf.upfronthosting.co.za>
Message-ID: <1286884651.82.0.158483399845.issue10071@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Currently, PC/winreg.c releases GIL while calling registry
API, but I found this in Remarks section of RegEnumValue.

http://msdn.microsoft.com/en-us/library/ms724865%28VS.85%29.aspx

> While using RegEnumValue, an application should not call any registry
> functions that might change the key being queried.

Maybe we shouldn't release GIL in PC/winreg.c? Thank you.

----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Tue Oct 12 14:15:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Oct 2010 12:15:53 +0000
Subject: [issue10069] 2to3 crash in fix_urllib.py
In-Reply-To: <1286882208.41.0.35723041656.issue10069@psf.upfronthosting.co.za>
Message-ID: <1286885753.36.0.711083763051.issue10069@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +benjamin.peterson
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10069>
_______________________________________

From report at bugs.python.org  Tue Oct 12 14:18:50 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 12 Oct 2010 12:18:50 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286884455.97.0.259933277388.issue10070@psf.upfronthosting.co.za>
Message-ID: <hbf.20101012gb6u@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Martin v. L??wis writes:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> I don't understand. If the code is already Python 3 code, why are you
> running 2to3 on it?

I should have clarified - it's still Python 2 code (maybe 2.7), moving
one step at a time towards something which will work on Python 3 as
well.

Or it's just that I'm handling one issue which 2to3 reports at a time,
like modifying str vs bytes vs unicode usage, then I come back and look
at another thing 2to3 has to say.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 14:19:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 12:19:04 +0000
Subject: [issue10068] global objects created in some module are not destroyed
	when last reference to that module is released
In-Reply-To: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>
Message-ID: <1286885944.78.0.0292994255743.issue10068@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Probably issue7140, which will disable clearing of the module dict if it's caught in a reference cycle (which it is here, since A.__init__ and A.__del__ will reference it as their globals dict).

----------
nosy: +benjamin.peterson, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10068>
_______________________________________

From report at bugs.python.org  Tue Oct 12 14:33:52 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 12 Oct 2010 12:33:52 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1286886832.35.0.0262360609893.issue10070@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I still don't understand. If it's 2.x code, why do you want to say that it is 3.x code?

If you don't want to run a specific fixer, you can exclude it from the list of fixers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 14:34:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 12:34:13 +0000
Subject: [issue10030] Patch for zip decryption speedup
In-Reply-To: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>
Message-ID: <1286886853.68.0.569196405129.issue10030@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hello,

Some quick comments:
- the C module should be private and therefore called _zipdecrypt
- if you want to avoid API mismatch, you could give a tp_call to your C decrypter object, rather than a "decrypt" method
- you can put all initialization code in zipdecrypt_new and avoid the need for zipdecrypt_init
- it's better to use the "y*" code in PyArg_ParseTuple, rather than "s#"
- you should define your module as PY_SSIZE_T_CLEAN and use Py_ssize_t as length variables (rather than int)
- you *mustn't* change the contents of the buffer which is given you by "s#" or "y*", since that buffer is read-only (it can be a bytes object); instead, create a new bytes object using PyBytes_FromStringAndSize(NULL, length) and write into that; or, if you want a read-write buffer, use the "w*" code

----------
nosy: +pitrou
stage:  -> patch review
versions: +Python 3.2 -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10030>
_______________________________________

From report at bugs.python.org  Tue Oct 12 14:41:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 12 Oct 2010 12:41:49 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1286887309.72.0.685802894989.issue8611@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Tue Oct 12 14:41:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 12 Oct 2010 12:41:55 +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: <1286887315.0.0.251545332314.issue8746@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: deferred blocker -> release blocker

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8746>
_______________________________________

From report at bugs.python.org  Tue Oct 12 14:52:51 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 12 Oct 2010 12:52:51 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286886832.35.0.0262360609893.issue10070@psf.upfronthosting.co.za>
Message-ID: <hbf.20101012gx87@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Martin v. L??wis writes:
> I still don't understand. If it's 2.x code, why do you want to say that
> it is 3.x code?

It works on Python 2.  It runs on Python 3 - maybe correctly, or maybe
it's not that far along yet.  Maybe some files in a package work on
Python 3, and others have not yet been updated.

> If you don't want to run a specific fixer, you can exclude it from the
> list of fixers.

I know.  So this request is mostly for convenience, but then so is 2to3
in the first place.

print(single argument) would be nice to leave alone in any case though,
since there can be other reasons for the ().  E.g.:

    print(very long
          single argument)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 15:27:17 2010
From: report at bugs.python.org (Rafe H. Kettler)
Date: Tue, 12 Oct 2010 13:27:17 +0000
Subject: [issue4758] Python 3.x internet documentation needs work
In-Reply-To: <1230383680.06.0.695552325819.issue4758@psf.upfronthosting.co.za>
Message-ID: <1286890037.91.0.998103920597.issue4758@psf.upfronthosting.co.za>


Rafe H. Kettler <rafe.kettler at gmail.com> added the comment:

Thanks Eric, I think you're right. I'll do that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4758>
_______________________________________

From report at bugs.python.org  Tue Oct 12 15:32:10 2010
From: report at bugs.python.org (Rafe H. Kettler)
Date: Tue, 12 Oct 2010 13:32:10 +0000
Subject: [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>


New submission from Rafe H. Kettler <rafe.kettler at gmail.com>:

I think that the documentation for ftplib is a bit too concise and assumes that the reader in an expert in the protocol when the point of the module is to abstract out such details.

For example, for the error documentation, the exceptions are only explained by the error code the server can return to trigger them. So, while the explanation of error_perm, for example, should say something about permissions, it just says "raised when an error code in the range 500?599 is received." This is particularly unclear for those with no knowledge of the internals of the protocol.

Also, in the documentation for RetrLines(), the documentation mentions the options LIST, NLST, and MLSD without explaining what they are. I know that when I first started using ftplib I had to experiment with each option to determine what they do, and I think it would be better if this was clear in the docs from the start.

This can become particularly unclear for less FTP-savvy users.

I can propose a patch to the documentation if needed.

----------
assignee: docs at python
components: Documentation
messages: 118423
nosy: Rafe.H..Kettler, docs at python, orsenthil
priority: normal
severity: normal
status: open
title: ftplib documentation is unclear
type: feature request
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10072>
_______________________________________

From report at bugs.python.org  Tue Oct 12 15:47:56 2010
From: report at bugs.python.org (AM Helin)
Date: Tue, 12 Oct 2010 13:47:56 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>


New submission from AM Helin <shadikka at gmail.com>:

calendar.isleap() doesn't enforce any types, leading to string formatting errors when a string is passed to it:

>>> calendar.isleap("2011")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Library/Frameworks/Python.framework/Versions/3.1/lib/python3.1/calendar.py", line 99, in isleap
    return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)
TypeError: not all arguments converted during string formatting

A quick peek at the SVN shows that the problem still exists.

----------
components: Library (Lib)
messages: 118424
nosy: shadikka
priority: normal
severity: normal
status: open
title: calendar.isleap() not checking parameter type
versions: Python 2.7, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 12 15:48:07 2010
From: report at bugs.python.org (AM Helin)
Date: Tue, 12 Oct 2010 13:48:07 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1286891287.86.0.248505565664.issue10073@psf.upfronthosting.co.za>


Changes by AM Helin <shadikka at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 12 15:55:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 13:55:47 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1286891747.94.0.164635420984.issue10073@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/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 12 15:59:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 13:59:39 +0000
Subject: [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1286891979.22.0.702361109835.issue10072@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10072>
_______________________________________

From report at bugs.python.org  Tue Oct 12 16:11:25 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 12 Oct 2010 14:11:25 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1286892685.06.0.886216583275.issue10070@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Maybe we need to tackle this from a different angle: can you please specify the feature you are asking for exactly, with any syntax, API, or command line changes that you consider necessary?

Omitting redundant parentheses for print is a separate issue (feel free to open an issue); we should not mix it with this issue (which I still don't understand).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 16:49:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Oct 2010 14:49:26 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1286894966.69.0.241118546662.issue10073@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

In Python we often don't type check, we just let errors happen.  It is true that it would make the problem clearer to do a type check and issue a specific error message, but I don't know if it is worth it.  (The error would already have been clear if it weren't for the fact that % is the string formatting operator...)

----------
nosy: +r.david.murray
versions: +Python 3.1, Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 12 17:14:49 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 12 Oct 2010 15:14:49 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286892685.06.0.886216583275.issue10070@psf.upfronthosting.co.za>
Message-ID: <hbf.20101012jh7w@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

> Maybe we need to tackle this from a different angle: can you please
> specify the feature you are asking for exactly, with any syntax, API, or
> command line changes that you consider necessary?

First, nothing here is necessary, since it's just a request for a
convenience.  The syntax could be a generalization of the example I
gave:

  <whatever>:   # Python <version>
     <indented block> 

and

   <whatever>:
      # Python <version>
      <indented block>

tell 2to3 "The code in <block> it is expected to only run (or succeed)
in Python <version>.  Do not modify it, except it is an error if it
is a syntax error under Python 3 so the script won't even run".

'<whatever>:' can be some if,else,try,except, I don't know what else,
and is responsible for making different Python versions do the right
thing.

> Omitting redundant parentheses for print is a separate issue (feel
> free to open an issue); we should not mix it with this issue (which
> I still don't understand).

OK.  But I don't understand what you don't understand...

I have some Python 2 files in various stages of transition to be
runnable and correct in Python 3, while still working in Python 2.
It'd be convenient if the parts that do work under both Python 2 and 3
could be written so that 2to3 would be silent about them, without need
for different 2to3 command line options for different .py files.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 17:16:13 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Oct 2010 15:16:13 +0000
Subject: [issue1708] improvements for linecache
In-Reply-To: <1199024318.28.0.602984080184.issue1708@psf.upfronthosting.co.za>
Message-ID: <1286896573.73.0.00450342543337.issue1708@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I am indeed going to close this.  The patch isn't complete, since there's the line ending issue Antoine pointed out, which implies that there are also some missing tests.  

I doubt that linecache performance is something that affects very many people, but if someday someone wants to pick this up and finish it, it sounds like there's no objection in principle to the change.

----------
nosy: +r.david.murray -BreamoreBoy
resolution:  -> later
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1708>
_______________________________________

From report at bugs.python.org  Tue Oct 12 17:25:25 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 12 Oct 2010 15:25:25 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286892685.06.0.886216583275.issue10070@psf.upfronthosting.co.za>
Message-ID: <hbf.20101012jo4f@bombur.uio.no>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

Another syntax could be attached to if-else and try-except.  Given:

    if ...:
        <block 1>
    else:
        <block 2>

or
    try:
        <block 1>
    except ...:
        <block 2>

if 2to3 would translate <block 1> to <block 2> or vise versa, sans
whitespace/comment differences, then it does not do so.  Instead it
assumes the blocks are for running under Python 2 and 3 respectively.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 18:02:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 12 Oct 2010 16:02:06 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1286899326.08.0.142633622173.issue10073@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I agree with David on this one.  In addition to the arguments already stated, the string value of an exception is not part of specification.  The exception is still TypeError even if the message may be confusing.  I also find that once read in the context of the backtrace, the error is clear enough.

I am changing this to an RFE for now, but I think this should be closed as "won't fix".

----------
assignee:  -> belopolsky
type: behavior -> feature request
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 12 18:33:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Oct 2010 16:33:27 +0000
Subject: [issue6322] Pdb breakpoints don't work on lines without bytecode
In-Reply-To: <1245679754.68.0.982838087844.issue6322@psf.upfronthosting.co.za>
Message-ID: <1286901207.78.0.356090341616.issue6322@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +georg.brandl -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6322>
_______________________________________

From report at bugs.python.org  Tue Oct 12 18:41:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 16:41:00 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286901660.15.0.27687307602.issue10063@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

file: URIs provoking FTP access seem wrong to me.  Are there widely-used tools displaying this behavior?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Tue Oct 12 18:46:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Oct 2010 16:46:33 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286901993.47.0.165250715365.issue10063@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I doubt it.  As Senthil says, file invoking ftp it is a bug.  I'm just betting that *someone* is going to complain when it stops working in their particular situation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Tue Oct 12 18:47:37 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 16:47:37 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286902057.9.0.637989337466.issue10063@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Ah, I thought this was not a bug, because of ?RFC 1738, says that host, if present should be the FQDN of the machine?.  If it?s a bug I?m all for fixing it in all three versions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Tue Oct 12 18:52:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 16:52:48 +0000
Subject: [issue10066] xmlrpclib does not handle some non-printable characters
	properly
In-Reply-To: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>
Message-ID: <1286902368.05.0.233153070103.issue10066@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Unfortunately, 2.6 only gets security fixes, not general bug fixes; can you tell if this applies to 2.7, 3.1 and 3.2?  If you have a small script that displays the problem, please attach it.

----------
nosy: +eric.araujo, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10066>
_______________________________________

From report at bugs.python.org  Tue Oct 12 18:55:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 16:55:16 +0000
Subject: [issue10069] 2to3 crash in fix_urllib.py
In-Reply-To: <1286882208.41.0.35723041656.issue10069@psf.upfronthosting.co.za>
Message-ID: <1286902516.65.0.917734190607.issue10069@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/issue10069>
_______________________________________

From report at bugs.python.org  Tue Oct 12 18:57:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 16:57:38 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1286902658.72.0.227582806234.issue10070@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/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:01:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 17:01:59 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1286902919.1.0.34878084256.issue10070@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

How about this phrasing: ?Make 2to3 fixers not touch code in a block starting with ?if sys.version >= '3'?? (and hexversion, version_info, you get the idea)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:03:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 17:03:27 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1286903007.69.0.489556992611.issue10073@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/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:06:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 17:06:02 +0000
Subject: =?utf-8?q?=5Bissue10039=5D_python_=C3=A9=2Epy_fails_with_UnicodeEncodeErr?=
	=?utf-8?q?or_if_PYTHONFSENCODING_is_used?=
In-Reply-To: <1286414733.34.0.0267403088134.issue10039@psf.upfronthosting.co.za>
Message-ID: <1286903162.25.0.123832608621.issue10039@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t understand why reading a filename would not respect the envvar stating the filesystem encoding.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10039>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:08:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 17:08:33 +0000
Subject: [issue10042] total_ordering stack overflow
In-Reply-To: <1286440012.74.0.624864175042.issue10042@psf.upfronthosting.co.za>
Message-ID: <1286903313.54.0.838841536703.issue10042@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/issue10042>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:12:45 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 12 Oct 2010 17:12:45 +0000
Subject: [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1286903565.63.0.0152440606512.issue10072@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

A patch would be great.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10072>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:15:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 17:15:39 +0000
Subject: [issue8106] SSL session management
In-Reply-To: <1268184052.67.0.269640299758.issue8106@psf.upfronthosting.co.za>
Message-ID: <1286903739.39.0.265190356323.issue8106@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

http://www.openssl.org/docs/ssl/SSL_CTX_set_session_cache_mode.html suggests that SSL session caching already occurs by default in server mode:

?SSL_SESS_CACHE_SERVER

    Server sessions are added to the session cache. When a client proposes a session to be reused, the server looks for the corresponding session in (first) the internal session cache (unless SSL_SESS_CACHE_NO_INTERNAL_LOOKUP is set), then (second) in the external cache if available. If the session is found, the server will try to reuse the session. This is the default.?


A nice and easy thing to do would be to export the statistics given by http://www.openssl.org/docs/ssl/SSL_CTX_sess_number.html# .

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8106>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:17:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 12 Oct 2010 17:17:04 +0000
Subject: [issue10066] xmlrpclib does not handle some non-printable characters
	properly
In-Reply-To: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>
Message-ID: <1286903824.26.0.894978642089.issue10066@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch is incorrect. Even though this may let get these characters "through", the other end will have no clue that \x is meant as an escape.

Please face the ugly truth: XML (and hence XML-RPC) just does not support these characters, see http://www.w3.org/TR/REC-xml/#NT-Char

This is fixed slightly in XML 1.1 (which allows to refer to these characters by character reference), however, XML 1.1 is not used for XML-RPC, so this is not an option.

I'm closing this as "won't fix". If there is interest in doing something about it, I could accept a patch that rejects non-Char characters with an exception, instead of sending ill-formed XML. I'd recommend to use a regular expression for that.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10066>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:17:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 17:17:12 +0000
Subject: [issue10067] itertools' docs put izip_longest in the "terminating on
	the shortest input sequence" section
In-Reply-To: <1286875214.59.0.114835470036.issue10067@psf.upfronthosting.co.za>
Message-ID: <1286903832.34.0.000694803826031.issue10067@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +rhettinger
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10067>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:17:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 17:17:19 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286903839.51.0.178054049262.issue10063@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I'd say disable hostnames in file:// URIs altogether. There's no practical reason for forcing a hostname in there, and trying to check that it matches the local host's FQDN sounds like a distraction.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:17:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 17:17:33 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286903853.31.0.105918708657.issue10063@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(by disable I meant disallow, sorry)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:23:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Oct 2010 17:23:26 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286904206.64.0.307761386147.issue10063@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

?ric: Well....I suppose that depends on how you look at it.

The RFC says that 'file:' does not specify a network protocol, and so "it's utility in network protocols between hosts is limited".  So, technically an implementation that decides to handle 'file://<fqdn>' by using ftp isn't *wrong*, but it certainly isn't something that someone writing a 'file:' uri should expect to work.

I agree with Senthil, I am -1 on backporting this to earlier versions because of the potential for breaking "working" applications (even though those applications shouldn't really be working :)

Antoine: except that the RFC allows FQDNs in 'file:' URIs.  So I don't think we can just reject them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:24:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 12 Oct 2010 17:24:02 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286902919.1.0.34878084256.issue10070@psf.upfronthosting.co.za>
Message-ID: <4CB499AE.4010304@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> How about this phrasing: ?Make 2to3 fixers not touch code in a block
> starting with ?if sys.version >= '3'?? (and hexversion, version_info,
> you get the idea)?

I don't think this can work. You may have to write code like

if sys.version_info >= (3,):
  try:
    some_code()
  except Exception, e:
    pass

(i.e. not use the "as" syntax), because it otherwise won't parse on
Python 2. Hence, one has to rely on 2to3 fixing it, even though
it will never be run on Python 2.

So any scheme of skipping code must be opt-in.

While I now understand what is being requested, I still fail to see
the rationale. In my applications of 2to3, I never look at the generated
code, so it doesn't bother me at all if print gets another pairs of
brackets, or if redundant (but dead) import statements are inserted.

In fact, I also avoid writing code explicitly so that it works
unmodified on Python 3 if I know that 2to3 will fix it.

There has been a long-standing request to suppress 2to3 in certain
expressions in cases where the 2to3 conversion would actually be
incorrect. However, this does not seem to be the motivation here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:29:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Oct 2010 17:29:27 +0000
Subject: =?utf-8?q?=5Bissue10039=5D_python_=C3=A9=2Epy_fails_with_UnicodeEncodeErr?=
	=?utf-8?q?or_if_PYTHONFSENCODING_is_used?=
In-Reply-To: <1286414733.34.0.0267403088134.issue10039@psf.upfronthosting.co.za>
Message-ID: <1286904567.7.0.176908717503.issue10039@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

?ric, if you are saying, "the user asked for it, it *should* fail", then that is indeed one of the arguments put forward in issue 9992 where this was discussed.  But I think the emerging consensus is that it is better to just avoid the problem by always using the locale on Unix, and solve the problem that PYTHONFSENCODING was supposed to solve in a different way (by always using utf-8 on OSX and unicode on Windows).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10039>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:39:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 17:39:47 +0000
Subject: =?utf-8?q?=5Bissue10039=5D_python_=C3=A9=2Epy_fails_with_UnicodeEncodeErr?=
	=?utf-8?q?or_if_PYTHONFSENCODING_is_used?=
In-Reply-To: <1286414733.34.0.0267403088134.issue10039@psf.upfronthosting.co.za>
Message-ID: <1286905187.25.0.0222983594214.issue10039@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> if you are saying, "the user asked for it, it *should* fail", then
> that is indeed one of the arguments put forward in issue 9992 where
> this was discussed.
You could put it that way, thanks for phrasing my thoughts :)

> But I think the emerging consensus is that it is better to just avoid
> the problem by always using the locale on Unix,
*displays his lack of knowledge* Is it always correct to decode a filename with the locale encoding on Unix?  Can?t each filesystem have its own encoding?

> and solve the problem that PYTHONFSENCODING was supposed to solve in a
> different way (by always using utf-8 on OSX and unicode on Windows).
If there is a better alternate way, let?s go for it, and maybe remove PYTHONFSENCODING altogether, since it?s new in 3.2.

Thanks for explaining!  I?ll repay your time by reviewing the doc patches.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10039>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:42:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 17:42:02 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286905322.86.0.511113759441.issue10063@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

With this explanation, I agree with Senthil?s plan too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:47:30 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Oct 2010 17:47:30 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1286905650.56.0.278594904956.issue10063@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I think the error message should be changed from 'allowed' to 'supported', though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:49:41 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 12 Oct 2010 17:49:41 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286905781.95.0.721520804393.issue10049@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

I'm with Antoine. Why not just do this in the context function itself?
I think it's more explicit and easier than reading the doc to figure out what nullcontext is supposed to do:


from contextlib import contextmanager

CONDITION = False

@contextmanager
def transaction():
    if not CONDITION:
        yield None
    else:
        yield ...

with transaction() as x:
    ...

----------
nosy: +giampaolo.rodola

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Tue Oct 12 19:55:56 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 12 Oct 2010 17:55:56 +0000
Subject: [issue10074] dictobject.c: crash in Py_XDECREF
In-Reply-To: <1286906156.68.0.829457870543.issue10074@psf.upfronthosting.co.za>
Message-ID: <1286906156.68.0.829457870543.issue10074@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

I noticed that Python 2.6.6 crashes on OSX 10.6 when using Komodo. The below traceback indicates a crash in line 911 - "Py_XDECREF(ep->me_value);" in tags/r266/Objects/dictobject.c

Thread 0:  Dispatch queue: com.apple.main-thread
0   org.activestate.ActivePython26	0x129a3716 dict_dealloc + 82 (dictobject.c:911)
1   org.activestate.ActivePython26	0x12976ed1 instance_dealloc + 437 (classobject.c:669)
2   org.activestate.ActivePython26	0x129a3752 dict_dealloc + 142 (dictobject.c:907)
3   org.activestate.ActivePython26	0x129bfcdd subtype_dealloc + 884 (typeobject.c:1004)
4   org.activestate.ActivePython26	0x12994f96 list_dealloc + 212 (listobject.c:306)
5   org.activestate.ActivePython26	0x129a2f81 insertdict + 122 (dictobject.c:459)
6   org.activestate.ActivePython26	0x129a33d9 PyDict_SetItem + 92 (dictobject.c:701)
7   org.activestate.ActivePython26	0x129a8f2e PyObject_GenericSetAttr + 262 (object.c:1504)
8   org.activestate.ActivePython26	0x129a7c2b PyObject_SetAttr + 135 (object.c:1252)
9   org.activestate.ActivePython26	0x12a08132 PyEval_EvalFrameEx + 8529 (ceval.c:1864)
10  org.activestate.ActivePython26	0x12a0bcaa PyEval_EvalFrameEx + 23753 (ceval.c:3836)
11  org.activestate.ActivePython26	0x12a0bcaa PyEval_EvalFrameEx + 23753 (ceval.c:3836)
12  org.activestate.ActivePython26	0x12a0cbca PyEval_EvalCodeEx + 1973 (ceval.c:3000)
13  org.activestate.ActivePython26	0x12990d81 function_call + 162 (funcobject.c:524)
14  org.activestate.ActivePython26	0x12963b46 PyObject_Call + 77 (abstract.c:2492)
15  org.activestate.ActivePython26	0x12a08f3b PyEval_EvalFrameEx + 12122 (ceval.c:4063)
16  org.activestate.ActivePython26	0x12a0cbca PyEval_EvalCodeEx + 1973 (ceval.c:3000)
17  org.activestate.ActivePython26	0x12990d81 function_call + 162 (funcobject.c:524)
18  org.activestate.ActivePython26	0x12963b46 PyObject_Call + 77 (abstract.c:2492)
19  org.activestate.ActivePython26	0x12974615 instancemethod_call + 401 (classobject.c:2579)
20  org.activestate.ActivePython26	0x12963b46 PyObject_Call + 77 (abstract.c:2492)
21  org.activestate.ActivePython26	0x12968e47 PyObject_CallMethod + 154 (abstract.c:2524)
22  libpyxpcom.dylib              	0x0078cdde PyXPCOM_XPTStub::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) + 242

Even though the traceback is for ActivePython (that Komodo includes), this seems to happen with the official Python binaries as well: http://www.gossamer-threads.com/lists/python/python/844086

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh
messages: 118449
nosy: ronaldoussoren, srid
priority: normal
severity: normal
status: open
title: dictobject.c: crash in Py_XDECREF
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10074>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:03:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 12 Oct 2010 18:03:05 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286906585.11.0.360467518541.issue10049@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Because hardcoding a particular condition into a context manager is less flexible?  (I'm +0 on this thing myself, by the way.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:06:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 18:06:41 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1286906801.8.0.740732392813.issue9003@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file19189/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:14:04 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 12 Oct 2010 18:14:04 +0000
Subject: [issue10074] dictobject.c: crash in Py_XDECREF
In-Reply-To: <1286906156.68.0.829457870543.issue10074@psf.upfronthosting.co.za>
Message-ID: <1286907244.52.0.0693973207275.issue10074@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

It is not impossible that this is a bug in python, but IMHO pretty unlikely, it is way more likely to be a bug in a 3th-party extension.

BTW. This issue is very likely to languish unless you add a way to reproduce the issue (and preferably without Komodo).

If you do have a reliable way to reproduce the issue you could try using a debug build of python (--with-pydebug) to gather more information.

----------
assignee: ronaldoussoren -> nobody
nosy: +nobody

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10074>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:17:08 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Oct 2010 18:17:08 +0000
Subject: [issue10067] itertools' docs put izip_longest in the "terminating on
	the shortest input sequence" section
In-Reply-To: <1286875214.59.0.114835470036.issue10067@psf.upfronthosting.co.za>
Message-ID: <1286907428.45.0.946924635877.issue10067@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I saw that when I put in in. 
It doesn't fit the overall category
but it does belong in the same general
grouping and the notes make the semantics clear,
so there is no harm in it and I like the current
presentation better than the alternatives.

----------
resolution:  -> wont fix

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10067>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:17:43 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Oct 2010 18:17:43 +0000
Subject: [issue10067] itertools' docs put izip_longest in the "terminating on
	the shortest input sequence" section
In-Reply-To: <1286875214.59.0.114835470036.issue10067@psf.upfronthosting.co.za>
Message-ID: <1286907463.67.0.236095255625.issue10067@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/issue10067>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:24:31 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Oct 2010 18:24:31 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1286907871.3.0.555577692141.issue10049@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Are you sure that this is useful enough to warrant inclusion in the standard lib?  I don't know of anyone else who has used the same idiom.  It seems crufty to me -- something that adds weight (mental burden and maintenance effort) without adding much value. I don't know that anyone actually needs this.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:26:24 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Tue, 12 Oct 2010 18:26:24 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286882661.81.0.431457664283.issue10070@psf.upfronthosting.co.za>
Message-ID: <1286907984.94.0.191943692254.issue10070@psf.upfronthosting.co.za>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

[I got failed issue tracker submission, trying again...]

>> How about this phrasing: ?Make 2to3 fixers not touch code in a
>> block starting with ?if sys.version >= '3'??
>> (and hexversion, version_info, you get the idea)?

Right, almost... it doesn't need to be flexible, it only needs to be
documented for 2to3.  So it also doesn't need to handle the varions
version variables - if e.g. version_info is easiest for 2to3, it need
only handle that.  I've been posting with routine avoidance of testing
versions instead of features (learned from javascript frustration:-)
but that concern was misplaced here.

But it should be "if sys.version {either < or >=} '3':", and it should
not touch the else: block either.  Just trust that the programmer has
written correct version's code for each block, and parse one of the
blocks to pick up whatever info 2to3 needs to process the rest of the
python file.

So...

> I don't think this can work. You may have to write code like
> 
> if sys.version_info >= (3,):
>   try:
>     some_code()
>   except Exception, e:
>     pass
> 
> (i.e. not use the "as" syntax), because it otherwise won't parse on
> Python 2. Hence, one has to rely on 2to3 fixing it, even though
> it will never be run on Python 2.

I assume it should be "if sys.version_info < (3,):" since that looks
like Python 2 code, and that'll work with the above revised suggestion.

> So any scheme of skipping code must be opt-in.

Fair enough, if it's a 2to3 option which to obey whatever "skip some
code" hack is defined.  That's the same 2to3 command line for a lot of
files, instead of different commmand lines for different files.

Unless we're still talking past each other - if the example code will
never run on Python 2 as you say, there's no reason not to fix syntax
problems like the above.  It's fixing things like bytes vs str which
takes more thought.

> While I now understand what is being requested, I still fail to see
> the rationale. In my applications of 2to3, I never look at the generated
> code, so it doesn't bother me at all if print gets another pairs of
> brackets, or if redundant (but dead) import statements are inserted.

Wow.  We live in different mental worlds.  It would not have occurred
to me to take the 2to3 output as more than helpful suggestions.  Some
to be applied straight (like 'except' syntax), other to maybe apply
but also look closer at nearby code.

Indeed, one of my early 2to3 experiences led to a bug in python 3 code
which I'm now discussing in comp.lang.python.  Also 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.

-- 
Hallvard

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:47:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 18:47:04 +0000
Subject: [issue10075] Get session cache stats from SSLContext
In-Reply-To: <1286909224.78.0.82870617442.issue10075@psf.upfronthosting.co.za>
Message-ID: <1286909224.78.0.82870617442.issue10075@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch adds a method to query the session cache statistics from an SSL context. See http://www.openssl.org/docs/ssl/SSL_CTX_set_session_cache_mode.html# for more info.

----------
components: Library (Lib)
files: sslstats.patch
keywords: patch
messages: 118455
nosy: giampaolo.rodola, janssen, jcea, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Get session cache stats from SSLContext
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19199/sslstats.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10075>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:49:52 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 12 Oct 2010 18:49:52 +0000
Subject: [issue10074] dictobject.c: crash in Py_XDECREF
In-Reply-To: <1286906156.68.0.829457870543.issue10074@psf.upfronthosting.co.za>
Message-ID: <1286909392.28.0.28012684527.issue10074@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

And what is libpyxpcom.dylib?  As Ronald says, this is almost certainly a 3rd-party extension module problem.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10074>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:53:29 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Tue, 12 Oct 2010 18:53:29 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1286909609.39.0.276531416256.issue7523@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Made an attempt to port lekma's patch to py3k-trunk. No (logical) changes needed.

Don't know about accept4() issue. As I saw in Qt sources, they ifdef'ed CLOEXEC by default on file descriptors. Don't think it's acceptable :) in this particular case. So, @Antoine, what do you say?

----------
nosy: +nvetoshkin
Added file: http://bugs.python.org/file19200/issue7523_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:53:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 12 Oct 2010 18:53:57 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1286909637.01.0.378960242118.issue10073@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would also like to note the following curiosity:

>>> calendar.isleap("%d")
False

I still don't think there is anything worth fixing here, but we can consider replacing year % 4 == 0 predicate with year & 3 == 0 which will change the error raised by isleap("2004") from

TypeError: not all arguments converted during string formatting

to 

TypeError: unsupported operand type(s) for &: 'str' and 'int'

I am not sure if the later is much clearer than the former once you consider obfuscated year & 3 == 0 showing up in the backtrace compared to a clear year % 4 == 0 test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:55:24 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Tue, 12 Oct 2010 18:55:24 +0000
Subject: [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1286909724.95.0.458613578145.issue10072@psf.upfronthosting.co.za>


Rafe Kettler <rafe.kettler at gmail.com> added the comment:

I've drafted up a patch. For those of you who don't want to read the diff, it changes all references to FTP reply codes with short explanations of what they do. Also, in the docs for retrlines() and nlst() the commands LIST, NLST, and MLSD are explained.

Attached is the patch.

----------
Added file: http://bugs.python.org/file19201/ftplib-patch.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10072>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:55:42 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Tue, 12 Oct 2010 18:55:42 +0000
Subject: [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1286909742.07.0.538246081291.issue10072@psf.upfronthosting.co.za>


Changes by Rafe Kettler <rafe.kettler at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19202/ftplib-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10072>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:56:14 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Tue, 12 Oct 2010 18:56:14 +0000
Subject: [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1286909774.31.0.206313318587.issue10072@psf.upfronthosting.co.za>


Changes by Rafe Kettler <rafe.kettler at gmail.com>:


Removed file: http://bugs.python.org/file19201/ftplib-patch.rst

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10072>
_______________________________________

From report at bugs.python.org  Tue Oct 12 20:57:00 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Tue, 12 Oct 2010 18:57:00 +0000
Subject: [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1286909820.29.0.450024729983.issue10072@psf.upfronthosting.co.za>


Changes by Rafe Kettler <rafe.kettler at gmail.com>:


Added file: http://bugs.python.org/file19203/ftplib-patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10072>
_______________________________________

From report at bugs.python.org  Tue Oct 12 21:10:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 19:10:49 +0000
Subject: [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1286910649.96.0.969171403855.issue10072@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good to me.  Before committing, spaces after full stops should be doubled.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10072>
_______________________________________

From report at bugs.python.org  Tue Oct 12 21:13:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 12 Oct 2010 19:13:10 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1286910790.87.0.0803823227449.issue10073@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d be in favor of type checking here, but I know I?m in the minority.  I?m very much not in favor of making code less readable (?& 3?).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 12 21:22:43 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Tue, 12 Oct 2010 19:22:43 +0000
Subject: [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1286911363.87.0.22221241966.issue10072@psf.upfronthosting.co.za>


Changes by Rafe Kettler <rafe.kettler at gmail.com>:


Removed file: http://bugs.python.org/file19203/ftplib-patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10072>
_______________________________________

From report at bugs.python.org  Tue Oct 12 21:23:10 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Tue, 12 Oct 2010 19:23:10 +0000
Subject: [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1286911390.9.0.937296258938.issue10072@psf.upfronthosting.co.za>


Rafe Kettler <rafe.kettler at gmail.com> added the comment:

Double spaced after the sentence ending periods.

----------
Added file: http://bugs.python.org/file19204/ftplib-patch.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10072>
_______________________________________

From report at bugs.python.org  Tue Oct 12 21:29:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 19:29:48 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1286911788.34.0.383080444965.issue7523@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The accept() issue is the following: the socket created by accept() (in Lib/socket.py) will formally inherit its parent's `type` attribute (including any SOCK_NONBLOCK and SOCK_CLOEXEC flags).

However, the underlying Linux socket is created by the accept() system call, which doesn't inherit flags as mentioned in the aforementioned man page. Therefore, the Python socket gives the wrong information about the socket's real flags.

This can be witnessed quickly:

>>> s = socket.socket(socket.AF_INET, socket.SOCK_STREAM | socket.SOCK_CLOEXEC)
>>> s.bind(("", 0))
>>> s.getsockname()
('0.0.0.0', 34634)
>>> s.listen(5)
>>> c, a = s.accept()
   # Here, just start a "telnet" or "nc" session from another term
>>> import fcntl
>>> fcntl.fcntl(s, fcntl.F_GETFD)
1
>>> fcntl.fcntl(c, fcntl.F_GETFD)
0
>>> fcntl.fcntl(c, fcntl.F_GETFD) & fcntl.FD_CLOEXEC
0
>>> c.type & socket.SOCK_CLOEXEC
524288


The quick solution would be to mask out these flags when creating the Python socket in accept(). A better solution might be to inherit these flags by using the accept4() system call when possible (this is useful especially for SOCK_CLOEXEC, of course).


Apart from that, the patch looks ok, but it would be nice to test that at least the underlying socket is really in non-blocking mode, like is done in NonBlockingTCPTests.testSetBlocking.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Tue Oct 12 21:47:33 2010
From: report at bugs.python.org (shadikka)
Date: Tue, 12 Oct 2010 19:47:33 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1286912853.41.0.533021948232.issue10073@psf.upfronthosting.co.za>


shadikka <shadikka at gmail.com> added the comment:

To clarify my original point, I'm for making an explicit error message for that, definitely not for any silent failure or automatic string conversion.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 12 22:09:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 20:09:42 +0000
Subject: [issue10075] Get session cache stats from SSLContext
In-Reply-To: <1286909224.78.0.82870617442.issue10075@psf.upfronthosting.co.za>
Message-ID: <1286914182.03.0.967053214211.issue10075@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've renamed the method to session_stats() and commited the patch in r85383.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10075>
_______________________________________

From report at bugs.python.org  Tue Oct 12 22:16:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 20:16:52 +0000
Subject: [issue10075] Get session cache stats from SSLContext
In-Reply-To: <1286909224.78.0.82870617442.issue10075@psf.upfronthosting.co.za>
Message-ID: <1286914612.44.0.959353984287.issue10075@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10075>
_______________________________________

From report at bugs.python.org  Tue Oct 12 22:22:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 20:22:21 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286914941.67.0.214014145552.issue10041@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The proposed test case doesn't test a lot, IMHO. It would be better if it sent binary from one end and received unicode on the other end, or vice-versa (with explicit encoding and errors, preferably).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Tue Oct 12 22:29:07 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Tue, 12 Oct 2010 20:29:07 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1286915347.34.0.386303987393.issue10073@psf.upfronthosting.co.za>


Philip Jenvey <pjenvey at underboss.org> added the comment:

Another option is to wrap the operations in a try/except. When a TypeError is raised have it throw a new TypeError with an improved error message and the original chained to it

----------
nosy: +pjenvey

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 12 22:29:58 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 12 Oct 2010 20:29:58 +0000
Subject: [issue10070] 2to3 wishes for already-2to3'ed files
In-Reply-To: <1286907984.94.0.191943692254.issue10070@psf.upfronthosting.co.za>
Message-ID: <4CB4C543.80102@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> I don't think this can work. You may have to write code like
>>
>> if sys.version_info >= (3,):
>>   try:
>>     some_code()
>>   except Exception, e:
>>     pass
>>
>> (i.e. not use the "as" syntax), because it otherwise won't parse on
>> Python 2. Hence, one has to rely on 2to3 fixing it, even though
>> it will never be run on Python 2.
> 
> I assume it should be "if sys.version_info < (3,):" since that looks
> like Python 2 code, and that'll work with the above revised suggestion.

No, I meant this as stated. Suppose you would write (as you apparently
expected me to)

if sys.version_info >= (3,):
   try:
     some_code()
   except Exception as e:
     pass

then the entire module (and not just this if-block) will fail to import
in Python 2. Therefore, you must not use syntax that is exclusively
Python 3 in an if-python3 block if you want to continue to use the code
in Python 2 (and if you don't want to use the code in Python 2, you
don't need the if block).

Then you run the code (as I originally posted) through 2to3, and out
you get the block that will then get executed in Python 3.
Therefore, it is necessary to convert the code that is meant for
Python 3 with 2to3 still.

>> While I now understand what is being requested, I still fail to see
>> the rationale. In my applications of 2to3, I never look at the generated
>> code, so it doesn't bother me at all if print gets another pairs of
>> brackets, or if redundant (but dead) import statements are inserted.
> 
> Wow.  We live in different mental worlds.  It would not have occurred
> to me to take the 2to3 output as more than helpful suggestions.  Some
> to be applied straight (like 'except' syntax), other to maybe apply
> but also look closer at nearby code.

So please reconsider. Using that approach will allow you to have a
single source code for Python 2 and Python 3. You write it so that
it works fine on Python 2, and let 2to3 generate the Python 3 version,
which you then run unmodified. For that to work, it's important that
any modifications that 2to3 won't do will be done *before* invoking
2to3, and these modifications must therefore then work with Python 2
as well (albeit possibly in a block that is never executed on Python 2).

If, at some point, you are then ready to burn the bridges (i.e. give
up Python 2 support), you run 2to3 once, and start removing all
ugliness that you had collected during the transition phase.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10070>
_______________________________________

From report at bugs.python.org  Tue Oct 12 22:45:24 2010
From: report at bugs.python.org (Michael Shields)
Date: Tue, 12 Oct 2010 20:45:24 +0000
Subject: [issue10076] Regex objects became uncopyable in 2.5
In-Reply-To: <1286916324.24.0.772801528988.issue10076@psf.upfronthosting.co.za>
Message-ID: <1286916324.24.0.772801528988.issue10076@psf.upfronthosting.co.za>


New submission from Michael Shields <mshields at google.com>:

For many years now, the sre module has provided __copy__ and __deepcopy__ modules that raise an exception ("cannot copy this pattern object") by default, with an #ifdef to enable their implementations.  Until Python 2.5, these were simply unused.  Since then, deepcopying these objects fails, instead of falling back to the default implementation.

Python 2.4.6 (#1, Nov 23 2009, 03:28:22)
[GCC 4.2.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> x = [re.compile('.*')]
>>> import copy
>>> copy.deepcopy(x)
[<_sre.SRE_Pattern object at 0x7f3e9411e168>]

Python 2.6.2 (r262:71600, Jul 24 2009, 17:29:21)
[GCC 4.2.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import re
>>> x = [re.compile('.*')]
>>> import copy
>>> copy.deepcopy(x)
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "/usr/grte/v1/k8-linux/lib/python2.6/copy.py", line 162, in deepcopy
   y = copier(x, memo)
 File "/usr/grte/v1/k8-linux/lib/python2.6/copy.py", line 228, in _deepcopy_list
   y.append(deepcopy(a, memo))
 File "/usr/grte/v1/k8-linux/lib/python2.6/copy.py", line 173, in deepcopy
   y = copier(memo)
TypeError: cannot deepcopy this pattern object

I'll attach a patch against 2.7 to correct this.

----------
components: Library (Lib)
messages: 118469
nosy: Michael.Shields
priority: normal
severity: normal
status: open
title: Regex objects became uncopyable in 2.5
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10076>
_______________________________________

From report at bugs.python.org  Tue Oct 12 22:48:49 2010
From: report at bugs.python.org (Michael Shields)
Date: Tue, 12 Oct 2010 20:48:49 +0000
Subject: [issue10076] Regex objects became uncopyable in 2.5
In-Reply-To: <1286916324.24.0.772801528988.issue10076@psf.upfronthosting.co.za>
Message-ID: <1286916529.35.0.0775616902283.issue10076@psf.upfronthosting.co.za>


Michael Shields <mshields at google.com> added the comment:

Here's the patch.  I updated the test case and release notes also.

I'm a Google employee, so this patch is covered by whatever usual copyright arrangement we have with the PSF.

----------
keywords: +patch
Added file: http://bugs.python.org/file19205/copy-pattern.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10076>
_______________________________________

From report at bugs.python.org  Tue Oct 12 22:49:14 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Tue, 12 Oct 2010 20:49:14 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1286916554.53.0.857842921194.issue7523@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Thanks! I can see the problem now, but I think checking should be done like this:
>>> fcntl.fcntl(c, fcntl.F_GETFD) & fcntl.FD_CLOEXEC
0
>>> fcntl.fcntl(s, fcntl.F_GETFD) & fcntl.FD_CLOEXEC
1
and with accept4() call I've got flag set:
>>> fcntl.fcntl(c, fcntl.F_GETFD) & fcntl.FD_CLOEXEC
1
>>> fcntl.fcntl(s, fcntl.F_GETFD) & fcntl.FD_CLOEXEC
1

Don't know how to properly check if accept4 is available.

Second attempt - dropping flags from sock_type should be done on Python level in socket.py and I don't quite like idea to check if SOCK_CLOEXEC is in locals every time.

----------
Added file: http://bugs.python.org/file19206/issue7523_py3k_accept4.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Tue Oct 12 22:52:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 20:52:04 +0000
Subject: [issue3873] Unpickling is really slow
In-Reply-To: <1221496652.57.0.686468497967.issue3873@psf.upfronthosting.co.za>
Message-ID: <1286916724.48.0.175046347018.issue3873@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r85384.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3873>
_______________________________________

From report at bugs.python.org  Tue Oct 12 23:03:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 21:03:38 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1286917418.07.0.907180981236.issue7523@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can check accept4() presence by adding it to the AC_CHECK_FUNCS macro in configure.in around line 2553, and add the corresponding HAVE_ACCEPT4 lines in pyconfig.h.in. Then run "autoconf" and you will have access to a HAVE_ACCEPT4 constant when accept4() exists.

By the way, you shouldn't use C++-style comments ("// ..."), because some C compilers refuse them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Tue Oct 12 23:16:42 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Oct 2010 21:16:42 +0000
Subject: [issue10068] global objects created in some module are not destroyed
	when last reference to that module is released
In-Reply-To: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>
Message-ID: <1286918202.44.0.519115682349.issue10068@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Tricky. I think the only way to do this properly is to call _PyModule_Clear when the dict is destroyed. However, there's no good way to flag a dictionary as a "module" dict. Therefore, I propose we remove the Py_REFCNT == 1 guard in module_dealloc, and simply leave as an open bug that modules will clear their dictionaries on deallocation. Thoughts?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10068>
_______________________________________

From report at bugs.python.org  Tue Oct 12 23:19:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Oct 2010 21:19:39 +0000
Subject: [issue10068] global objects created in some module are not destroyed
	when last reference to that module is released
In-Reply-To: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>
Message-ID: <1286918379.22.0.492162780746.issue10068@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Therefore, I propose we remove the Py_REFCNT == 1 guard in
> module_dealloc, and simply leave as an open bug that modules will clear 
> their dictionaries on deallocation.

Yes, I think it's the best solution. People can easily copy the dict if they want to keep it around after the module gets destroyed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10068>
_______________________________________

From report at bugs.python.org  Wed Oct 13 00:07:09 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 12 Oct 2010 22:07:09 +0000
Subject: [issue10074] dictobject.c: crash in Py_XDECREF
In-Reply-To: <1286909392.28.0.28012684527.issue10074@psf.upfronthosting.co.za>
Message-ID: <7FED3B63-64BC-4A2F-B157-CFB4182A5807@activestate.com>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

On 2010-10-12, at 11:49 AM, Ned Deily wrote:

> And what is libpyxpcom.dylib?  

Likely PyXPCOM
https://developer.mozilla.org/en/PyXPCOM

> As Ronald says, this is almost certainly a 3rd-party extension module problem.

Ok, I've made a note for Todd (current developer for PyXPCOM) here,
http://bugs.activestate.com/show_bug.cgi?id=88165#c5

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10074>
_______________________________________

From report at bugs.python.org  Wed Oct 13 00:07:44 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Tue, 12 Oct 2010 22:07:44 +0000
Subject: [issue10074] dictobject.c: crash in Py_XDECREF
In-Reply-To: <1286906156.68.0.829457870543.issue10074@psf.upfronthosting.co.za>
Message-ID: <1286921264.31.0.780848108298.issue10074@psf.upfronthosting.co.za>


Changes by Sridhar Ratnakumar <sridharr at activestate.com>:


----------
nosy: +toddw

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10074>
_______________________________________

From report at bugs.python.org  Wed Oct 13 00:28:19 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Oct 2010 22:28:19 +0000
Subject: [issue10069] 2to3 crash in fix_urllib.py
In-Reply-To: <1286882208.41.0.35723041656.issue10069@psf.upfronthosting.co.za>
Message-ID: <1286922499.14.0.181329408476.issue10069@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85388.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10069>
_______________________________________

From report at bugs.python.org  Wed Oct 13 00:47:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Oct 2010 22:47:59 +0000
Subject: [issue10077] Python 3.1: site error is not logged
In-Reply-To: <1286923679.0.0.360055889779.issue10077@psf.upfronthosting.co.za>
Message-ID: <1286923679.0.0.360055889779.issue10077@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

If the site module fails, the error is not logged because of a bug in initsite(). The problem is that PyFile_WriteString() does nothing if an error occurred.

 - Edit Lib/site.py to add "raise Exception('xxx')" at the beginning of main()
 - Run ./python
 - (no error is logged)

In verbose mode, only the exception is logged, without the first line:

  'import site' failed; traceback:

Attached patch fixes both issues.

--

This issue is specific to Python 3.1:
 - Python 2.7 and 3.2 consider site error as a fatal error 
 - Python 2.6 doesn't have the bug because PyFile_WriteString() write the message even if an error occurred

----------
components: Library (Lib)
files: site_error.patch
keywords: patch
messages: 118478
nosy: haypo
priority: normal
severity: normal
status: open
title: Python 3.1: site error is not logged
versions: Python 3.1
Added file: http://bugs.python.org/file19207/site_error.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10077>
_______________________________________

From report at bugs.python.org  Wed Oct 13 00:57:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Oct 2010 22:57:29 +0000
Subject: [issue6612] 'import site' fails when called from an unlinked directory
In-Reply-To: <1249034007.06.0.695800326888.issue6612@psf.upfronthosting.co.za>
Message-ID: <1286924249.03.0.700809195555.issue6612@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed in 3.2 (r85386+r85387+r85389), 2.7 (r85390), 3.1 (r85391).

Thanks labrat for your patch. I added you to Misc/ACKS.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6612>
_______________________________________

From report at bugs.python.org  Wed Oct 13 00:58:23 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Oct 2010 22:58:23 +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: <1286924303.97.0.527540742179.issue7140@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Rebroken in r85392. See #10068.

----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7140>
_______________________________________

From report at bugs.python.org  Wed Oct 13 00:58:29 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Oct 2010 22:58:29 +0000
Subject: [issue10068] global objects created in some module are not destroyed
	when last reference to that module is released
In-Reply-To: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>
Message-ID: <1286924309.37.0.790476863963.issue10068@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85392.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10068>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:05:35 2010
From: report at bugs.python.org (Retro)
Date: Tue, 12 Oct 2010 23:05:35 +0000
Subject: [issue10078] Documentation: 'Postive' should be 'Positive'
In-Reply-To: <1286924735.29.0.0342537376676.issue10078@psf.upfronthosting.co.za>
Message-ID: <1286924735.29.0.0342537376676.issue10078@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

There's a typo in the docs. Please follow http://docs.python.org/py3k/library/string.html#format-specification-mini-language and find the below text, and fix the word 'Postive' to 'Positive', indicated between >>> and <<<:

'g'	
General format. For a given precision p >= 1, this rounds the number to p significant digits and then formats the result in either fixed-point format or in scientific notation, depending on its magnitude.

The precise rules are as follows: suppose that the result formatted with presentation type 'e' and precision p-1 would have exponent exp. Then if -4 <= exp < p, the number is formatted with presentation type 'f' and precision p-1-exp. Otherwise, the number is formatted with presentation type 'e' and precision p-1. In both cases insignificant trailing zeros are removed from the significand, and the decimal point is also removed if there are no remaining digits following it.

>>>Postive<<< and negative infinity, positive and negative zero, and nans, are formatted as inf, -inf, 0, -0 and nan respectively, regardless of the precision.

A precision of 0 is treated as equivalent to a precision of 1.

----------
assignee: docs at python
components: Documentation
messages: 118482
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Documentation: 'Postive' should be 'Positive'
versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10078>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:07:39 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Oct 2010 23:07:39 +0000
Subject: [issue10078] Documentation: 'Postive' should be 'Positive'
In-Reply-To: <1286924735.29.0.0342537376676.issue10078@psf.upfronthosting.co.za>
Message-ID: <1286924859.68.0.817487802966.issue10078@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85395.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10078>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:08:08 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Oct 2010 23:08:08 +0000
Subject: [issue10074] dictobject.c: crash in Py_XDECREF
In-Reply-To: <1286906156.68.0.829457870543.issue10074@psf.upfronthosting.co.za>
Message-ID: <1286924888.75.0.472547718881.issue10074@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/issue10074>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:19:09 2010
From: report at bugs.python.org (Retro)
Date: Tue, 12 Oct 2010 23:19:09 +0000
Subject: [issue10078] Documentation: 'Postive' should be 'Positive'
In-Reply-To: <1286924735.29.0.0342537376676.issue10078@psf.upfronthosting.co.za>
Message-ID: <1286925549.79.0.0217778110848.issue10078@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

Please commit this fix to the trunk, as well as to the Python 2.5, Python 2.6, and Python 2.7 branches. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10078>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:19:33 2010
From: report at bugs.python.org (Retro)
Date: Tue, 12 Oct 2010 23:19:33 +0000
Subject: [issue10078] Documentation: 'Postive' should be 'Positive'
In-Reply-To: <1286924735.29.0.0342537376676.issue10078@psf.upfronthosting.co.za>
Message-ID: <1286925573.59.0.702089798837.issue10078@psf.upfronthosting.co.za>


Changes by Retro <vinetouu at gmail.com>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10078>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:19:49 2010
From: report at bugs.python.org (Retro)
Date: Tue, 12 Oct 2010 23:19:49 +0000
Subject: [issue10078] Documentation: 'Postive' should be 'Positive'
In-Reply-To: <1286924735.29.0.0342537376676.issue10078@psf.upfronthosting.co.za>
Message-ID: <1286925589.49.0.463175054808.issue10078@psf.upfronthosting.co.za>


Changes by Retro <vinetouu at gmail.com>:


----------
resolution: fixed -> remind

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10078>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:21:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 12 Oct 2010 23:21:48 +0000
Subject: [issue10078] Documentation: 'Postive' should be 'Positive'
In-Reply-To: <1286924735.29.0.0342537376676.issue10078@psf.upfronthosting.co.za>
Message-ID: <1286925708.2.0.901806614168.issue10078@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Done for all branches that are maintained.

----------
resolution: remind -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10078>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:41:42 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Oct 2010 23:41:42 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286926902.27.0.209283522897.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

New version of the patch:
 - use more standard function names (_Py_initsegfault => _Py_InitSegfault)
 - use "#ifdef HAVE_SIGACTION" to support system without sigaction(): fallback to signal()
 - usage of the alternative stack is now optional (#ifdef HAVE_SIGALTSTACK)
 - don't call _PyUnicode_AsString() (encode unicode to utf-8) because it allocates memory and it does complex operation which may fail: implement a new simple function to write a unicode string to a FILE* object with ascii+backslashreplace
 - display the function name in the backtrace (but don't display function depth)
 - _Py_FiniSegfault(): restore the old signal handlers before freeing the alternative stack memory (and not the opposite)

I only tested the patch on Linux with a narrow build. It should be tested at least on a wide build and on Windows.

I tested my patch on all Lib/test/crashers/*.py: all segfaults are replaced by nice Python tracebacks.

If you debug a Python program in gdb, gdb stops at the first SIGSEGV (before calling the signal handler).

I didn't tested how the signal handler behaves if it raises a new fault (SIGFPE or SIGSEGV). It is supposes to stop immediatly.

In the worst case, my patch introduces an infinite loop and the program eats all CPU time (and consume maybe a lot of memory?) instead of exiting immediatly. Especially, segfault_handler() doesn't ensure that there is no loop in the frame linked list. A possible solution is to fix a limit of the maximum depth (eg. only display first 100 frames and finished with "...").

----------
Added file: http://bugs.python.org/file19208/segfault_handler-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:44:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Oct 2010 23:44:20 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286927060.06.0.295088330309.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated example:
----------------------------------------------
$ ./python Lib/test/crashers/recursive_call.py
Fatal Python error: segmentation fault

Traceback (most recent call first):
  File "Lib/test/crashers/recursive_call.py", line 12 in <lambda>
  File "Lib/test/crashers/recursive_call.py", line 12 in <lambda>
  File "Lib/test/crashers/recursive_call.py", line 12 in <lambda>
...
  File "Lib/test/crashers/recursive_call.py", line 12 in <lambda>
  File "Lib/test/crashers/recursive_call.py", line 12 in <lambda>
  File "Lib/test/crashers/recursive_call.py", line 15 in <module>
Segmentation fault
----------------------------------------------

SIGSEGV catched in gdb:
----------------------------------------------
$ gdb -args ./python Lib/test/crashers/recursive_call.py 
...
(gdb) run
Starting program: /home/SHARE/SVN/py3k/python Lib/test/crashers/recursive_call.py

Program received signal SIGSEGV, Segmentation fault.
0x080614e1 in _PyObject_DebugMalloc (nbytes=24) at Objects/obmalloc.c:1398
1398        return _PyObject_DebugMallocApi(_PYMALLOC_OBJ_ID, nbytes);
(gdb)
----------------------------------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:46:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Oct 2010 23:46:16 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286927176.99.0.62571793387.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:46:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Oct 2010 23:46:20 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286927180.77.0.480514303587.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17507/segfault_handler.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:46:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Oct 2010 23:46:25 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286927185.22.0.878223190916.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file17717/segfault_handler-2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:53:22 2010
From: report at bugs.python.org (kai zhu)
Date: Tue, 12 Oct 2010 23:53:22 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286927602.72.0.235410785471.issue10041@psf.upfronthosting.co.za>


kai zhu <kaizhu256 at gmail.com> added the comment:

done ;p
added separate unicode read, write, and readwrite test cases (which all pass)

keep in mind my issue is specific to truncation of carriage return (imo a  priority for py3k migration).  i think this can b resolved by python 3.2

more general unicode issues should b raised in separate bug reports.

----------
Added file: http://bugs.python.org/file19209/socket.makefile.with.unittest.v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Wed Oct 13 01:55:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 12 Oct 2010 23:55:29 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286927729.91.0.504561383905.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> It should be tested at least on a wide build and ...

Done: it works correctly for non-BMP characters in narrow and wide builds.

Eg. in wide build with U+10ffff character in the path:
---------------------
$ ./python bla.py 
Fatal Python error: segmentation fault

Traceback (most recent call first):
  File "/home/SHARE/SVN/py3k\U0010ffff/Lib/ctypes/__init__.py", line 486 in string_at
  File "bla.py", line 2 in <module>
Segmentation fault
Abandon
---------------------

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 02:09:25 2010
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 13 Oct 2010 00:09:25 +0000
Subject: [issue1503] test_xmlrpc is still flakey
In-Reply-To: <1196126599.89.0.0637627606597.issue1503@psf.upfronthosting.co.za>
Message-ID: <1286928565.09.0.894268638135.issue1503@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

The tests now pass, but the underlying issue hasn't been fixed!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1503>
_______________________________________

From report at bugs.python.org  Wed Oct 13 02:10:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 00:10:24 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286928624.15.0.866088132612.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 4:
 - Add segfault.c to pythoncore.vcproj
 - Remove #error "nope" (I used it for debug purpose)
 - Don't include <unistd.h> on Windows

This version works on Windows.

----------
Added file: http://bugs.python.org/file19210/segfault_handler-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 02:25:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 00:25:49 +0000
Subject: =?utf-8?q?=5Bissue10039=5D_python_=C3=A9=2Epy_fails_with_UnicodeEncodeErr?=
	=?utf-8?q?or_if_PYTHONFSENCODING_is_used?=
In-Reply-To: <1286414733.34.0.0267403088134.issue10039@psf.upfronthosting.co.za>
Message-ID: <1286929549.16.0.521717656075.issue10039@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Is it always correct to decode a filename with the locale encoding
> on Unix?

Do you know something better than the locale encoding? I don't.

> Can?t each filesystem have its own encoding?

Yes, but how do you get the encoding of each filesystem? I think that few or no application support such case without mojibake. Backup programs can use the "raw" (bytes) API of Python 3 to avoid all encoding issues.

--

As wrote R. David Murray, read issue #9992 if you would like to know more about this problem and the different proposed solutions. I voted for removal of PYTHONFSENCODING which fix most issues.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10039>
_______________________________________

From report at bugs.python.org  Wed Oct 13 02:35:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Oct 2010 00:35:07 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
In-Reply-To: <1286884651.82.0.158483399845.issue10071@psf.upfronthosting.co.za>
Message-ID: <1286930107.83.0.652058419234.issue10071@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Some of your submission appears to have gotten lost (I saw it via email).
Below is the patch you proposed. I haven't experienced this crash on my machines, but the solution seems fine to me.


# I sometimes experienced crash of test_changing_value(test_winreg)
# on release27-maint. It happens when 2 threads calls PyEnumValue and
# PySetValue simultaneously. And I could stop it by following patch.
# I'll attach the stack trace of crash.

Index: PC/_winreg.c
===================================================================
--- PC/_winreg.c        (revision 85344)
+++ PC/_winreg.c        (working copy)
@@ -1219,7 +1219,6 @@
    }

    while (1) {
-        Py_BEGIN_ALLOW_THREADS
        rc = RegEnumValue(hKey,
                  index,
                  retValueBuf,
@@ -1228,7 +1227,6 @@
                  &typ,
                  (BYTE *)retDataBuf,
                  &retDataSize);
-        Py_END_ALLOW_THREADS

        if (rc != ERROR_MORE_DATA)
            break;
@@ -1577,9 +1575,7 @@
        if (subKey == NULL)
            return NULL;
    }
-    Py_BEGIN_ALLOW_THREADS
    rc = RegSetValue(hKey, subKey, REG_SZ, str, len+1);
-    Py_END_ALLOW_THREADS
    if (rc != ERROR_SUCCESS)
        return PyErr_SetFromWindowsErrWithFunction(rc, "RegSetValue");
    Py_INCREF(Py_None);

----------
components: +Windows
nosy: +brian.curtin, stutzbach
stage:  -> patch review
type:  -> crash

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Wed Oct 13 02:36:59 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 00:36:59 +0000
Subject: [issue10068] global objects created in some module are not destroyed
	when last reference to that module is released
In-Reply-To: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>
Message-ID: <1286930219.46.0.504533667073.issue10068@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r85393 introduced a regression in test_runpy of Python 2.7.

----------
nosy: +haypo
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10068>
_______________________________________

From report at bugs.python.org  Wed Oct 13 02:55:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 00:55:22 +0000
Subject: [issue10068] global objects created in some module are not destroyed
	when last reference to that module is released
In-Reply-To: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>
Message-ID: <1286931322.36.0.526636643995.issue10068@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_runpy fails also on Python 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10068>
_______________________________________

From report at bugs.python.org  Wed Oct 13 03:05:26 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Oct 2010 01:05:26 +0000
Subject: [issue10068] global objects created in some module are not destroyed
	when last reference to that module is released
In-Reply-To: <1286878168.64.0.888099098753.issue10068@psf.upfronthosting.co.za>
Message-ID: <1286931926.74.0.586135064356.issue10068@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85398

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10068>
_______________________________________

From report at bugs.python.org  Wed Oct 13 03:12:03 2010
From: report at bugs.python.org (Michael Newman)
Date: Wed, 13 Oct 2010 01:12:03 +0000
Subject: [issue6417] multiprocessing Process examples: print and getppid
In-Reply-To: <1246719525.24.0.54072257834.issue6417@psf.upfronthosting.co.za>
Message-ID: <1286932323.12.0.16822175428.issue6417@psf.upfronthosting.co.za>


Michael Newman <michael.b.newman at gmail.com> added the comment:

The example is working correctly for:
Python 3.2a3 (r32a3:85355, Oct 10 2010, 17:11:45) [MSC v.1500 32 bit (Intel)] on win32

# First test:
C:\mike>c:\Python32\python.exe s2.py
main line
module name: __main__
parent process: 2360
process id: 1584
function f
module name: __main__
parent process: 1584
process id: 3588
hello bob

# Second test (run it again to see process IDs change)
C:\mike>c:\Python32\python.exe s2.py
main line
module name: __main__
parent process: 2360
process id: 5904
function f
module name: __main__
parent process: 5904
process id: 1560
hello bob

# For reference:
C:\mike>c:\Python32\python.exe
Python 3.2a3 (r32a3:85355, Oct 10 2010, 17:11:45) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.getppid()
2360

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6417>
_______________________________________

From report at bugs.python.org  Wed Oct 13 04:23:57 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Oct 2010 02:23:57 +0000
Subject: [issue7944] Use the 'with' statement in conjunction with 'open'
	throughout test modules
In-Reply-To: <1266342231.42.0.692171370087.issue7944@psf.upfronthosting.co.za>
Message-ID: <1286936637.98.0.877061897208.issue7944@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed test_gzip in r85400.

----------
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Wed Oct 13 04:43:16 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Wed, 13 Oct 2010 02:43:16 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
In-Reply-To: <1286884651.82.0.158483399845.issue10071@psf.upfronthosting.co.za>
Message-ID: <1286937796.94.0.997503755655.issue10071@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

Hirokazu, could you run Python in a debugger and figure out exactly which line crashes and what the error is?  I'm curious.

If we make this change, the same change should be applied to RegEnumKey, etc., since the RegEnumKey docs contain similar language.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Wed Oct 13 04:58:29 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Oct 2010 02:58:29 +0000
Subject: [issue7944] Use the 'with' statement in conjunction with 'open'
	throughout test modules
In-Reply-To: <1266342231.42.0.692171370087.issue7944@psf.upfronthosting.co.za>
Message-ID: <1286938709.4.0.548176583825.issue7944@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed test_mailbox in r85401.
Fixed test_marshal in r85402.
Fixed test_bz2 in r85403.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Wed Oct 13 05:19:56 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Wed, 13 Oct 2010 03:19:56 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>


New submission from Bruce Sherwood <bruce.sherwood at gmail.com>:

It is proposed to incorporate the work of Guilherme Polo in the 2009
Google Summer of Code into idlelib. Polo's enhancements have been
extensively tested for a year through being included with VPython.

Here is a description from NEWS.txt:

In December 2008 David Scherer created an alternative version
of IDLE to fix some long-standing problems. In the 2009 Google
Summer of Code Guilherme Polo continued this work, assisted by
Bruce Sherwood. Important new fixes and features include:

 * A configuration preference that permits writing and running
   test programs from the editor without having to save the file
   (you're warned upon quitting whether to save).

 * Bringing the shell window forward in case of an error (because
   novices often failed to realize why their program had stopped).
 * A revert plug-in (FileRevert.py).

 * Unreliable and slow termination of user program on Windows;
   now you can re-run without first closing the graphics window.

 * Missing preferences and other menus on Macintosh.

 * Use any port for RPC server, so multiple instances of VIDLE
   can run at the same time without interference.

Polo submitted patches at the end of the summer of 2009, found at
code.google.com/p/google-summer-of-code-2009-python/downloads/list
This was for the Python 2.X series.

Because the mechanism was not clear for getting these patches
into the version of IDLE distributed with Python, the patched
version has been distributed with VPython (vpython.org) with
the name VIDLE to attempt to avoid confusion with IDLE. It is
installed into site-packages.

In October 2010 Bruce Sherwood manually applied Polo's patches
to the idlelib found at 
   svn.python.org/projects/python/tags/r312/Lib/idlelib 

In addition to applying Polo's patches, the new code uses the new
dot addressing of modules (e.g. from . import PyShell). Except for
having to change one absolute address in the use of __import__ in
PyShell.py, this version can work either in Python31/Lib/idlelib or
in Python31/Lib/site-packages/vidle. This VIDLE will be included in
the installer for VPython for Python 3.

----------
components: IDLE
files: vidle20101012.diff
keywords: patch
messages: 118501
nosy: Bruce.Sherwood
priority: normal
severity: normal
status: open
title: idlelib for Python 3 with Guilherme Polo GSoC enhancements
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file19211/vidle20101012.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Wed Oct 13 06:11:15 2010
From: report at bugs.python.org (Mitchell Stokes)
Date: Wed, 13 Oct 2010 04:11:15 +0000
Subject: [issue10080] Py_Initialize crashes when stdout has been redirected
	with freopen
In-Reply-To: <1286943075.1.0.984332542932.issue10080@psf.upfronthosting.co.za>
Message-ID: <1286943075.1.0.984332542932.issue10080@psf.upfronthosting.co.za>


New submission from Mitchell Stokes <mogurijin at gmail.com>:

I have Python embedded in a C/C++ program, and I'm trying to redirect stdout to a text file. Since I'm trying to get rid of the console, I want C and Python stdout going to the text file (so, not sys.stdout = open('log.txt', 'w')). To this end, I used freopen() like so:

freopen("log.txt", "w", stdout);

to redirect stdout in C. However, when using Python 3.1, I get the following error:

Fatal Python error: Py_Initialize: can't initialize sys standard streams
OSError: [Errno 9] Bad file descriptor

followed by a crash (Runtime Error). I think this is somewhat related to this bug: http://bugs.python.org/issue1415

I've attached a sample program that illustrates the problem. I compiled it with:

gcc -o py_main.exe py_main.c -IC:\Python31\include -LC:\Python31\libs -lpython31

I had someone test the sample program on Linux, and it worked fine there, so I think it's a Windows issue.

----------
components: Windows
files: py_main.c
messages: 118502
nosy: Mitchell.Stokes
priority: normal
severity: normal
status: open
title: Py_Initialize crashes when stdout has been redirected with freopen
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file19212/py_main.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10080>
_______________________________________

From report at bugs.python.org  Wed Oct 13 07:10:59 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 13 Oct 2010 05:10:59 +0000
Subject: [issue6417] multiprocessing Process examples: print and getppid
In-Reply-To: <1246719525.24.0.54072257834.issue6417@psf.upfronthosting.co.za>
Message-ID: <1286946658.89.0.409260861536.issue6417@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Thanks Michael for checking it, this bug can be closed then, since all the points mentioned were already fixed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6417>
_______________________________________

From report at bugs.python.org  Wed Oct 13 07:16:03 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 13 Oct 2010 05:16:03 +0000
Subject: [issue6417] multiprocessing Process examples: print and getppid
In-Reply-To: <1246719525.24.0.54072257834.issue6417@psf.upfronthosting.co.za>
Message-ID: <1286946963.62.0.19989567407.issue6417@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6417>
_______________________________________

From report at bugs.python.org  Wed Oct 13 08:42:34 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 13 Oct 2010 06:42:34 +0000
Subject: [issue10080] Py_Initialize crashes when stdout has been redirected
	with freopen
In-Reply-To: <1286943075.1.0.984332542932.issue10080@psf.upfronthosting.co.za>
Message-ID: <1286952154.86.0.634626330106.issue10080@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It looks very similar to issue6501.
Can you check if setting the environment variable
    PYTHONIOENCODING=cp1252
solves the problem?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10080>
_______________________________________

From report at bugs.python.org  Wed Oct 13 10:32:50 2010
From: report at bugs.python.org (Valery Lesin)
Date: Wed, 13 Oct 2010 08:32:50 +0000
Subject: [issue10081] 'import' operator doesn't work with unicode non 7-bit
	ASCII module names (OS: windows)
In-Reply-To: <1286958770.12.0.126097151739.issue10081@psf.upfronthosting.co.za>
Message-ID: <1286958770.12.0.126097151739.issue10081@psf.upfronthosting.co.za>


New submission from Valery Lesin <valery.lesin at gmail.com>:

OS: windows

The attempt to import module with non 7-bit ASCII name results in 
'ImportError: No module named <module name>' exception.


Some thoughts: import.c uses functions like fopen, stat and FindFirstFile which wouldn't work correctly with non 7-bit ASCII filenames in Windows.

----------
components: Interpreter Core, Unicode
messages: 118505
nosy: Valery.Lesin
priority: normal
severity: normal
status: open
title: 'import' operator doesn't work with unicode non 7-bit ASCII module names (OS: windows)
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10081>
_______________________________________

From report at bugs.python.org  Wed Oct 13 10:50:04 2010
From: report at bugs.python.org (Valery Lesin)
Date: Wed, 13 Oct 2010 08:50:04 +0000
Subject: [issue10082] PyRun_SimpleFile crashes application
In-Reply-To: <1286959803.51.0.331487773868.issue10082@psf.upfronthosting.co.za>
Message-ID: <1286959803.51.0.331487773868.issue10082@psf.upfronthosting.co.za>


New submission from Valery Lesin <valery.lesin at gmail.com>:

All the functions in Python/C API for file execution (like PyRun_SimpleFile) crash the application.

Some thoughts about problem: these functions use FILE* as first parameter which is binary incompatible with different CRT (python.dll and application could use different ones). 

Some thoughts about solution: maybe it's possible to pass only filename and python will open (and close) file itself? Second idea is to use functions like PyFile_FromString (like in Python 2)

----------
components: Extension Modules, Windows
messages: 118506
nosy: Valery.Lesin
priority: normal
severity: normal
status: open
title: PyRun_SimpleFile crashes application
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10082>
_______________________________________

From report at bugs.python.org  Wed Oct 13 11:36:53 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 13 Oct 2010 09:36:53 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
In-Reply-To: <1286884651.82.0.158483399845.issue10071@psf.upfronthosting.co.za>
Message-ID: <1286962613.74.0.818882833544.issue10071@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Well, I couldn't reproduce it on WinXP. Probably
Win2K's bug. One thread is exactly on RegEnumValue
or RegQueryValue, and another thread is a bit after
RegSetValue (the place varies case by case). Type is
SEGV.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Wed Oct 13 11:47:06 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 13 Oct 2010 09:47:06 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
In-Reply-To: <1286884651.82.0.158483399845.issue10071@psf.upfronthosting.co.za>
Message-ID: <1286963226.45.0.710838046204.issue10071@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


----------
Removed message: http://bugs.python.org/msg118507

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Wed Oct 13 11:55:49 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 13 Oct 2010 09:55:49 +0000
Subject: [issue10071] Should not release GIL while running RegEnumValue
In-Reply-To: <1286884651.82.0.158483399845.issue10071@psf.upfronthosting.co.za>
Message-ID: <1286963749.65.0.213695915868.issue10071@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

One thread is exactly on RegEnumValue
or RegQueryValue, and another thread is a bit after
RegSetValue (the place varies case by case). Type is
SEGV.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10071>
_______________________________________

From report at bugs.python.org  Wed Oct 13 12:36:27 2010
From: report at bugs.python.org (=?utf-8?q?Bram_Mari=C3=ABn?=)
Date: Wed, 13 Oct 2010 10:36:27 +0000
Subject: [issue10083] locale.currency() uses different formatting than system
	locale for negative values
In-Reply-To: <1286966187.73.0.144936729531.issue10083@psf.upfronthosting.co.za>
Message-ID: <1286966187.73.0.144936729531.issue10083@psf.upfronthosting.co.za>


New submission from Bram Mari?n <bram.marien at gmail.com>:

On Windows Vista and Windows 7 (XP and Ubuntu seem ok):

If the system locale is used (using locale.setlocale(LC_ALL, '') and the system locale is set to dutch belgium: 
If the regional options are set to format negative monetary items as "<EURO sign> -<value>", than locale.currency(value) will format it as "<EURO sign)value-".

Other formatting options works ok: e.g. if the regional settings display negative monetary items as "(value)", than "locale.currency(value)" will also display "{value)".

Reproducable on Python 2.6.x, 2.7.x and 3.1.2 on Windows Vista (32 bit)

----------
components: Windows
files: locale_currency_negative.JPG
messages: 118509
nosy: bram.marien
priority: normal
severity: normal
status: open
title: locale.currency() uses different formatting than system locale for negative values
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19213/locale_currency_negative.JPG

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10083>
_______________________________________

From report at bugs.python.org  Wed Oct 13 12:40:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 10:40:18 +0000
Subject: [issue9003] urllib.request and http.client should allow certificate
	checking
In-Reply-To: <1276650277.98.0.113951617798.issue9003@psf.upfronthosting.co.za>
Message-ID: <1286966418.39.0.105681993019.issue9003@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r85408. I believe this fixes, at last, the whole issue people were complaining about.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9003>
_______________________________________

From report at bugs.python.org  Wed Oct 13 13:10:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 11:10:18 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286968218.81.0.625617482782.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> dmalcolm asked if it would be possible to display the 
> Python backtrace on Py_FatalError()

It works :-) I fixed a bug in ceval.c (r85411) which was not directly related.

Patch version 5:
 - Display the Python backtrace on Py_FatalError() (if no error occurred)
 - Use _PyThreadState_GetFrame(tstate) instead of tstate->frame
 - Create _Py_DumpBacktrace() function
 - _Py_DumpBacktrace() doesn't display anything if there is no frame (tstate->frame == NULL), it's the case during Python initialization
 - replace fprintf() by calls to fputs/fputc in Py_FatalError(): fprintf() might raise a new error, I prefer simple functions (safer and faster)

----------
Added file: http://bugs.python.org/file19214/segfault_handler-5.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 13:11:57 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 11:11:57 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286968317.62.0.764774198303.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file19208/segfault_handler-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 13:12:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 11:12:02 +0000
Subject: [issue8863] Segfault handler: display Python backtrace on segfault
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286968322.38.0.531565324498.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file19210/segfault_handler-4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 13:20:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 11:20:47 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286968847.7.0.357597241964.issue8863@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
title: Segfault handler: display Python backtrace on segfault -> Display Python backtrace on SIGSEGV, SIGFPE and fatal error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 13:21:31 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 13 Oct 2010 11:21:31 +0000
Subject: [issue10083] locale.currency() uses different formatting than system
	locale for negative values
In-Reply-To: <1286966187.73.0.144936729531.issue10083@psf.upfronthosting.co.za>
Message-ID: <1286968891.31.0.239992772352.issue10083@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I don't have a copy of Vista or 7 handy to check with. Could you tell me what locale.localeconv() returns on a non-working system and on a working system (preferably Windows XP)?

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10083>
_______________________________________

From report at bugs.python.org  Wed Oct 13 13:22:18 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 13 Oct 2010 11:22:18 +0000
Subject: [issue10083] locale.currency() uses different formatting than system
	locale for negative values
In-Reply-To: <1286966187.73.0.144936729531.issue10083@psf.upfronthosting.co.za>
Message-ID: <1286968938.7.0.282413626124.issue10083@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
components: +Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10083>
_______________________________________

From report at bugs.python.org  Wed Oct 13 13:31:24 2010
From: report at bugs.python.org (=?utf-8?q?Bram_Mari=C3=ABn?=)
Date: Wed, 13 Oct 2010 11:31:24 +0000
Subject: [issue10083] locale.currency() uses different formatting than system
	locale for negative values
In-Reply-To: <1286966187.73.0.144936729531.issue10083@psf.upfronthosting.co.za>
Message-ID: <1286969484.46.0.305391429151.issue10083@psf.upfronthosting.co.za>


Bram Mari?n <bram.marien at gmail.com> added the comment:

*  On Windows Vista (non working system): 

>>> locale.localeconv()
{'mon_decimal_point': ',', 'int_frac_digits': 2, 'p_sep_by_space': 1, 'frac_digits': 2, 'thousands_sep': '.', 'n_sign_posn': 4, 'decimal_point': ',', 'int_curr_symbol': 'EUR', 'n_cs_precedes': 1, 'p_sign_posn': 4, 'mon_thousands_sep': '.', 'negative_sign': '-', 'currency_symbol': '\x80', 'n_sep_by_space': 1, 'mon_grouping': [3, 0], 'p_cs_precedes': 1, 'positive_sign': '', 'grouping': [3, 0]}


* On Windows XP (Working system):
{'mon_decimal_point': ',', 'int_frac_digits': 2, 'p_sep_by_space': 1, 'frac_digits': 2, 'thousands_sep': '.', 'n_sign_posn': 1, 'decimal_point': ',', 'int_curr_symbol': 'EUR', 'n_cs_precedes': 0, 'p_sign_posn': 1, 'mon_thousands_sep': '.', 'negative_sign': '-', 'currency_symbol': '\x80', 'n_sep_by_space': 1, 'mon_grouping': [3, 0], 'p_cs_precedes': 0, 'positive_sign': '', 'grouping': [3, 0]}

The locale is set to 'Dutch_Belgium.1252'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10083>
_______________________________________

From report at bugs.python.org  Wed Oct 13 13:43:35 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 13 Oct 2010 11:43:35 +0000
Subject: [issue10083] locale.currency() uses different formatting than system
	locale for negative values
In-Reply-To: <1286966187.73.0.144936729531.issue10083@psf.upfronthosting.co.za>
Message-ID: <1286970215.35.0.85889874154.issue10083@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

So it looks like locale.currency() is doing the right thing, given the values returned by locale.localeconv().

These values are copied from C's localeconv(), so the problem must be there. I don't see how we can do anything about it on the Python side, unfortunately.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10083>
_______________________________________

From report at bugs.python.org  Wed Oct 13 14:22:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 12:22:32 +0000
Subject: [issue10080] Py_Initialize crashes when stdout has been redirected
	with freopen
In-Reply-To: <1286943075.1.0.984332542932.issue10080@psf.upfronthosting.co.za>
Message-ID: <1286972552.6.0.379885435788.issue10080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't think freopen() is the right solution, since it might open another (different) file descriptor under the hood; but Python always uses file descriptor 1 when creating sys.stderr.

I would suggest instead something such as (untested):

int tmpfd;
tmpfd = open("myfile.txt", O_CREAT | O_WRONLY);
dup2(tmpfd, 1);

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10080>
_______________________________________

From report at bugs.python.org  Wed Oct 13 14:23:19 2010
From: report at bugs.python.org (=?utf-8?q?=C5=81ukasz_Langa?=)
Date: Wed, 13 Oct 2010 12:23:19 +0000
Subject: [issue7434] general pprint rewrite
In-Reply-To: <1259944363.21.0.149882342014.issue7434@psf.upfronthosting.co.za>
Message-ID: <1286972599.67.0.0801081064929.issue7434@psf.upfronthosting.co.za>


?ukasz Langa <lukasz at langa.pl> added the comment:

I would like to work on that. Expect a patch soon.

Georg, Fred, I've added you to nosy because you're the ones watching over me currently. Bare with me :)

----------
nosy: +fdrake, georg.brandl, lukasz.langa
title: pprint doesn't know how to print a namedtuple -> general pprint rewrite
versions:  -Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7434>
_______________________________________

From report at bugs.python.org  Wed Oct 13 14:30:05 2010
From: report at bugs.python.org (Nicolas Schodet)
Date: Wed, 13 Oct 2010 12:30:05 +0000
Subject: [issue6755] Patch: new method get_wch for ncurses bindings: accept
	wide characters (unicode)
In-Reply-To: <1250855012.37.0.745791721367.issue6755@psf.upfronthosting.co.za>
Message-ID: <1286973005.43.0.553434803019.issue6755@psf.upfronthosting.co.za>


Changes by Nicolas Schodet <nico-python at ni.fr.eu.org>:


----------
nosy: +schodet

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6755>
_______________________________________

From report at bugs.python.org  Wed Oct 13 14:39:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 13 Oct 2010 12:39:06 +0000
Subject: [issue10082] PyRun_SimpleFile crashes application
In-Reply-To: <1286959803.51.0.331487773868.issue10082@psf.upfronthosting.co.za>
Message-ID: <1286973546.3.0.357174686698.issue10082@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What operating system are you using? What compiler?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10082>
_______________________________________

From report at bugs.python.org  Wed Oct 13 14:54:28 2010
From: report at bugs.python.org (Valery Lesin)
Date: Wed, 13 Oct 2010 12:54:28 +0000
Subject: [issue10082] PyRun_SimpleFile crashes application
In-Reply-To: <1286959803.51.0.331487773868.issue10082@psf.upfronthosting.co.za>
Message-ID: <1286974468.32.0.597100597163.issue10082@psf.upfronthosting.co.za>


Valery Lesin <valery.lesin at gmail.com> added the comment:

OS: windows xp
Compiler: MSVC versions 7.1, 8.0 and 9.0 

Actually, the difference in compiler for python library and client applications causes the problem (I suppose that even same compiler with different options could give binary incompatible FILE structures).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10082>
_______________________________________

From report at bugs.python.org  Wed Oct 13 15:09:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 13:09:12 +0000
Subject: [issue10084] SSL support for asyncore
In-Reply-To: <1286975352.23.0.354014332486.issue10084@psf.upfronthosting.co.za>
Message-ID: <1286975352.23.0.354014332486.issue10084@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It might be useful to make public the SSL support for asyncore which is currently implemented in various tests.

----------
assignee: giampaolo.rodola
components: Library (Lib)
messages: 118519
nosy: giampaolo.rodola, pitrou
priority: normal
severity: normal
status: open
title: SSL support for asyncore
type: feature request
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10084>
_______________________________________

From report at bugs.python.org  Wed Oct 13 15:11:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 13:11:43 +0000
Subject: [issue10084] SSL support for asyncore
In-Reply-To: <1286975352.23.0.354014332486.issue10084@psf.upfronthosting.co.za>
Message-ID: <1286975503.91.0.648966100928.issue10084@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(I'm posting this issue after having read this message:
http://mail.python.org/pipermail/python-list/2010-October/1257689.html
where the poster is clearly confused about SSL support for asyncore)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10084>
_______________________________________

From report at bugs.python.org  Wed Oct 13 15:11:53 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 13 Oct 2010 13:11:53 +0000
Subject: [issue10082] PyRun_SimpleFile crashes application
In-Reply-To: <1286959803.51.0.331487773868.issue10082@psf.upfronthosting.co.za>
Message-ID: <1286975513.61.0.2733522427.issue10082@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Ok, unless you are using the very same compiler that Python was compiled with, this will indeed crash. Closing this as "won't fix", then - use PyRun_SimpleString instead.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10082>
_______________________________________

From report at bugs.python.org  Wed Oct 13 16:12:20 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 13 Oct 2010 14:12:20 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1286979140.86.0.515084014063.issue7523@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/issue7523>
_______________________________________

From report at bugs.python.org  Wed Oct 13 16:16:55 2010
From: report at bugs.python.org (Peter Gyorko)
Date: Wed, 13 Oct 2010 14:16:55 +0000
Subject: [issue10066] xmlrpclib does not handle some non-printable characters
	properly
In-Reply-To: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>
Message-ID: <1286979415.28.0.505135655871.issue10066@psf.upfronthosting.co.za>


Peter Gyorko <gyorkop at balabit.hu> added the comment:

The shortest code which can trigger this error is the following:

>>> import xmlrpclib
>>> print xmlrpclib.dumps(('\x01',))
<params>
<param>
<value><string>
</string></value>
</param>
</params>

As you can see, the escape method does not care about non-printable characters which can cause parsing error in the other side.

My previous patch used \x to tell to the other side that the value contains some binary garbage. It you want to reject these binary bytes (which was not acceptable in my case), use this patch:

--- a/xmlrpclib.py	2010-10-13 14:45:02.000000000 +0200
+++ b/xmlrpclib.py	2010-10-13 16:03:14.000000000 +0200
@@ -165,6 +165,9 @@
     return data
 
 def escape(s, replace=string.replace):
+    if (None != re.search('[\x00-\x08\x0b-\x0c\x0e-\x1f\x7f-\xff]', s)):
+        raise Fault(INVALID_ENCODING_CHAR, 'Non-printable character in string')
+
     s = replace(s, "&", "&amp;")
     s = replace(s, "<", "&lt;")
     return replace(s, ">", "&gt;",)

An other idea: we may use CDATA (http://www.w3schools.com/xml/xml_cdata.asp) to transfer binary values...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10066>
_______________________________________

From report at bugs.python.org  Wed Oct 13 16:19:09 2010
From: report at bugs.python.org (=?utf-8?b?0JDQvdC00YDQtdC5INCU0LDQstGL0LTQvtCy?=)
Date: Wed, 13 Oct 2010 14:19:09 +0000
Subject: [issue10085] Memory allocation for primitive types
In-Reply-To: <1286979549.85.0.436821167858.issue10085@psf.upfronthosting.co.za>
Message-ID: <1286979549.85.0.436821167858.issue10085@psf.upfronthosting.co.za>


New submission from ?????? ??????? <andrey.a.davydov at gmail.com>:

Output for this script is

8.64453125
in test 163.80078125
in f 318.70703125
after f 280.49609375
in f 318.72265625
after f 280.50390625
0
164.4765625
126.26171875
10.01171875

If Python store all created objects of primitive types, why does it allocate (318 - 163) MB for call of function 'f'?
What memory does it free when call 'gc.collect()'

----------
components: None
files: memory.py
messages: 118523
nosy: ??????.???????
priority: normal
severity: normal
status: open
title: Memory allocation for primitive types
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file19215/memory.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10085>
_______________________________________

From report at bugs.python.org  Wed Oct 13 16:30:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 14:30:25 +0000
Subject: [issue10085] Memory allocation for primitive types
In-Reply-To: <1286979549.85.0.436821167858.issue10085@psf.upfronthosting.co.za>
Message-ID: <1286980225.98.0.942313887562.issue10085@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't see any actual problem here. If you want help understanding Python's semantics, please post to comp.lang.python.

----------
nosy: +pitrou
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10085>
_______________________________________

From report at bugs.python.org  Wed Oct 13 16:39:23 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Wed, 13 Oct 2010 14:39:23 +0000
Subject: [issue10086] test_sysconfig failure with site-packages
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

test_sysconfig on Python 3.2a3 fails with AssertionError:
'/home/sjef/.local/lib/python3.2/site-packages' !=
'/home/sjef/.local/lib/python3.2/home/sjef/.local-packages'

Python-3.2a3$ ./python Lib/test/regrtest.py -v test_sysconfig
== CPython 3.2a3 (r32a3:85355, Oct 13 2010, 07:34:15) [GCC 4.4.3]
==   Linux-2.6.32-25-generic-x86_64-with-debian-squeeze-sid little-endian
==   /home/sjef/src/python/Python-3.2a3/build/test_python_17497
[1/1] test_sysconfig
test_get_config_h_filename (test.test_sysconfig.TestSysConfig) ... ok
test_get_config_vars (test.test_sysconfig.TestSysConfig) ... ok
test_get_makefile_filename (test.test_sysconfig.TestSysConfig) ... ok
test_get_path (test.test_sysconfig.TestSysConfig) ... ok
test_get_path_names (test.test_sysconfig.TestSysConfig) ... ok
test_get_paths (test.test_sysconfig.TestSysConfig) ... ok
test_get_platform (test.test_sysconfig.TestSysConfig) ... ok
test_get_scheme_names (test.test_sysconfig.TestSysConfig) ... ok
test_ldshared_value (test.test_sysconfig.TestSysConfig) ... ok
test_main (test.test_sysconfig.TestSysConfig) ... ok
test_symlink (test.test_sysconfig.TestSysConfig) ... ok
test_user_similar (test.test_sysconfig.TestSysConfig) ... FAIL

======================================================================
FAIL: test_user_similar (test.test_sysconfig.TestSysConfig)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/sjef/src/python/Python-3.2a3/Lib/test/test_sysconfig.py", line 278, in test_user_similar
    self.assertEquals(user_path, global_path.replace(base, user))
AssertionError: '/home/sjef/.local/lib/python3.2/site-packages' != '/home/sjef/.local/lib/python3.2/home/sjef/.local-packages'
- /home/sjef/.local/lib/python3.2/site-packages
?                                  ^^
+ /home/sjef/.local/lib/python3.2/home/sjef/.local-packages
?                                 +++++ ^ ++++++++


----------------------------------------------------------------------
Ran 12 tests in 0.145s

FAILED (failures=1)
test test_sysconfig failed -- Traceback (most recent call last):
  File "/home/sjef/src/python/Python-3.2a3/Lib/test/test_sysconfig.py", line 278, in test_user_similar
    self.assertEquals(user_path, global_path.replace(base, user))
AssertionError: '/home/sjef/.local/lib/python3.2/site-packages' != '/home/sjef/.local/lib/python3.2/home/sjef/.local-packages'
- /home/sjef/.local/lib/python3.2/site-packages
?                                  ^^
+ /home/sjef/.local/lib/python3.2/home/sjef/.local-packages
?                                 +++++ ^ ++++++++


1 test failed:
    test_sysconfig

----------
components: Tests
messages: 118525
nosy: hfuru
priority: normal
severity: normal
status: open
title: test_sysconfig failure with site-packages
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Wed Oct 13 16:40:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 14:40:30 +0000
Subject: [issue10086] test_sysconfig failure with site-packages
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1286980830.53.0.934356585891.issue10086@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> tarek
components: +Distutils -Tests
nosy: +eric.araujo, tarek
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Wed Oct 13 16:41:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 14:41:51 +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: <1286980911.16.0.242735878226.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I posted the patch on Rietveld for a review (as asked by Antoine): http://codereview.appspot.com/2477041

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 16:59:51 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 13 Oct 2010 14:59:51 +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: <1286981991.49.0.850528229472.issue8863@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

It looks like this doesn't yet have any test cases.

You probably should invoke a child python process that crashes and examine the output (perhaps running some/all of the examples in Lib/test/crashers ?); you may want to "steal" some of the wrapper code from Lib/test/test_gdb.py to do this.

Test ideas:
  - generate a segfault, verify that the output is sane
  - generate a FPE (likewise)
  - perhaps run all of the crashers, and ensure that something sane happens (e.g. stack overflow when the limit is set to something that's beyond what the OS/CPU can cope with).

Also, please test the interaction of this with the debugger (with gdb, at any rate): as I see it, this ought to gracefully get out of the way if you're running python under a debugger.  See Lib/test/test_gdb.py  for more examples of how to detect gdb, and invoke it in batch mode from a test suite.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 17:05:50 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 13 Oct 2010 15:05:50 +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: <1286982350.22.0.680991360437.issue8863@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

One other concern: many OSes (e.g. Linux distributions) implement some kind of system-wide crash-catching utility; for example in Fedora we have ABRT ( https://fedorahosted.org/abrt/wiki ).

I'm not sure yet exactly how these are implemented, but we'd want to avoid breaking them: segfaults of a system-provided /usr/bin/python (or /usr/bin/python3 ) should continue to be detected by such tools.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 17:25:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 15:25:31 +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: <1286983531.52.0.403566234012.issue8863@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, don't you want to handle SIGILL and SIGBUS too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 17:26:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 15:26:37 +0000
Subject: [issue7980] time.strptime not thread safe
In-Reply-To: <1266835598.13.0.361031999331.issue7980@psf.upfronthosting.co.za>
Message-ID: <1286983597.67.0.721959083619.issue7980@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It seems to me that this is related to if not a duplicate of issue 8098.

----------
keywords:  -patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7980>
_______________________________________

From report at bugs.python.org  Wed Oct 13 17:37:25 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 13 Oct 2010 15:37:25 +0000
Subject: [issue7287] import hook demo does not work
In-Reply-To: <1257687050.33.0.193418499466.issue7287@psf.upfronthosting.co.za>
Message-ID: <1286984245.77.0.179231364763.issue7287@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hi Benjamin,
you are the author of r63966 (I know, it's quite old, sorry about that) where you removed Demo/imputil/importers.py : do you think Demo/imputil/knee.py is still something interesting to have or should this be removed altogether? In case it's still worth to be included, I can work on fix it.

Regards,
Sandro

----------
nosy: +benjamin.peterson, sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7287>
_______________________________________

From report at bugs.python.org  Wed Oct 13 17:43:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 15:43:28 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

$ python3 -m calendar --type=html 2010

Produces HTML which renders into the attached PDF file.  It looks like bytes vs. strings issue.

----------
assignee: belopolsky
components: Library (Lib)
files: Calendar for 2010.pdf
messages: 118532
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: HTML calendar is broken
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19216/Calendar for 2010.pdf

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:00:39 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 16:00:39 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1286985639.97.0.582513938646.issue10087@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The issue is clearly with using print() for bytes' output: 

        if len(args) == 1:
            print(cal.formatyearpage(datetime.date.today().year, **optdict))

I am not sure, however how this can be fixed because calendar interface allows user to specify the encoding to be used for HTML and that encoding may not be the same or even compatible with sys.stdout encoding.

I would suggest adding -o/--output option to calendar CLI to specify the output file and make it required when specified encoding is not "compatible" with that of sys.stdout.  What constitutes "compatible" still needs to be defined.

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:01:24 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 13 Oct 2010 16:01:24 +0000
Subject: [issue10088] pdb can't re-set variables
In-Reply-To: <1286985684.86.0.916625287507.issue10088@psf.upfronthosting.co.za>
Message-ID: <1286985684.86.0.916625287507.issue10088@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola' <g.rodola at gmail.com>:

Not sure if this is on purpose but I've lost quite some time to debug this problem.

--- code ---

def foo():
    bar = 1
    import pdb; pdb.set_trace()   
foo()


--- pdb session ---

(Pdb) dir()
['__return__', 'bar', 'pdb']
(Pdb) bar
1
(Pdb) bar = 2
(Pdb) bar
1
(Pdb) 


If this is on purpose (pdb just CAN'T do it) then I would expect it to display an error of some kind when I enter "bar = 2", say: "*** NameError: 'foo' is a reserved name".

----------
messages: 118534
nosy: giampaolo.rodola
priority: normal
severity: normal
status: open
title: pdb can't re-set variables

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10088>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:10:08 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 Oct 2010 16:10:08 +0000
Subject: [issue10078] Documentation: 'Postive' should be 'Positive'
In-Reply-To: <1286924735.29.0.0342537376676.issue10078@psf.upfronthosting.co.za>
Message-ID: <1286986208.34.0.810288828038.issue10078@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10078>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:13:49 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 Oct 2010 16:13:49 +0000
Subject: [issue10088] pdb can't re-set variables
In-Reply-To: <1286985684.86.0.916625287507.issue10088@psf.upfronthosting.co.za>
Message-ID: <1286986429.39.0.476884801517.issue10088@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

What versions of Python does this apply to?  Is this a duplicate of issue 5215?

----------
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10088>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:20:37 2010
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 13 Oct 2010 16:20:37 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1286986837.55.0.134501462538.issue10087@psf.upfronthosting.co.za>


Walter D?rwald <walter at livinglogic.de> added the comment:

Does the following patch fix your problems?

----------
keywords: +patch
nosy: +doerwalter
Added file: http://bugs.python.org/file19217/calendar.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:26:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 16:26:34 +0000
Subject: [issue10041] socket.makefile(mode = 'r').readline() silently removes
	carriage return
In-Reply-To: <1286439179.94.0.684121251448.issue10041@psf.upfronthosting.co.za>
Message-ID: <1286987194.88.0.0799992296577.issue10041@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thank you very much! I've committed the patch in r85420 (3.2) and r85421 (3.1).

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10041>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:32:47 2010
From: report at bugs.python.org (Josh Bressers)
Date: Wed, 13 Oct 2010 16:32:47 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286987567.91.0.0874585922234.issue8863@psf.upfronthosting.co.za>


Josh Bressers <josh at bress.net> added the comment:

You would be wise to avoid using heap storage once you're in the crash handler. From a security standpoint, if something has managed to damage the heap (which is not uncommon in a crash), you should not attempt to allocate or free heap memory. On modern glibc systems, this isn't much of a concern as there are various memory protection mechanisms that make heap exploitation very very hard (you're just going to end up crashing the crash handler). I'm not sure about other operating systems that python supports though.

----------
nosy: +joshbressers

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:35:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 16:35:48 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1286987567.91.0.0874585922234.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286987744.3362.1.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> You would be wise to avoid using heap storage once you're in the crash
> handler. From a security standpoint, if something has managed to
> damage the heap (which is not uncommon in a crash), you should not
> attempt to allocate or free heap memory.

As far as I can tell, the signal handler in the patch doesn't call
malloc() or free(), neither directly nor indirectly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:38:07 2010
From: report at bugs.python.org (Mitchell Stokes)
Date: Wed, 13 Oct 2010 16:38:07 +0000
Subject: [issue10080] Py_Initialize crashes when stdout has been redirected
	with freopen
In-Reply-To: <1286943075.1.0.984332542932.issue10080@psf.upfronthosting.co.za>
Message-ID: <1286987887.03.0.284168873385.issue10080@psf.upfronthosting.co.za>


Mitchell Stokes <mogurijin at gmail.com> added the comment:

Setting PYTHONIOENCODING=cp1252 does not help.

Also, dup2 is not available on Windows (at least not from what I've read). >From my understanding, freopen() is supposed to be the portable way to redirect stdout.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10080>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:40:51 2010
From: report at bugs.python.org (Josh Bressers)
Date: Wed, 13 Oct 2010 16:40:51 +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: <1286988051.26.0.150710072438.issue8863@psf.upfronthosting.co.za>


Josh Bressers <josh at bress.net> added the comment:

I am then confused by this in the initial comment:

> It calls indirectly PyUnicode_EncodeUTF8() and so call
> PyBytes_FromStringAndSize() which allocates memory on the heap.

I've not studied the patch though, so this may have changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:42:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 16:42:37 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286986837.55.0.134501462538.issue10087@psf.upfronthosting.co.za>
Message-ID: <AANLkTikypKHPmObSUHk-ifYbstLuzg=r6or6BbVkMLp=@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Oct 13, 2010 at 12:20 PM, Walter D?rwald <report at bugs.python.org> wrote:
..
> Does the following patch fix your problems?
>

Probably not because with your patch print() will encode HTML stream
with the system default encoding which may be different from that
specified by -e/--encode argument to calendar.  The result would be an
ill-formed XML stream with encoding specified by the meta-tag not
matching the actual encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:45:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 16:45:40 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1286988051.26.0.150710072438.issue8863@psf.upfronthosting.co.za>
Message-ID: <1286988335.3362.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I am then confused by this in the initial comment:
> 
> > It calls indirectly PyUnicode_EncodeUTF8() and so call
> > PyBytes_FromStringAndSize() which allocates memory on the heap.
> 
> I've not studied the patch though, so this may have changed.

The patch certainly has changed, yes. In the latest patch, printing of
unicode message is done one code point at a time without allocating any
intermediary area.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:48:25 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Oct 2010 16:48:25 +0000
Subject: [issue10081] 'import' operator doesn't work with unicode non 7-bit
	ASCII module names (OS: windows)
In-Reply-To: <1286958770.12.0.126097151739.issue10081@psf.upfronthosting.co.za>
Message-ID: <1286988505.99.0.320403513428.issue10081@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

This is a duplicate of 9425

----------
nosy: +brett.cannon
superseder:  -> Rewrite import machinery to work with unicode paths

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10081>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:48:37 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Oct 2010 16:48:37 +0000
Subject: [issue10081] 'import' operator doesn't work with unicode non 7-bit
	ASCII module names (OS: windows)
In-Reply-To: <1286958770.12.0.126097151739.issue10081@psf.upfronthosting.co.za>
Message-ID: <1286988517.32.0.654956489894.issue10081@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10081>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:50:34 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 13 Oct 2010 16:50:34 +0000
Subject: [issue10088] pdb can't re-set variables
In-Reply-To: <1286985684.86.0.916625287507.issue10088@psf.upfronthosting.co.za>
Message-ID: <1286988634.84.0.810979445102.issue10088@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

It seems it's a duplicate of issue 5215 and I was using Python 2.6.
msg114103 states that the fix wasn't ported to 2.6 so I'm closing this out as invalid.

----------
resolution:  -> invalid
status: open -> closed
versions: +Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10088>
_______________________________________

From report at bugs.python.org  Wed Oct 13 18:52:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 16:52:24 +0000
Subject: [issue10080] Py_Initialize crashes when stdout has been redirected
	with freopen
In-Reply-To: <1286987887.03.0.284168873385.issue10080@psf.upfronthosting.co.za>
Message-ID: <1286988740.3362.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Also, dup2 is not available on Windows (at least not from what I've
> read).

MSDN says dup2 is deprecated but you can use _dup2 instead:
http://msdn.microsoft.com/en-us/library/8syseb29%28v=VS.80%29.aspx

> From my understanding, freopen() is supposed to be the portable way to
> redirect stdout.

I'm not sure, but as I said Python does not use C's "stdout". Instead,
it writes directly (using write()) to the file descriptor number 1. So,
if freopen() creates a different file descriptor for the C stdout,
Python's stdout will not be redirected where you want it to be.

I'm not saying that's what happens in your program, though. You could
call _fileno(stdout) after the reopen() call to check if it's still 1 or
not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10080>
_______________________________________

From report at bugs.python.org  Wed Oct 13 19:10:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 17:10:53 +0000
Subject: [issue9772] test_pep277 failure on AMD64 debian parallel buildbot
In-Reply-To: <1283601685.6.0.819525034936.issue9772@psf.upfronthosting.co.za>
Message-ID: <1286989853.78.0.458838183621.issue9772@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, the error message is (when interpreted as utf-8):

======================================================================
FAIL: test_listdir (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_pep277.py", line 157, in test_listdir
    self.assertEqual(sf0, sf2)
AssertionError: Items in the first set but not the second:
'@test_29046_tmp/Gr??-Gott'
Items in the second set but not the first:
'@test_29046_tmp/Gr\udcfc\udcdf-Gott'


Which corresponds to utf8 or ascii decoding of "Gr??-Gott" encoded with latin1:

>>> "Gr??-Gott".encode("latin1").decode("ascii", "surrogateescape")
'Gr\udcfc\udcdf-Gott'
>>> "Gr??-Gott".encode("latin1").decode("utf8", "surrogateescape")
'Gr\udcfc\udcdf-Gott'

----------
nosy: +haypo, loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9772>
_______________________________________

From report at bugs.python.org  Wed Oct 13 19:11:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 17:11:41 +0000
Subject: [issue9774] test_smtpnet fails with "[110] Connection timed out" on
	AMD64 debian parallel buildbot
In-Reply-To: <1283602927.92.0.540080511811.issue9774@psf.upfronthosting.co.za>
Message-ID: <1286989901.85.0.657531209623.issue9774@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/issue9774>
_______________________________________

From report at bugs.python.org  Wed Oct 13 19:16:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 17:16:06 +0000
Subject: [issue9774] test_smtpnet fails with "[110] Connection timed out" on
	AMD64 debian parallel buildbot
In-Reply-To: <1283602927.92.0.540080511811.issue9774@psf.upfronthosting.co.za>
Message-ID: <1286990166.04.0.394744143731.issue9774@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've commited a patch in r85423 to skip test_smtpnet when the connection to gmail fails (which it probably does because of a firewall somewhere).

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9774>
_______________________________________

From report at bugs.python.org  Wed Oct 13 19:17:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 17:17:44 +0000
Subject: [issue9773] test_tarfile fails because of inaccurate mtime on AMD64
	debian parallel buildbot
In-Reply-To: <1283602399.09.0.660649968872.issue9773@psf.upfronthosting.co.za>
Message-ID: <1286990264.77.0.242181360261.issue9773@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, when compiling on this buildbot, there's the following error message:

make: Warning: File `Makefile' has modification time 4.7 s in the future

which seems to hint that the filesystem on the buildbot is slightly misbehaving, or at least doesn't have very reliable timestamps.

----------
nosy: +loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9773>
_______________________________________

From report at bugs.python.org  Wed Oct 13 19:21:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 17:21:37 +0000
Subject: [issue9774] test_smtpnet fails with "[110] Connection timed out" on
	AMD64 debian parallel buildbot
In-Reply-To: <1283602927.92.0.540080511811.issue9774@psf.upfronthosting.co.za>
Message-ID: <1286990497.44.0.41510470828.issue9774@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Backported to 3.1 (r85424) and 2.7 (r85425).

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9774>
_______________________________________

From report at bugs.python.org  Wed Oct 13 19:27:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 17:27:38 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1286811287.76.0.200161520558.issue9437@psf.upfronthosting.co.za>
Message-ID: <1286990853.3362.9.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> However, since the Makefile now explicitly appends PY_LDFLAGS to
> LDSHARED, we could also stop doing so in ./configure.

I've committed a patch which does just this (in r85422). Hopefully it
won't break anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Wed Oct 13 19:40:40 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 13 Oct 2010 17:40:40 +0000
Subject: [issue10084] SSL support for asyncore
In-Reply-To: <1286975352.23.0.354014332486.issue10084@psf.upfronthosting.co.za>
Message-ID: <1286991640.59.0.0748965816063.issue10084@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Problem with SSL dispatcher subclasses used in tests is that they are all similar to pyftpdlib's SSLConnection class ( http://code.google.com/p/pyftpdlib/source/browse/trunk/pyftpdlib/contrib/handlers.py?spec=svn743&r=729#73 ) and I'm not sure it's API is suitable for a general use case. 
It fits well for pyftpdlib, servers in general and stdlib tests but I'm not sure about other uses cases.
In details I'm thinking about clients, secure connections reverted back to clear-text (e.g FTP might need this) and recent issues about certificates validation.
Before writing anything we should agree on an API and make sure it is able to cover all use cases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10084>
_______________________________________

From report at bugs.python.org  Wed Oct 13 19:57:18 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 13 Oct 2010 17:57:18 +0000
Subject: [issue7944] Use the 'with' statement in conjunction with 'open'
	throughout test modules
In-Reply-To: <1266342231.42.0.692171370087.issue7944@psf.upfronthosting.co.za>
Message-ID: <1286992638.22.0.879070694825.issue7944@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Here is a patch for test_os.py.

----------
nosy: +giampaolo.rodola
Added file: http://bugs.python.org/file19218/test_os.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:03:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Oct 2010 18:03:22 +0000
Subject: [issue9992] Command-line arguments are not correctly decoded if
	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1286993002.79.0.0249767402583.issue9992@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
title: Command line arguments are not correctly decodediflocale and fileystem encodingsaredifferent -> Command-line arguments are not correctly decoded if locale and fileystem encodings are different

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:10:44 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Oct 2010 18:10:44 +0000
Subject: [issue7944] Use the 'with' statement in conjunction with 'open'
	throughout test modules
In-Reply-To: <1266342231.42.0.692171370087.issue7944@psf.upfronthosting.co.za>
Message-ID: <1286993444.5.0.887892712798.issue7944@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm not sure that this is a worthwhile exercise unless it can be shown for certain that alternate implementations need this.  Otherwise, it just changes tests in a way that isn't backwards compatible, makes it more difficult to apply patches cleanly, and risks damaging an otherwise good test.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:13:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 18:13:51 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1286993631.44.0.246753106141.issue10087@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

There is a similar issue with printing text calendar with specified encoding:

$ python3 -m calendar --encoding=utf8
b'                                  2010\n\n ..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:14:35 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 13 Oct 2010 18:14:35 +0000
Subject: [issue10083] locale.currency() uses different formatting than system
	locale for negative values
In-Reply-To: <1286966187.73.0.144936729531.issue10083@psf.upfronthosting.co.za>
Message-ID: <1286993675.76.0.805809406985.issue10083@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10083>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:14:37 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Oct 2010 18:14:37 +0000
Subject: [issue7944] Use the 'with' statement in conjunction with 'open'
	throughout test modules
In-Reply-To: <1266342231.42.0.692171370087.issue7944@psf.upfronthosting.co.za>
Message-ID: <1286993677.59.0.670456779512.issue7944@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution: accepted -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:23:06 2010
From: report at bugs.python.org (Dave Fugate)
Date: Wed, 13 Oct 2010 18:23:06 +0000
Subject: [issue7944] Use the 'with' statement in conjunction with 'open'
	throughout test modules
In-Reply-To: <1286993444.5.0.887892712798.issue7944@psf.upfronthosting.co.za>
Message-ID: <299545F35D442642800736DBA0C3AA2806031CF3@TK5EX14MBXC207.redmond.corp.microsoft.com>


Dave Fugate <dfugate at microsoft.com> added the comment:

I guarantee you that IronPython needs this.  I was a tester on IronPython for four years, and saw hundreds of random failures due to this specific issue.

My best,

Dave

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:25:04 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 13 Oct 2010 18:25:04 +0000
Subject: [issue7944] Use the 'with' statement in conjunction with 'open'
	throughout test modules
In-Reply-To: <1266342231.42.0.692171370087.issue7944@psf.upfronthosting.co.za>
Message-ID: <1286994304.77.0.46867262162.issue7944@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

If you're sure that is still the case, this can proceed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:32:35 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 13 Oct 2010 18:32:35 +0000
Subject: [issue10066] xmlrpclib does not handle some non-printable characters
	properly
In-Reply-To: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>
Message-ID: <1286994755.0.0.416163239629.issue10066@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

No, CDATA is not an appropriate mechanism to encapsulate bytes in XML. The data in the CDATA section must still match the Char production, and it must still follow the encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10066>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:33:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Oct 2010 18:33:48 +0000
Subject: [issue10086] test_sysconfig failure with site-packages
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1286994828.37.0.632555754233.issue10086@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  Can you tell us what ./configure line you used before running make?  Or maybe you edited site.py or created a sitecustomize.py?

Tarek, Antoine: Is ?Distutils? the right component for sysconfig bugs?  (I thought it would be ?Library?.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:37:10 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 13 Oct 2010 18:37:10 +0000
Subject: [issue10085] Memory allocation for primitive types
In-Reply-To: <1286979549.85.0.436821167858.issue10085@psf.upfronthosting.co.za>
Message-ID: <1286995030.6.0.118816170328.issue10085@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It's probably more Python's implementation that ?????? is interested in, however, I agree that this is off-topic for this bug tracker, and that comp.lang.python might be a better place. You can also answer these questions by studying the Python source code, which you'll find at

http://www.python.org/ftp/python/2.6.6/Python-2.6.6.tar.bz2

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10085>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:41:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 13 Oct 2010 18:41:39 +0000
Subject: [issue10066] xmlrpclib does not handle some non-printable characters
	properly
In-Reply-To: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>
Message-ID: <1286995299.31.0.436955455251.issue10066@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the new patch.  I suggest one style change before committing:

 if re.search(<snip>, s) is not None:

Agree that CDATA is not appropriate.

Martin: I?m reopening the bug in reaction to your message ?I could accept a patch that rejects non-Char characters with an exception?, hope it?s fine.

----------
resolution: wont fix -> 
stage:  -> patch review
status: closed -> open
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10066>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:54:04 2010
From: report at bugs.python.org (Mitchell Stokes)
Date: Wed, 13 Oct 2010 18:54:04 +0000
Subject: [issue10080] Py_Initialize crashes when stdout has been redirected
	with freopen
In-Reply-To: <1286943075.1.0.984332542932.issue10080@psf.upfronthosting.co.za>
Message-ID: <1286996044.93.0.0700325678138.issue10080@psf.upfronthosting.co.za>


Mitchell Stokes <mogurijin at gmail.com> added the comment:

I used _dup2() and I still got a crash. Also, if I use _fileno(stdout) after using freopen(), I get 1.

I'm uploading two more example programs.

py_main_fileno_check.c prints the fileno to the text file
py_main_dup2.c uses _dup2() to redirect stdout instead of freopen

----------
Added file: http://bugs.python.org/file19219/py_main_fileno_check.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10080>
_______________________________________

From report at bugs.python.org  Wed Oct 13 20:54:16 2010
From: report at bugs.python.org (Mitchell Stokes)
Date: Wed, 13 Oct 2010 18:54:16 +0000
Subject: [issue10080] Py_Initialize crashes when stdout has been redirected
	with freopen
In-Reply-To: <1286943075.1.0.984332542932.issue10080@psf.upfronthosting.co.za>
Message-ID: <1286996056.38.0.732466673187.issue10080@psf.upfronthosting.co.za>


Changes by Mitchell Stokes <mogurijin at gmail.com>:


Added file: http://bugs.python.org/file19220/py_main_dup2.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10080>
_______________________________________

From report at bugs.python.org  Wed Oct 13 21:01:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 19:01:40 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

It can be useful to enable or disable global Python features based on command-line flags. The -X is supposed to allow implementation-specific options but it is currently disabled for CPython. This patch allows to use -X for arbitrary options in CPython. These options are not validated but minimally parsed and fed into a dictionary, sys.xoptions. An example is better than a thousand words:

$ ./python -c "import sys; print(sys.xoptions)"
{}
$ ./python -Xa,b=c,d -Xe,f=g=h -c "import sys; print(sys.xoptions)"
{'a': True, 'b': 'c', 'e': True, 'd': True, 'f': 'g=h'}


This could be useful for various debug enablers, such as Victor's SIGSEGV handler, warnings about unclosed files, etc.

----------
components: Interpreter Core
files: xopts.patch
keywords: patch
messages: 118563
nosy: haypo, loewis, ncoghlan, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Add support for arbitrary -X options
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19221/xopts.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Wed Oct 13 21:06:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 13 Oct 2010 19:06:05 +0000
Subject: [issue10066] xmlrpclib does not handle some non-printable characters
	properly
In-Reply-To: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>
Message-ID: <1286996765.98.0.548913741854.issue10066@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

?ric, I think the patch needs some rework. First, it is incorrect/incomplete: please see the Char definition for a complete list of characters that must be excluded. This then raises a Unicode vs. bytes issue, where invalid Unicode characters must be prohibited before the string actually being encoded (since apply the regex to the encoded string is not practical).

The other side of the bytes vs. string issue is that the bytes really ought to be in self.encoding, which doesn't get checked, either.

And then, it lacks tests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10066>
_______________________________________

From report at bugs.python.org  Wed Oct 13 21:07:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 19:07:18 +0000
Subject: [issue10080] Py_Initialize crashes when stdout has been redirected
	with freopen
In-Reply-To: <1286943075.1.0.984332542932.issue10080@psf.upfronthosting.co.za>
Message-ID: <1286996838.69.0.247580886991.issue10080@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the information. I'm afraid I can't be of any more help, since I'm not a Windows developer. I hope someone else can chime in.

----------
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10080>
_______________________________________

From report at bugs.python.org  Wed Oct 13 21:30:55 2010
From: report at bugs.python.org (Retro)
Date: Wed, 13 Oct 2010 19:30:55 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1286998255.4.0.507181416694.issue2775@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

I am very glad you're reorganizing the Standard Library. Thumbs up! I hope everything will comply to PEP 8 after you're done.

Since you're reorganizing, I have my own contribution. I have uploaded a patch. The issue7351 (http://bugs.python.org/issue7351) was not accepted at the time, I hope you'll accept this fix now.

My point is that every class name in module zipfile is like this:
- exception class: LargeZipFile
- normal class: ZipFile
- normal class: PyZipFile

So apply my fix to make the exception class BadZipfile consistent to others and let it be BadZipFile.

Thank you.

----------
nosy: +Retro
Added file: http://bugs.python.org/file19222/zipfile-patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Wed Oct 13 21:33:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 19:33:12 +0000
Subject: [issue10090] python -m locale fails on OSX
In-Reply-To: <1286998392.83.0.0924618610068.issue10090@psf.upfronthosting.co.za>
Message-ID: <1286998392.83.0.0924618610068.issue10090@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

$ python -m locale
Locale aliasing:

Locale defaults as determined by getdefaultlocale():
------------------------------------------------------------------------
Language:  en_US
Encoding:  UTF8
..

Locale settings after calling resetlocale():
------------------------------------------------------------------------
Traceback (most recent call last):
 ..

  File "Lib/locale.py", line 548, in resetlocale
    _setlocale(category, _build_localename(getdefaultlocale()))
locale.Error: unsupported locale setting


Apparently the problem is due to locale.getdefaultlocale() returning encoding as 'UTF8' while locale.setlocale() expects 'UTF-8'.

----------
components: Library (Lib)
messages: 118567
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: python -m locale fails on OSX
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10090>
_______________________________________

From report at bugs.python.org  Wed Oct 13 21:36:42 2010
From: report at bugs.python.org (nestor)
Date: Wed, 13 Oct 2010 19:36:42 +0000
Subject: [issue10091] ast.literal_eval does not handled new set literals
In-Reply-To: <1286998602.58.0.486068120725.issue10091@psf.upfronthosting.co.za>
Message-ID: <1286998602.58.0.486068120725.issue10091@psf.upfronthosting.co.za>


New submission from nestor <nestornissen at gmail.com>:

>>> import ast
>>> eval('{1:11,2:22}')
{1: 11, 2: 22}
>>> ast.literal_eval('{1:11,2:22}')
{1: 11, 2: 22}

>>> eval('{1,2}')
{1, 2}
>>> ast.literal_eval('{1,2}')
Traceback (most recent call last):
  File "<pyshell#8>", line 1, in <module>
    ast.literal_eval('{1,2}')
  File "C:\Python31\lib\ast.py", line 80, in literal_eval
    return _convert(node_or_string)
  File "C:\Python31\lib\ast.py", line 79, in _convert
    raise ValueError('malformed string')
ValueError: malformed string

>>> 

I haven't tested for 2.7 or 3.2 but this bug probably applies also there.

----------
components: Library (Lib)
messages: 118568
nosy: aronacher, benjamin.peterson, georg.brandl, gpolo, mark.dickinson, nestor, rhettinger, terry.reedy
priority: normal
severity: normal
status: open
title: ast.literal_eval does not handled new set literals
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10091>
_______________________________________

From report at bugs.python.org  Wed Oct 13 21:39:49 2010
From: report at bugs.python.org (Ezio Melotti)
Date: Wed, 13 Oct 2010 19:39:49 +0000
Subject: [issue10091] ast.literal_eval does not handled new set literals
In-Reply-To: <1286998602.58.0.486068120725.issue10091@psf.upfronthosting.co.za>
Message-ID: <1286998789.28.0.941600549703.issue10091@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/issue10091>
_______________________________________

From report at bugs.python.org  Wed Oct 13 21:41:42 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Wed, 13 Oct 2010 19:41:42 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1286998902.76.0.0732630771345.issue7523@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Another patch with:
 - testInitBlocking method
 - no c++ style comments
 - a newly generated configure script (almost 1.5k lines diff)
 - proper accept4 availability check

With this patch I've got 
Traceback (most recent call last):
  File "/home/nekto/workspace/py3k/Lib/test/test_socket.py", line 1564, in testInterruptedTimeout
    foo = self.serv.accept()
socket.timeout: timed out

Can someone test if there's a real regression?

----------
Added file: http://bugs.python.org/file19223/issue7523_py3k_accept4_1.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Wed Oct 13 21:53:37 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 19:53:37 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

>>> import calendar
>>> calendar.TextCalendar().formatmonthname(2010,10,10)
'October 2010'
>>> calendar.LocaleTextCalendar(locale='fr_FR').formatmonthname(2010,10,10)
'octobre 2010'
>>> calendar.TextCalendar().formatmonthname(2010,10,10)
'octobre 2010'

----------
messages: 118570
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: calendar does not restore locale properly

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Wed Oct 13 21:58:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 13 Oct 2010 19:58:02 +0000
Subject: [issue10091] ast.literal_eval does not handled new set literals
In-Reply-To: <1286998602.58.0.486068120725.issue10091@psf.upfronthosting.co.za>
Message-ID: <1286999882.5.0.805201394236.issue10091@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is fixed in 3.2 (see r82804).  As it is a new feature, it is not backported to 2.7 or earlier.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10091>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:01:31 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 13 Oct 2010 20:01:31 +0000
Subject: [issue10078] Documentation: 'Postive' should be 'Positive'
In-Reply-To: <1286924735.29.0.0342537376676.issue10078@psf.upfronthosting.co.za>
Message-ID: <1287000091.65.0.1603624556.issue10078@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

@OP: In general, we do apply such changes to all branches they can be fixed in.  Since this is done by merging from py3k to the other branches, it can be done later than the commit to py3k, or in batches.  Please leave that branch management to us.

----------
nosy: +georg.brandl
versions:  -3rd party, Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10078>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:03:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 20:03:01 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287000181.41.0.792058391864.issue10092@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +christian.heimes, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:04:16 2010
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 13 Oct 2010 20:04:16 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1287000256.99.0.527477761248.issue2775@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

The reorganization is over short of one or two lasting changes that may not even be made now. New suggestions are not directly being discussed here and would have to be taken up on python-dev.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:04:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 20:04:32 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287000272.36.0.412421035822.issue10092@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +twouters

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:08:48 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 13 Oct 2010 20:08:48 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1287000528.59.0.382510493544.issue4111@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Updated version of patch attached (against py3k; r85426)

I've changed the names back to "function__entry" and "function__return".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:11:25 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 13 Oct 2010 20:11:25 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1287000685.11.0.165957769081.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

What do we need to have this ready for Python 3.2?. The oportunity window is closing fast, and 3.3 is two years away...

So now or never...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:13:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 20:13:19 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1287000799.49.0.482432492589.issue10087@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Note that .decode(encoding) calls have been deliberately removed in py3k: see issue 3059.

----------
nosy: +georg.brandl, gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10087>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:16:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 20:16:29 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This patch outputs a warning on file deallocation when it hasn't been explicitly closed by the programmer.

Printing the warning by default is probably not desirable, but using the patch for "-X" options in issue10089 would allow to switch on when necessary.

----------
components: Extension Modules, Interpreter Core
files: deallocwarn.patch
keywords: patch
messages: 118577
nosy: pitrou
priority: normal
severity: normal
status: open
title: Warn when files are not explicitly closed
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19224/deallocwarn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:22:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 20:22:28 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287001348.15.0.896339886777.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, python-dev discussion was here:
http://mail.python.org/pipermail/python-dev/2010-September/104247.html

The rough consensus seems to be that there should be a command-line option to enable it, but to enable it by default with pydebug.

----------
nosy: +amaury.forgeotdarc, benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:22:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 20:22:44 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1287001364.37.0.770836311736.issue10089@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

See issue10093 for a possible use case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:46:00 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Wed, 13 Oct 2010 20:46:00 +0000
Subject: [issue10086] test_sysconfig failure with site-packages
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1287002760.09.0.158936341644.issue10086@psf.upfronthosting.co.za>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

"./configure --prefix=/site" on Ubuntu.
Unedited site.py.
I had Python3.2a2 installed, but removing it did
not make the test do anything different.
Nor did removing /home/sjef/.local/lib/python3.2,
which only contained an empty site-packages/.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:49:52 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Wed, 13 Oct 2010 20:49:52 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1287002992.51.0.578800523452.issue7523@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Here's what strace on FAIL shows (print "in alarm_handler" added)

alarm(2)                                = 0
poll([{fd=3, events=POLLIN}], 1, 5000)  = ? ERESTART_RESTARTBLOCK (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xffffffff)                = -1 EINTR (Interrupted system call)
accept4(3, 0x7fffa94c4780, [16], 0)     = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=3, events=POLLIN}], 1, 2999)  = 0 (Timeout)
accept4(3, 0x7fffa94c4780, [16], 0)     = -1 EAGAIN (Resource temporarily unavailable)
write(1, "in alarm_handler\n", 17)      = 17
alarm(0)                                = 0

Here's on OK:

alarm(2)                                = 0
poll([{fd=3, events=POLLIN}], 1, 5000)  = ? ERESTART_RESTARTBLOCK (To be restarted)
--- SIGALRM (Alarm clock) @ 0 (0) ---
rt_sigreturn(0xffffffff)                = -1 EINTR (Interrupted system call)
write(1, "in alarm_handler\n", 17)      = 17
alarm(0)

For some reason does another trip through BEGIN_SELECT_LOOP() macro

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Wed Oct 13 22:50:29 2010
From: report at bugs.python.org (Nathan Letwory)
Date: Wed, 13 Oct 2010 20:50:29 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <1287003029.26.0.162346022233.issue9377@psf.upfronthosting.co.za>


Nathan Letwory <nathan at letworyinteractive.com> added the comment:

platform.system() fails with UnicodeEncodeError on systems that have their computer name set to a name containing non-ascii characters. The implementation of platform.system() uses at some point socket.gethostname() ( see http://www.pasteall.org/16215 for a stacktrace of such usage)

There are a lot of our Blender users that are not english native-speakers and they set up their machine as they please, against RCFs or not.

This currently breaks some code that use platform.system() to check the system it's run on. The paste from above is from a user who has named his computer N?tk?tti.

It would be more than great if this error could be fixed. If another 3.1 release is planned, preferrably for that.

----------
nosy: +jesterKing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Wed Oct 13 23:04:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 21:04:15 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1287003855.15.0.223950083466.issue7523@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> For some reason does another trip through BEGIN_SELECT_LOOP() macro

Indeed:

     if (!timeout)
+#ifdef HAVE_ACCEPT4
+        /* inherit socket flags and use accept4 call */
+        flags = s->sock_type & (SOCK_CLOEXEC | SOCK_NONBLOCK);
+        newfd = accept4(s->sock_fd, SAS2SA(&addrbuf), &addrlen, flags);
+#else


There's a missing curly brace after "if (!timeout)", so accept4() is always called.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Wed Oct 13 23:06:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 21:06:46 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287004006.3.0.684704136673.issue10093@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file19224/deallocwarn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Wed Oct 13 23:06:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 21:06:54 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287004014.35.0.732985507058.issue10093@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Added file: http://bugs.python.org/file19225/deallocwarn.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Wed Oct 13 23:07:40 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Wed, 13 Oct 2010 21:07:40 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1287004060.45.0.63595558128.issue7523@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

@Antoine already found that myself, patched and tested :) thanks!

----------
Added file: http://bugs.python.org/file19226/issue7523_py3k_accept4_2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Wed Oct 13 23:41:00 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 13 Oct 2010 21:41:00 +0000
Subject: [issue9539] python-2.6.4: test failure in test_distutils due to
	linking to system libpython2.6
In-Reply-To: <1281222795.64.0.211558756173.issue9539@psf.upfronthosting.co.za>
Message-ID: <1287006060.56.0.9824857664.issue9539@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
on an up-to-date 2.7 I can't replicate this bug:

$ ./python Lib/test/regrtest.py test_distutils
test_distutils
1 test OK.

Is it just me or is been fixed already?

----------
nosy: +sandro.tosi
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9539>
_______________________________________

From report at bugs.python.org  Wed Oct 13 23:43:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 21:43:53 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1287006233.31.0.481959441813.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Version 6:
 - don't use fputc(), fputs(), fprintf() or fflush() on stderr: use write() on file descriptor 2 (should be stderr)
 - write tests: add sigsegv(), sigfpe() and fatal_error() functions to the _testcapi module

I was too lazy to reimplement functions to convert an integer to a string in bases 10 and 16, so I used snprintf() on a small buffer allocated on the stack.

----------
Added file: http://bugs.python.org/file19227/segfault_handler-6.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 23:50:32 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 21:50:32 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1287006632.73.0.623451916399.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

TODO (maybe): Call the original signal handler to make tools like apport or ABRT able to catch segmentation faults.

> By the way, don't you want to handle SIGILL and SIGBUS too?

Maybe. SIGILL is a very rare exception. To test it, should I send a SIGILL signal to the process? Or should I try to execute arbitrary CPU instructions?

About SIGBUS: I don't know this signal. Is it used on Linux? If not, on which OS is it used?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 13 23:53:25 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 13 Oct 2010 21:53:25 +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: <1287006805.69.0.284562579974.issue8863@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> About SIGBUS: I don't know this signal. Is it used on Linux? If not, on 
> which OS is it used?
Yes, IIRC typically you'll only see it on RISC CPUs that require instructions to be word-aligned; you typically see it if the program counter jumps to a broken address; the SIGBUS happens when the CPU tries to fetch the code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:00:56 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Oct 2010 22:00:56 +0000
Subject: [issue7287] import hook demo does not work
In-Reply-To: <1257687050.33.0.193418499466.issue7287@psf.upfronthosting.co.za>
Message-ID: <1287007256.44.0.555636544944.issue7287@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

See r85429.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7287>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:04:41 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 13 Oct 2010 22:04:41 +0000
Subject: [issue7287] import hook demo does not work
In-Reply-To: <1286984245.77.0.179231364763.issue7287@psf.upfronthosting.co.za>
Message-ID: <AANLkTimpKSEnNKaKJA9DNWjhOyR5-eXL9phv=dcgzYS0@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/10/13 Sandro Tosi <report at bugs.python.org>:
>
> Sandro Tosi <sandro.tosi at gmail.com> added the comment:
>
> Hi Benjamin,
> you are the author of r63966 (I know, it's quite old, sorry about that) where you removed Demo/imputil/importers.py : do you think Demo/imputil/knee.py is still something interesting to have or should this be removed altogether? In case it's still worth to be included, I can work on fix it.

Thank you for your offer! However, knee.py looks old and obsolete, so
I'm going to remove it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7287>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:18:41 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 22:18:41 +0000
Subject: [issue9992] Command-line arguments are not correctly decoded if
	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1287008321.86.0.323912651051.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited issue9992.patch as r85430 (remove PYTHONFSENCODING) + r85435 (OSX: decode command line arguments from utf-8).

These commits should fix this issue. Reopen the issue if you notice new problems, or if the problem is not fixed yet. I will watch Mac OS X buildbots, especially about r85435 ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:20:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 22:20:21 +0000
Subject: =?utf-8?q?=5Bissue10039=5D_python_=C3=A9=2Epy_fails_with_UnicodeEncodeErr?=
	=?utf-8?q?or_if_PYTHONFSENCODING_is_used?=
In-Reply-To: <1286414733.34.0.0267403088134.issue10039@psf.upfronthosting.co.za>
Message-ID: <1287008421.49.0.852951731666.issue10039@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r85430 (remove PYTHONFSENCODING), see #9992.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10039>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:20:25 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 13 Oct 2010 22:20:25 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287008425.96.0.420116285909.issue10093@psf.upfronthosting.co.za>


Jean-Paul Calderone <invalid at example.invalid> added the comment:

If the warnings are emitted as usual with the warnings module, you can use -W to control this.  -X isn't necessary.

----------
nosy: +exarkun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:20:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 22:20:26 +0000
Subject: [issue10014] sys.path[0] is incorrect if PYTHONFSENCODING is used
In-Reply-To: <1286021663.34.0.689026258035.issue10014@psf.upfronthosting.co.za>
Message-ID: <1287008426.96.0.674240948481.issue10014@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r85430 (remove PYTHONFSENCODING), see #9992.

----------
resolution:  -> fixed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10014>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:22:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 22:22:05 +0000
Subject: [issue9988] test_warnings fails with PYTHONFSENCODING=latin-1 on
	UNIX/BSD
In-Reply-To: <1285781003.02.0.409003653893.issue9988@psf.upfronthosting.co.za>
Message-ID: <1287008525.0.0.549549035101.issue9988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r85430 (remove PYTHONFSENCODING), see #9992.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9988>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:23:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 22:23:56 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1287008636.09.0.707008001023.issue4388@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

This issue should be fixed by r85435 (OSX: decode command line arguments from utf-8), see #9992.

I will watch for the OSX buildbots.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:25:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 22:25:10 +0000
Subject: [issue10014] sys.path[0] is incorrect if PYTHONFSENCODING is used
In-Reply-To: <1286021663.34.0.689026258035.issue10014@psf.upfronthosting.co.za>
Message-ID: <1287008710.63.0.192731219109.issue10014@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10014>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:46:22 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 13 Oct 2010 22:46:22 +0000
Subject: [issue10094] test_urllib.py fails in py3k r85440 with RuntimeError
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Running the test suite on py3k r85440, I get the following failure:


======================================================================
ERROR: test_getproxies_environment_keep_no_proxies (__main__.ProxyTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_urllib.py", line 121, in setUp
    for k in os.environ.keys():
  File "/home/barry/projects/python/py3k/Lib/_abcoll.py", line 410, in __iter__
    for key in self._mapping:
  File "/home/barry/projects/python/py3k/Lib/os.py", line 441, in __iter__
    for key in self._data:
RuntimeError: dictionary changed size during iteration

This is consistent (i.e. fails every time) on Ubuntu 10.10 amd64.

----------
components: Library (Lib)
messages: 118598
nosy: barry
priority: normal
severity: normal
status: open
title: test_urllib.py fails in py3k r85440 with RuntimeError
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:49:12 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 13 Oct 2010 22:49:12 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1287010152.4.0.117206534989.issue10049@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

To me, this is more a matter of conceptual completeness than one of practical utility (ala fractions.Fraction). That said, I *have* personally encountered the "I only sometimes want to wrap this code in a CM" situation, so it isn't completely impractical, either. Those two factors are enough to reach my threshold for it being worthwhile to declare "one obvious way to do it" through the contextlib module.

There is a possible alternative approach that may be more intuitive to use and read than nullcontext() though:

@contextmanager
def optional_cm(cm, *, use_cm=True): # See naming note below
    if cm is None or not use_cm:
        yield
    else:
        with cm:
            yield

The OP's original example would then look like:

with optional_cm(transaction):
    ...

I suspect readers would find it far easier to remember what optional_cm does than to learn to recognise the "or nullcontext()" idiom. It also plays better with nested context managers:

with optional_cm(sync_lock), optional_cm(db_transaction), \
     open(fname) as f:
    ...


Naming Note: I nearly suggested "optional_context" as a name for this, but realised that would be subtly misleading (suggesting PEP 377 style functionality that potentially skipped the statement body, rather than the intended semantics of skipping use of the CM)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Thu Oct 14 00:55:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 13 Oct 2010 22:55:20 +0000
Subject: [issue9005] Year range in timetuple
In-Reply-To: <1276660627.85.0.364876080456.issue9005@psf.upfronthosting.co.za>
Message-ID: <1287010520.07.0.0518613241332.issue9005@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r85441.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9005>
_______________________________________

From report at bugs.python.org  Thu Oct 14 01:31:44 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 23:31:44 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1287012704.23.0.695383283591.issue4388@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> This issue should be fixed by r85435 ... 
> I will watch for the OSX buildbots.

I don't know if it fixes the issue, but it introduces a regression. r85442 reverts it.

---

Revert r85435 (and r85440): decode command line arguments from utf-8

Python exits with a fatal error if the command line contains an undecodable argument. PyUnicode_FromString() fails at the first undecodable byte because it calls the error handler, but error handlers are not ready before Python initialization.

---

The problem is to get a function to decode a bytes string from utf-8 in main() (before Python initialization). Possibilities:
 - Use PyUnicode_DecodeUTF8Stateful() and tell it to not call the error handler but exit immediatly (return NULL). Eg. check a flag (function argument or global variable?) to check if we should call the error handler or not
 - Use _Py_char2wchar() and set temporary the locale to an utf-8 locale. The problem is to get an utf-8 locale. Is there an utf-8 locale which is always available?
 - Another solution?

I prefer the _Py_char2wchar() solution because I'm sure that it works before Python initialization.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Thu Oct 14 01:38:24 2010
From: report at bugs.python.org (David Watson)
Date: Wed, 13 Oct 2010 23:38:24 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1287003029.26.0.162346022233.issue9377@psf.upfronthosting.co.za>
Message-ID: <20101013233811.GA10810@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

> platform.system() fails with UnicodeEncodeError on systems that have their computer name set to a name containing non-ascii characters. The implementation of platform.system() uses at some point socket.gethostname() ( see http://www.pasteall.org/16215 for a stacktrace of such usage)

This trace is from a Windows system, where the platform module
uses gethostname() in its cross-platform uname() function, which
platform.system() and various other functions in the module rely
on.  On a Unix system, platform.uname() depends on os.uname()
working, meaning that these functions still fail when the
hostname cannot be decoded, as it is part of os.uname()'s return
value.

Given that os.uname() is a primary source of information about
the platform on Unix systems, this sort of collateral damage from
an undecodable hostname is likely to occur in more places.

> It would be more than great if this error could be fixed. If another 3.1 release is planned, preferrably for that.

If you'd like to try the surrogateescape patches, they ought to
fix this.  The relevant patches are ascii-surrogateescape-2.diff,
try-surrogateescape-first-4.diff and uname-surrogateescape.diff.

----------
title: socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Thu Oct 14 01:39:03 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 23:39:03 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1287013143.52.0.620829014055.issue4388@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

osx_utf8_cmdline.patch: copy of r85435.

----------
Added file: http://bugs.python.org/file19228/osx_utf8_cmdline.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Thu Oct 14 01:52:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 13 Oct 2010 23:52:58 +0000
Subject: [issue10095] Support undecodable filenames in the parser API
In-Reply-To: <1287013978.13.0.815823866511.issue10095@psf.upfronthosting.co.za>
Message-ID: <1287013978.13.0.815823866511.issue10095@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

It looks like the parser API (eg. PyParser_ParseFileFlagsEx, PyParser_ASTFromFile) expects utf-8 filename: err_input() decodes the filename from utf-8. But 

Example in a non-ascii directory (/home/SHARE/SVN/py3k??) and an ascii locale:
----
$ LANG= ./python -c "import inspect"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/home/SHARE/SVN/py3k\xe9\u0141/Lib/inspect.py", line 1
SyntaxError: encoding problem: with BOM
----

The problem occurs in fp_setreadl(): this function reopens the file with the right encoding. But to open the file, the bytes filename is decoded from utf-8 (in strict mode), whereas the filename (in my example) contains surrogates and utf-8 in strict mode rejects surrogates.

To support undecodable filenames in the parser API, we have two solutions:

 * Use the filesystem encoding with surrogateescape (PyUnicode_EncodeFSDefault, PyUnicode_DecodeFSDefault)
 * Use utf-8 in another mode: surrogateescape or surrogatepass

The parser API has many public functions, and we have to consider the compatibility with Python 3.1.

See also #9713 and #8611.

----------
components: Interpreter Core, Unicode
messages: 118604
nosy: haypo
priority: normal
severity: normal
status: open
title: Support undecodable filenames in the parser API
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10095>
_______________________________________

From report at bugs.python.org  Thu Oct 14 01:53:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 13 Oct 2010 23:53:28 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287014008.51.0.255001041819.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If the warnings are emitted as usual with the warnings module, you can 
> use -W to control this.

Right. Perhaps we can add a new warning category (e.g. ResourceWarning), or simply reuse RuntimeWarning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 01:54:09 2010
From: report at bugs.python.org (Brian Curtin)
Date: Wed, 13 Oct 2010 23:54:09 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287014049.38.0.17057238373.issue10093@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/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 02:09:22 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 Oct 2010 00:09:22 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287014962.16.0.84926054794.issue10093@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

+1 for RuntimeError.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 02:34:40 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Oct 2010 00:34:40 +0000
Subject: [issue9992] Command-line arguments are not correctly decoded if
	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1287016480.96.0.377009902741.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

test_undecodable_env() of test_subprocess fails. r85430 removes the following code which was added by Antoine to fix this issue.

# Force surrogate-escaping of \xFF in the child process;
# otherwise it can be decoded as-is if the default locale
# is latin-1.
env['PYTHONFSENCODING'] = 'ascii'

I think that we should accept that b'\xff' can be decoded as '\xff' and that's all.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Oct 14 02:41:48 2010
From: report at bugs.python.org (Alex)
Date: Thu, 14 Oct 2010 00:41:48 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287016908.05.0.768656134518.issue10093@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

RuntimeWarning you mean?  I don't think anyone is suggesting making it an error.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 03:00:05 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 Oct 2010 01:00:05 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287016908.05.0.768656134518.issue10093@psf.upfronthosting.co.za>
Message-ID: <AANLkTikYYuRbC3E-RyzLegAPHb=wCUNDG1ZthWXWdcZ5@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/10/13 Alex <report at bugs.python.org>:
>
> Alex <alex.gaynor at gmail.com> added the comment:
>
> RuntimeWarning you mean? ?I don't think anyone is suggesting making it an error.

Indeed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 04:08:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Oct 2010 02:08:07 +0000
Subject: [issue7944] Use the 'with' statement in conjunction with 'open'
	throughout test modules
In-Reply-To: <1266342231.42.0.692171370087.issue7944@psf.upfronthosting.co.za>
Message-ID: <1287022087.37.0.580576521862.issue7944@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Backported test_gzip to to release27-maint in r85446.
Backported test_mailbox to to release27-maint in r85447.
Backported test_bz2 to to release27-maint in r85448.

Fixed test_old_mailbox, the original problem file, in release27-maint in r85449.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7944>
_______________________________________

From report at bugs.python.org  Thu Oct 14 04:26:06 2010
From: report at bugs.python.org (Matt Keeler)
Date: Thu, 14 Oct 2010 02:26:06 +0000
Subject: [issue3482] re.split, re.sub and re.subn should support flags
In-Reply-To: <1217575222.11.0.84305922701.issue3482@psf.upfronthosting.co.za>
Message-ID: <1287023166.35.0.88289873141.issue3482@psf.upfronthosting.co.za>


Matt Keeler <mjkeeler7 at gmail.com> added the comment:

Python 2.7 docs say this was added in 2.7.3.1
Python 3.1 docs say this was added in 3.1

The problem with calling 're.split(pattern, string, re.I)' is that you are using positional arguments only.  If you were to do 're.split(pattern, string, flags=re.I)', that should produce the desired result.

----------
nosy: +mjkeeler7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3482>
_______________________________________

From report at bugs.python.org  Thu Oct 14 07:29:35 2010
From: report at bugs.python.org (Pramod T Sridhar)
Date: Thu, 14 Oct 2010 05:29:35 +0000
Subject: [issue10096] Question regarding python migration
In-Reply-To: <1287034175.54.0.655150007041.issue10096@psf.upfronthosting.co.za>
Message-ID: <1287034175.54.0.655150007041.issue10096@psf.upfronthosting.co.za>


New submission from Pramod T Sridhar <pramod.sridhar at nxp.com>:

Hi All,

We have a Python based test framework which is being used in various projects.

Our current environment is 
Python (ver 2.5.1)
wxPython (wxPython2.8-win32-ansi-2.8.6.0-py25)
pywin32-210.win32-py2.5
vcredist_x86.exe
pyserial-2.2

Our Framework is being currently used in Windows XP.

The issue is:
Soon our environment will be migrated from Windows XP to Windows 7.
In this regard, I would be in need of suggestions/ideas/information
regarding migration of our existing framework into windows 7 environment.

Do i need to migrate our framework from Python 2.5 to either Python 2.6 or directly to Python 3.0 ? What happens to all supporting packages..etc

Which is the best way ?

We tried out of some option of using our framework under virtual xp context of windows 7.Thou it works for timebeing,i am not interested to having the same as kind of way of working for future.

Please help

Many thanks in advance

- Pramod

----------
messages: 118612
nosy: pramod.ts
priority: normal
severity: normal
status: open
title: Question regarding python migration
type: performance
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10096>
_______________________________________

From report at bugs.python.org  Thu Oct 14 07:29:43 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 14 Oct 2010 05:29:43 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1287034183.44.0.999368420226.issue10079@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for creating the patch.  Since it is a feature, it would be considered to be applied to the current py3k branch (which at the moment is what will be going into the 3.2 release) rather than 3.1 which is generally only accepting bug fixes.

By the way, since I was investigating some other issues in IDLE for OS X, I thought it would be interesting to try the code here on the current 3.2. To that end, I did a quick forward port of the patch file, vidle20101012.diff, to the current py3k (3.2) branch.  The results are attached, but need to be thoroughly reviewed.  I simply did a quick test which indicated the patch did not have an impact one way or the other on the other issues so, at the moment, I am not planning to work further on this patch. I am uploading it here in case it might be of use.

Some notes: the 3.2 version of the patch differs because some of the changes in the original patch have already been checked in to py3k; there was another new file missing from the original patch (utils.py) which I pulled in from the vpython.org VIDLE 3.1.2 source patch, and I noticed one line in IOBinding.py that is commented out in the vidle20101012.diff file but not in the vpython.org source (I added a further comment there around line 240).

----------
nosy: +ned.deily
stage:  -> patch review
versions: +Python 3.2 -Python 3.1
Added file: http://bugs.python.org/file19229/issue10079_rebased_for_py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Thu Oct 14 07:36:23 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Oct 2010 05:36:23 +0000
Subject: [issue10096] Question regarding python migration
In-Reply-To: <1287034175.54.0.655150007041.issue10096@psf.upfronthosting.co.za>
Message-ID: <1287034583.19.0.286903125199.issue10096@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Please ask python-list at python.org

Bug tracker is for raising bugs on python.

----------
nosy: +orsenthil
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10096>
_______________________________________

From report at bugs.python.org  Thu Oct 14 08:10:13 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 06:10:13 +0000
Subject: [issue10097] platform.uname gives UnicodeError for non-ASCII computer
	names on Windows
In-Reply-To: <1287036613.43.0.313046805894.issue10097@psf.upfronthosting.co.za>
Message-ID: <1287036613.43.0.313046805894.issue10097@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

Reportedly, platform.uname gives UnicodeError for non-ASCII computer names on Windows, see http://www.pasteall.org/16215

I think it is incorrect that _node uses socket.gethostname on Windows. uname() should return the local hostname (i.e. the one that the system itself believes to have), independent of the network configuration or DNS.

Therefore, I think it should return the COMPUTERNAME environment variable, or the result of the GetComputerName() API.

----------
messages: 118615
nosy: loewis
priority: normal
severity: normal
status: open
title: platform.uname gives UnicodeError for non-ASCII computer names on Windows
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10097>
_______________________________________

From report at bugs.python.org  Thu Oct 14 08:11:12 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Oct 2010 06:11:12 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1287036672.72.0.985656743794.issue10049@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I like your latest suggestion, except for the name.  Given that we also have the (quite generic) "closing", what about just "optional"?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Thu Oct 14 08:12:47 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 06:12:47 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <1287036767.55.0.823137101897.issue9377@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The failure of platform.uname is an independent bug. IMO, it shouldn't use socket.gethostname on Windows, but instead look at the COMPUTERNAME environment variable or call the GetComputerName API function. This is more close to what uname() does on Unix (i.e. retrieve the local machine name independent of DNS).

I have created issue10097 for this bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Thu Oct 14 08:14:11 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Thu, 14 Oct 2010 06:14:11 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1287036851.24.0.325510059404.issue10079@psf.upfronthosting.co.za>


Bruce Sherwood <bruce.sherwood at gmail.com> added the comment:

Thanks for catching the missing utils.py file. I can explain the missing/commented statement in IOBinding.py. I found experimentally that if that statement is present, when you open a file on Windows the first line is off the top of the display, which can be quite confusing; this bug is not present on the Mac, and deleting the statement makes Windows work properly without affecting the Mac. The deletion of the statement was the very last correction Guilherme Polo made, and I got the correction into the patch I submitted but not into a less correct file at vpython.org.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Thu Oct 14 08:28:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 06:28:00 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1287037680.31.0.703440735844.issue4388@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

One solution would be to duplicate the UTF-8 decoder for OSX, incorporating surrogate escape. This should be much shorter than the full UTF-8 codec, and perhaps at least utf8_code_length could be shared.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Thu Oct 14 08:36:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Oct 2010 06:36:19 +0000
Subject: [issue7642] Minor improvement to os.system doc
In-Reply-To: <1262745991.38.0.384719539781.issue7642@psf.upfronthosting.co.za>
Message-ID: <1287038179.04.0.140722232907.issue7642@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Unfortunately, the rewrap makes it much more complicated to see what  the patch changes (i.e. the whole second part of the hunk only adds Windows versions).  Please leave that to the committer in the future.

Otherwise, committed in r85450; I also removed mention of the unsupported Win9x family.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7642>
_______________________________________

From report at bugs.python.org  Thu Oct 14 08:41:54 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Oct 2010 06:41:54 +0000
Subject: [issue3865] explain that profilers should be used for profiling,
	not benchmarking
In-Reply-To: <1221392860.21.0.302367581665.issue3865@psf.upfronthosting.co.za>
Message-ID: <1287038514.8.0.429167498664.issue3865@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Freshed up and committed in r85451.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3865>
_______________________________________

From report at bugs.python.org  Thu Oct 14 08:43:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Oct 2010 06:43:32 +0000
Subject: [issue10046] Correction to atexit documentation
In-Reply-To: <1286487295.44.0.431847380909.issue10046@psf.upfronthosting.co.za>
Message-ID: <1287038612.36.0.538180973139.issue10046@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r85452.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10046>
_______________________________________

From report at bugs.python.org  Thu Oct 14 08:44:25 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 14 Oct 2010 06:44:25 +0000
Subject: [issue7642] Minor improvement to os.system doc
In-Reply-To: <1287038179.04.0.140722232907.issue7642@psf.upfronthosting.co.za>
Message-ID: <AANLkTim6c=d9LAfrxS2ENtOTYEAo5bn0udZg8r=iQNzi@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Thu, Oct 14, 2010 at 08:36, Georg Brandl <report at bugs.python.org> wrote:
>
> Georg Brandl <georg at python.org> added the comment:
>
> Unfortunately, the rewrap makes it much more complicated to see what ?the patch changes (i.e. the whole second part of the hunk only adds Windows versions). ?Please leave that to the committer in the future.

Sorry about that :( I'll just leave a note on the tracker if the
changed paragraphs are in need of wrap (but I guess the committer
would notice anyhow ;) .

> Otherwise, committed in r85450; I also removed mention of the unsupported Win9x family.

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7642>
_______________________________________

From report at bugs.python.org  Thu Oct 14 08:46:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Oct 2010 06:46:19 +0000
Subject: [issue6825] Minor documentation bug with os.path.split
In-Reply-To: <1251923724.11.0.872695091666.issue6825@psf.upfronthosting.co.za>
Message-ID: <1287038779.3.0.893210020037.issue6825@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r85453.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6825>
_______________________________________

From report at bugs.python.org  Thu Oct 14 08:48:56 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Oct 2010 06:48:56 +0000
Subject: [issue9093] Tools/README is out of date
In-Reply-To: <1277658495.23.0.15994230675.issue9093@psf.upfronthosting.co.za>
Message-ID: <1287038936.31.0.997988648847.issue9093@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is indeed fixed already.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 09:00:05 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 14 Oct 2010 07:00:05 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1287039605.55.0.898453068306.issue10049@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> To me, this is more a matter of conceptual completeness 
> than one of practical utility ...

Nick, you don't seem to be truly sold on the need.
I'm -1 on adding this.  It's basically cruft.  If
it were published as an ASPN recipe, its uptake
would be nearly zero.

We need to focus on real problems in the standard 
library and provide solid solutions.  If weight
gets added to the standard lib, it needs to be
selective.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Thu Oct 14 09:02:09 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Oct 2010 07:02:09 +0000
Subject: [issue1710703] zipfile.ZipFile behavior inconsistent.
Message-ID: <1287039729.84.0.128054285382.issue1710703@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Okay, applied as r85455.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1710703>
_______________________________________

From report at bugs.python.org  Thu Oct 14 09:04:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Oct 2010 07:04:25 +0000
Subject: [issue9418] Move _formatter_* methods from string type into _string
	module
In-Reply-To: <1280416899.1.0.0890176421306.issue9418@psf.upfronthosting.co.za>
Message-ID: <1287039865.14.0.778291581846.issue9418@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Okay, committed as 85456.  I'll leave it to you how to proceed from here.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9418>
_______________________________________

From report at bugs.python.org  Thu Oct 14 09:14:47 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Oct 2010 07:14:47 +0000
Subject: [issue9964] Test failures with -OO
In-Reply-To: <1285626420.9.0.187351711939.issue9964@psf.upfronthosting.co.za>
Message-ID: <1287040487.12.0.606672978624.issue9964@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed pdb issue in r85457.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9964>
_______________________________________

From report at bugs.python.org  Thu Oct 14 09:17:01 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 07:17:01 +0000
Subject: [issue10095] Support undecodable filenames in the parser API
In-Reply-To: <1287013978.13.0.815823866511.issue10095@psf.upfronthosting.co.za>
Message-ID: <1287040621.55.0.67360038173.issue10095@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

We shouldn't need to reopen the file in the first place. If we already have a file handle, we can rewind it. Then the encoding of the file name becomes irrelevant.

I keep forgetting: what was the plan for deprecating the FILE* functions in the parser interface? If we need to continue to support them, we could read the whole contents of the file before parsing, and then use the memory-based parsing algorithm.

If parsing files can be fully based on the IO module, we shouldn't even need to rewind the file. Instead, the io module should support switching the encoding mid-stream (unless, say, we are in the middle of a multibyte character - since the parser always asks for complete lines, this should not happen).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10095>
_______________________________________

From report at bugs.python.org  Thu Oct 14 10:13:44 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Thu, 14 Oct 2010 08:13:44 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1287044024.62.0.618605817638.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

I tried to give the 64-bit version a try, but I might have encountered a more general difficulties.
I tested this on Windows 7 Home Premium (Czech), the system is 64-bit (or I've hoped so sofar :-), according to System info: x64-based PC
I installed
Python 2.7 Windows X86-64 installer
from http://www.python.org/download/
which run ok, but the header in the python shell contains "win32"

Python 2.7 (r27:82525, Jul  4 2010, 07:43:08) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.

Consequently, after copying the respecitive files from issue2636-20101009.zip
I get an import error:

>>> import regex
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python_64bit_27\lib\regex.py", line 253, in <module>
    from _regex_core import *
  File "C:\Python_64bit_27\lib\_regex_core.py", line 53, in <module>
    import _regex
ImportError: DLL load failed: %1 nen? platn? aplikace typu Win32.

>>> 

(The last part of the message is a in Czech with broken diacritics:
 %1 is not a valid Win32 type application.)

Is there something I can do in this case? I'd think, the installer would refuse to install a 64-bit software on a 32-bit OS or 32-bit architecture, or am I missing something obvious from the naming peculiarities x64, 64bit etc.?
That being said, I probably don't need to use 64-bit version of python, obviously, it isn't a wide unicode build mentioned earlier, hence
>>> len(u"\U00010333") # is still: 
2
>>>
And I currently don't have special memory requirements, which might be better addressed on a 64-bit system.

If there is something I can do to test regex in this environment, please, let me know;
On the same machine the 32-version is ok:
Python 2.7 (r27:82525, Jul  4 2010, 09:01:59) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import regex
>>>

regards
   vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Oct 14 10:13:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 14 Oct 2010 08:13:48 +0000
Subject: [issue9964] Test failures with -OO
In-Reply-To: <1285626420.9.0.187351711939.issue9964@psf.upfronthosting.co.za>
Message-ID: <1287044028.38.0.363756487784.issue9964@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

r85459 - test_dis
r85460 - test_import
r85461 - test_lib2to3 (bug was in fix_operator)
r85462 - test_xml_etree
r85464 - test_compileall
r85465 - test_cmd_line_script

That should be all of them.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9964>
_______________________________________

From report at bugs.python.org  Thu Oct 14 10:23:21 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 08:23:21 +0000
Subject: [issue9992] Command-line arguments are not correctly decoded if
	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1287044601.57.0.820520373191.issue9992@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I think that we should accept that b'\xff' can be decoded as '\xff' and 
> that's all.

What do you plan to do to fix this failure?

======================================================================
FAIL: test_undecodable_env (test.test_subprocess.POSIXProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/test/test_subprocess.py", line 892, in test_undecodable_env
    self.assertEquals(stdout.decode('ascii'), ascii(value))
AssertionError: "'abc\\xff'" != "'abc\\udcff'"
- 'abc\xff'
?      ^
+ 'abc\udcff'
?      ^^^

http://www.python.org/dev/buildbot/builders/x86%20debian%20parallel%203.x/builds/502/steps/test/logs/stdio

----------
assignee:  -> haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Oct 14 10:34:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 08:34:30 +0000
Subject: [issue10098] intermittent failure in test_os
In-Reply-To: <1287045270.71.0.765573711319.issue10098@psf.upfronthosting.co.za>
Message-ID: <1287045270.71.0.765573711319.issue10098@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The Windows 7 buildbot sometimes shows a failure in test_os:

test test_os failed -- Traceback (most recent call last):
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_os.py", line 1080, in test_CTRL_BREAK_EVENT
    self._kill_with_event(signal.CTRL_BREAK_EVENT, "CTRL_BREAK_EVENT")
  File "D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_os.py", line 1058, in _kill_with_event
    self.fail("subprocess did not stop on {}".format(name))
AssertionError: subprocess did not stop on CTRL_BREAK_EVENT

http://www.python.org/dev/buildbot/3.x.stable/builders/x86%20Windows7%203.x/builds/1755/steps/test/logs/stdio

----------
components: Tests, Windows
messages: 118634
nosy: brian.curtin, db3l, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: intermittent failure in test_os
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10098>
_______________________________________

From report at bugs.python.org  Thu Oct 14 10:38:29 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Oct 2010 08:38:29 +0000
Subject: [issue10097] platform.uname gives UnicodeError for non-ASCII
	computer	names on Windows
In-Reply-To: <1287036613.43.0.313046805894.issue10097@psf.upfronthosting.co.za>
Message-ID: <4CB6C181.6070109@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> New submission from Martin v. L?wis <martin at v.loewis.de>:
> 
> Reportedly, platform.uname gives UnicodeError for non-ASCII computer names on Windows, see http://www.pasteall.org/16215
> 
> I think it is incorrect that _node uses socket.gethostname on Windows. uname() should return the local hostname (i.e. the one that the system itself believes to have), independent of the network configuration or DNS.
> 
> Therefore, I think it should return the COMPUTERNAME environment variable, or the result of the GetComputerName() API.

There are two issues here:

1. socket.gethostname() shouldn't raise an error on Windows, but
   return the Unicode host name

2. COMPUTERNAME returns an uppercase version of the host name (which we
   could lowercase to stay b/w compatible), however I'm not sure
   whether this is the same as the socket.gethostname() or the
   NETBIOS name and I'm also not sure whether this is always set.

   This link suggests that it's using the NetBIOS name:
   http://www.scriptlogic.com/support/CustomScripts/environmentVariableReference.html

   The official Microsoft page is unclear about this:
   http://technet.microsoft.com/en-gb/library/bb490954.aspx

Could someone please check whether using the environment
variable COMPUTERNAME would work in the described case ?

What we could do is use the socket.gethostname() and fall back
to COMPUTERNAME in case of decoding problems.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------
nosy: +lemburg
title: platform.uname gives UnicodeError for non-ASCII computer names on Windows -> platform.uname gives UnicodeError for non-ASCII computer	names on Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10097>
_______________________________________

From report at bugs.python.org  Thu Oct 14 10:41:46 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 08:41: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: <1287045706.08.0.746049932049.issue2636@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Vlastil, what makes you think that issue2636-20101009.zip is a 64-bit version? I can only find 32-bit DLLs in it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Oct 14 10:42:45 2010
From: report at bugs.python.org (=?utf-8?q?K=C3=A1lm=C3=A1n_Gergely?=)
Date: Thu, 14 Oct 2010 08:42:45 +0000
Subject: [issue10099] socket.fromfd() documentation problem
In-Reply-To: <1287045765.45.0.437204596645.issue10099@psf.upfronthosting.co.za>
Message-ID: <1287045765.45.0.437204596645.issue10099@psf.upfronthosting.co.za>


New submission from K?lm?n Gergely <kalman.gergely at duodecad.hu>:

socket.fromfd()'s behaviour is somewhat counter-intutive and should contain a note to warn the user that it'll leave the original FD open. This is important if someone forgets to manually close the file descriptor as it might lead to FD leaks (and kernel memory leaks). This is especially the case when there is no python object associated with the FD, so no destruction will take place.

patch applies to this:
http://docs.python.org/py3k/archives/python-3.1.2-docs-html.tar.bz2

The only thing it does is that it adds a note section with the following message: "The original file descriptor will not be closed."

synapse

----------
assignee: docs at python
components: Documentation
files: fromfd_doc.patch
keywords: patch
messages: 118637
nosy: docs at python, synapse
priority: normal
severity: normal
status: open
title: socket.fromfd() documentation problem
type: feature request
versions: Python 3.1
Added file: http://bugs.python.org/file19230/fromfd_doc.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10099>
_______________________________________

From report at bugs.python.org  Thu Oct 14 10:44:37 2010
From: report at bugs.python.org (=?utf-8?q?K=C3=A1lm=C3=A1n_Gergely?=)
Date: Thu, 14 Oct 2010 08:44:37 +0000
Subject: [issue10099] socket.fromfd() documentation problem
In-Reply-To: <1287045765.45.0.437204596645.issue10099@psf.upfronthosting.co.za>
Message-ID: <1287045877.13.0.369182259515.issue10099@psf.upfronthosting.co.za>


K?lm?n Gergely <kalman.gergely at duodecad.hu> added the comment:

Forgot to add that the changes should be applied to all versions if accepted.

synapse

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10099>
_______________________________________

From report at bugs.python.org  Thu Oct 14 10:53:26 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Oct 2010 08:53:26 +0000
Subject: [issue10097] platform.uname gives UnicodeError for non-ASCII
	computer	names on Windows
In-Reply-To: <4CB6C181.6070109@egenix.com>
Message-ID: <4CB6C502.3090202@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Marc-Andre Lemburg wrote:
> 2. COMPUTERNAME returns an uppercase version of the host name (which we
>    could lowercase to stay b/w compatible), however I'm not sure
>    whether this is the same as the socket.gethostname() or the
>    NETBIOS name and I'm also not sure whether this is always set.
> 
>    This link suggests that it's using the NetBIOS name:
>    http://www.scriptlogic.com/support/CustomScripts/environmentVariableReference.html
> 
>    The official Microsoft page is unclear about this:
>    http://technet.microsoft.com/en-gb/library/bb490954.aspx

More evidence that the NetBIOS name is used:

http://msdn.microsoft.com/en-us/library/aa368009(VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms724295(v=VS.85).aspx

One problem with this approach is that changes to the NetBIOS name
are not seen by those APIs and variables, e.g. if the machine
get's an update via DHCP. The other is that NetBIOS itself is
being phased out in favor of DNS names - which socket.gethostname()
returns, so we'd be replacing a new technology with an old one.

http://blogs.technet.com/b/networking/archive/2008/12/16/netbios-browsing-and-windows-server-2008-x64-server-core.aspx

BTW: Why doesn't socket.gethostname() use GetComputerNameEx()
which does support Unicode ?

See http://msdn.microsoft.com/en-us/library/ms724301(v=VS.85).aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10097>
_______________________________________

From report at bugs.python.org  Thu Oct 14 10:55:40 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Thu, 14 Oct 2010 08:55: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: <1287046540.61.0.50817900804.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Well, it seemed to me too,
I happened to read the last post from Matthew, msg118243, in the sense that he made some updates which need testing on a 64 bit system (I am unsure, whether hardware architecture, OS type, python build or something else was meant); but it must have been somehow separated as a new directory in the issue2636-20101009.zip which is not the case.

More generaly, I was somhow confused about the "win32" in the shell header in the mentioned install.
    vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Oct 14 11:03:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 09:03:24 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287047004.92.0.785551233509.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There is a slight issue with warnings, and that's the filtering by module/location. Since these warnings will occur in destructors, they can appear at any point without being related to the code being executed. The "default" filtering method (print the first occurrence of matching warnings for each location where the warning is issued) then is not appropriate; therefore I suggest a separate warning category (ResourceWarning?) for which people can enable different rules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 11:15:42 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 14 Oct 2010 09:15:42 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287047742.61.0.356168286581.issue10093@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/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 11:17:14 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 14 Oct 2010 09:17:14 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287047834.14.0.573232743651.issue10093@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Does this work also for sockets?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 11:20:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 09:20:42 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287048042.98.0.401248412352.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Does this work also for sockets?

Not with the current implementation. I guess this could be added, but then I would have to make the warning method ("_dealloc_warn") public on IO classes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 12:29:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 10:29:52 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287052192.24.0.924641202983.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch using warnings (RuntimeWarning for now) and also warning about unclosed sockets.

----------
Added file: http://bugs.python.org/file19231/deallocwarn2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 12:44:33 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Oct 2010 10:44:33 +0000
Subject: [issue9992] Command-line arguments are not correctly decoded if
	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1287053073.69.0.330892200249.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

With r85466+r85467, the test_undecodable_env (of test_subprocess) uses C locale to get ASCII locale encoding (for the first test, on unicode environment variables). It should have the same effect than env['PYTHONFSENCODING'] = 'ascii': get ASCII as the filesystem encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Oct 14 12:53:09 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 14 Oct 2010 10:53:09 +0000
Subject: [issue10100] fromfd is now available on all platforms
In-Reply-To: <1287053589.11.0.994213576919.issue10100@psf.upfronthosting.co.za>
Message-ID: <1287053589.11.0.994213576919.issue10100@psf.upfronthosting.co.za>


New submission from Daniel Stutzbach <daniel at stutzbachenterprises.com>:

fromfd is marked as Availability: Unix, but in Python 3 it is also available on Windows:

C:\>c:\python31\python.exe
Python 3.1 (r31:73574, Jun 26 2009, 20:21:35) [MSC v.1500 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import socket
>>> socket.fromfd
<function fromfd at 0x00B9FBB8>

The following lines can also be removed from testFromFd:

        if not hasattr(socket, "fromfd"):
            return # On Windows, this doesn't exist

----------
assignee: docs at python
components: Documentation
messages: 118646
nosy: docs at python, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: fromfd is now available on all platforms
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10100>
_______________________________________

From report at bugs.python.org  Thu Oct 14 12:53:13 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Thu, 14 Oct 2010 10:53:13 +0000
Subject: [issue10099] socket.fromfd() documentation problem
In-Reply-To: <1287045765.45.0.437204596645.issue10099@psf.upfronthosting.co.za>
Message-ID: <1287053593.62.0.929977269525.issue10099@psf.upfronthosting.co.za>


Changes by Daniel Stutzbach <daniel at stutzbachenterprises.com>:


----------
nosy: +stutzbach

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10099>
_______________________________________

From report at bugs.python.org  Thu Oct 14 12:56:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Oct 2010 10:56:15 +0000
Subject: [issue9992] Command-line arguments are not correctly decoded if
	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1287053775.58.0.749009634019.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Ok, the issue is not complelty fixed ;-)

12:55 < py-bb> build #504 of x86 debian parallel 3.x is complete: Success [build successful]  Build details are at 
               http://www.python.org/dev/buildbot/all/builders/x86%20debian%20parallel%203.x/builds/504

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Oct 14 12:59:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Oct 2010 10:59:29 +0000
Subject: [issue9992] Command-line arguments are not correctly decoded if
	locale and fileystem encodings are different
In-Reply-To: <1285799783.26.0.120724027895.issue9992@psf.upfronthosting.co.za>
Message-ID: <1287053969.08.0.925961768601.issue9992@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tried... "the issue is *now* complelty fixed"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9992>
_______________________________________

From report at bugs.python.org  Thu Oct 14 13:19:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 11:19:06 +0000
Subject: [issue7516] Flag "-3" is silently ignored when running "regrtest.py
	-j2"
In-Reply-To: <1260899271.72.0.110257290528.issue7516@psf.upfronthosting.co.za>
Message-ID: <1287055146.44.0.711864374396.issue7516@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r85471.

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7516>
_______________________________________

From report at bugs.python.org  Thu Oct 14 13:22:40 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Oct 2010 11:22:40 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1276551598.69.0.32913607148.issue8998@psf.upfronthosting.co.za>
Message-ID: <1287055360.18.0.806196401183.issue8998@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I've been in touch with the copyright holders of pyOpenSSL and they all were positive about contributing the code to the PSF under a contributor agreement.

The idea would then be to add the crypto routines to pyOpenSSL and have that added to the stdlib as say openssl package.

So how should we go about this ? Open a new ticket ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Thu Oct 14 13:33:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 11:33:43 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1287055360.18.0.806196401183.issue8998@psf.upfronthosting.co.za>
Message-ID: <1287056015.3343.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I've been in touch with the copyright holders of pyOpenSSL and they
> all were positive about contributing the code to the PSF under a
> contributor agreement.
> So how should we go about this ? Open a new ticket ?

I would like to see public discussion about this, especially in the
light of the ssl module improvements in Python 3.2. It is not obvious
that duplicate APIs in the stdlib are a good idea, especially when they
are not compatible with each other. It also means that the current
pyOpenSSL maintainer (Jean-Paul) should agree to do maintenance directly
in the stdlib rather than in a separate repo.

> The idea would then be to add the crypto routines to pyOpenSSL and
> have that added to the stdlib as say openssl package.

This sounds a bit ridiculous. Why not add the crypto routines directly
to the stdlib?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Thu Oct 14 13:58:22 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Oct 2010 11:58:22 +0000
Subject: [issue10063] file:// scheme will stop accessing via ftp protocol
In-Reply-To: <1286703624.02.0.46805329948.issue10063@psf.upfronthosting.co.za>
Message-ID: <1287057502.13.0.378152234434.issue10063@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Thanks for the comments and feedback.
Fixed this in revision 85475.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10063>
_______________________________________

From report at bugs.python.org  Thu Oct 14 14:05:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 14 Oct 2010 12:05:47 +0000
Subject: [issue10095] Support undecodable filenames in the parser API
In-Reply-To: <1287013978.13.0.815823866511.issue10095@psf.upfronthosting.co.za>
Message-ID: <1287057947.24.0.934485638362.issue10095@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> We shouldn't need to reopen the file in the first place. 
> If we already have a file handle, we can rewind it.
> Then the encoding of the file name becomes irrelevant.

Oh yes, great idea. r85476 implements this solution (use lseek(0) on fileno(tok->fp)). The code path exists but only if filename was NULL. But I don't think that it worked because there was no call to lseek(0).

The commit fixes this issue (LANG= ./python -c "import inspect). I have other issues with "LANG= ./python Lib/test/regrtest.py -v test_pydoc test_traceback" but I think that it is a new (different) issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10095>
_______________________________________

From report at bugs.python.org  Thu Oct 14 14:11:31 2010
From: report at bugs.python.org (Retro)
Date: Thu, 14 Oct 2010 12:11:31 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1287058291.25.0.988609994481.issue2775@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

Can you send my patch and comment to python-dev? Because I don't know how to. I don't know where is python-dev and what exactly you mean by this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Thu Oct 14 14:18:06 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Oct 2010 12:18:06 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1287056015.3343.3.camel@localhost.localdomain>
Message-ID: <4CB6F4FB.6000704@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> I've been in touch with the copyright holders of pyOpenSSL and they
>> all were positive about contributing the code to the PSF under a
>> contributor agreement.
>> So how should we go about this ? Open a new ticket ?
> 
> I would like to see public discussion about this, especially in the
> light of the ssl module improvements in Python 3.2. It is not obvious
> that duplicate APIs in the stdlib are a good idea, especially when they
> are not compatible with each other. It also means that the current
> pyOpenSSL maintainer (Jean-Paul) should agree to do maintenance directly
> in the stdlib rather than in a separate repo.
> 
>> The idea would then be to add the crypto routines to pyOpenSSL and
>> have that added to the stdlib as say openssl package.
> 
> This sounds a bit ridiculous. Why not add the crypto routines directly
> to the stdlib?

To make those routines available to a broader audience and to
get more user feedback.

I don't think we can add pyOpenSSL to Python 3.2, so it's better
to use the available time to hash out the details outside the
stdlib. Once it's in the stdlib, changing APIs is very difficult.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Thu Oct 14 14:20:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 12:20:39 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <4CB6F4FB.6000704@egenix.com>
Message-ID: <1287058835.3343.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> > This sounds a bit ridiculous. Why not add the crypto routines directly
> > to the stdlib?
> 
> To make those routines available to a broader audience and to
> get more user feedback.

Sure. But it can be any standalone package, not necessarily pyOpenSSL.
Then, if we want to add them to the stdlib, we don't have to pull in the
whole pyOpenSSL package.

> I don't think we can add pyOpenSSL to Python 3.2,

Right, it's too late.

> so it's better
> to use the available time to hash out the details outside the
> stdlib. Once it's in the stdlib, changing APIs is very difficult.

Then I think the discussion about API and process should move to
python-ideas.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Thu Oct 14 14:33:07 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Oct 2010 12:33:07 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <1287058835.3343.5.camel@localhost.localdomain>
Message-ID: <4CB6F87E.2070705@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>>> This sounds a bit ridiculous. Why not add the crypto routines directly
>>> to the stdlib?
>>
>> To make those routines available to a broader audience and to
>> get more user feedback.
> 
> Sure. But it can be any standalone package, not necessarily pyOpenSSL.
> Then, if we want to add them to the stdlib, we don't have to pull in the
> whole pyOpenSSL package.

pyOpenSSL has the advantage of already providing all the other
bits and pieces needed to interface and build against OpenSSL,
so it's a good ecosystem for such a development.

Besides there are already patches available which do add the
ciphers and hashs to pyOpenSSL, so the development could be
sped up by using those as references.

>> I don't think we can add pyOpenSSL to Python 3.2,
> 
> Right, it's too late.
> 
>> so it's better
>> to use the available time to hash out the details outside the
>> stdlib. Once it's in the stdlib, changing APIs is very difficult.
> 
> Then I think the discussion about API and process should move to
> python-ideas.

The APIs should probably be discussed on the Python crypto or
pyOpenSSL list and the discussion about its integration into the
stdlib on either the python-dev or the stdlib list.

https://lists.sourceforge.net/lists/listinfo/pyopenssl-list
http://mail.python.org/mailman/listinfo/python-crypto
http://mail.python.org/mailman/listinfo/python-dev
http://mail.python.org/mailman/listinfo/stdlib-sig

python-ideas is not really meant for such discussions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Thu Oct 14 14:34:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 12:34:53 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <4CB6F87E.2070705@egenix.com>
Message-ID: <1287059688.3343.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The APIs should probably be discussed on the Python crypto or
> pyOpenSSL list and the discussion about its integration into the
> stdlib on either the python-dev or the stdlib list.

If the target goal is stdlib inclusion, the APIs should be discussed on
python-ideas too.

> python-ideas is not really meant for such discussions.

Yes, it is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Thu Oct 14 14:55:18 2010
From: report at bugs.python.org (Retro)
Date: Thu, 14 Oct 2010 12:55:18 +0000
Subject: [issue10101] a bug in built-in function round() ?
In-Reply-To: <1287060918.13.0.131332755047.issue10101@psf.upfronthosting.co.za>
Message-ID: <1287060918.13.0.131332755047.issue10101@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

>>> round(1.255, 2)
1.25

A bug in Python interpreter?


Shold have been:

>>> round(1.255, 2)
1.26

In mathematics, the .5 part is always rounded up, so in the example the .255 should be rounded to .26 so please fix this bug.

----------
components: Library (Lib)
messages: 118659
nosy: Retro
priority: normal
severity: normal
status: open
title: a bug in built-in function round() ?
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10101>
_______________________________________

From report at bugs.python.org  Thu Oct 14 15:16:36 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Oct 2010 13:16:36 +0000
Subject: [issue10065] future_builtins' docstring lacks some functions
In-Reply-To: <1286739108.25.0.226461556953.issue10065@psf.upfronthosting.co.za>
Message-ID: <1287062196.32.0.478624405456.issue10065@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in revision 85479.

----------
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10065>
_______________________________________

From report at bugs.python.org  Thu Oct 14 15:55:53 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 14 Oct 2010 13:55:53 +0000
Subject: [issue10101] a bug in built-in function round() ?
In-Reply-To: <1287060918.13.0.131332755047.issue10101@psf.upfronthosting.co.za>
Message-ID: <1287064553.43.0.496031073981.issue10101@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

No, just a result of the finite machine representation of
floats:

>>> repr(1.255)
'1.2549999999999999'

so the machine representation of 1.255 is actually less
than that value and round() is doing the right thing.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10101>
_______________________________________

From report at bugs.python.org  Thu Oct 14 16:08:05 2010
From: report at bugs.python.org (Kevin Barnhart)
Date: Thu, 14 Oct 2010 14:08:05 +0000
Subject: [issue10102] mktime adding an hour in April (naive struct)?
In-Reply-To: <1287065285.33.0.306092502984.issue10102@psf.upfronthosting.co.za>
Message-ID: <1287065285.33.0.306092502984.issue10102@psf.upfronthosting.co.za>


New submission from Kevin Barnhart <barnburnr at gmail.com>:

Just starting to dabble in the world of time and datetime objects.  I was converting an array of datetime objects to an array of floats via mktime to do some data analysis.  I have ran into an issue where mktime seems to be adding an hour on April 6, 2003.  Attached is an example script which I used to create the below output:

Python version:  (2, 6, 5, 'final', 0)
Epoch:  time.struct_time(tm_year=1970, tm_mon=1, tm_mday=1, tm_hour=0, tm_min=0, tm_sec=0, tm_wday=3, tm_yday=1, tm_isdst=0)
First datetime:  2003-04-06 02:58:17
Second datetime:  2003-04-06 03:13:17
Is first datetime prior to second?:  True
First datetime, time struct: time.struct_time(tm_year=2003, tm_mon=4, tm_mday=6, tm_hour=2, tm_min=58, tm_sec=17, tm_wday=6, tm_yday=96, tm_isdst=-1)
Second datetime, time struct: time.struct_time(tm_year=2003, tm_mon=4, tm_mday=6, tm_hour=3, tm_min=13, tm_sec=17, tm_wday=6, tm_yday=96, tm_isdst=-1)
Is first time struct prior to second?:  True
First timestamp generated by mktime:  1049623097.0
Second timestamp generated by mktime:  1049620397.0
Is first timestamp less than second timestamp?:  False
First recovered datetime:  2003-04-06 03:58:17
Second recovered datetime:  2003-04-06 03:13:17
Is first recovered prior to second recovered?:  False
Is first recovered datetime same as original?:  False
Is second recovered datetime same as original?:  True

----------
files: mktimeissue.py
messages: 118662
nosy: barnburnr
priority: normal
severity: normal
status: open
title: mktime adding an hour in April (naive struct)?
type: behavior
Added file: http://bugs.python.org/file19232/mktimeissue.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10102>
_______________________________________

From report at bugs.python.org  Thu Oct 14 16:31:03 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 14 Oct 2010 14:31:03 +0000
Subject: [issue10101] a bug in built-in function round() ?
In-Reply-To: <1287060918.13.0.131332755047.issue10101@psf.upfronthosting.co.za>
Message-ID: <1287066663.56.0.453980354041.issue10101@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/issue10101>
_______________________________________

From report at bugs.python.org  Thu Oct 14 16:42:36 2010
From: report at bugs.python.org (geremy condra)
Date: Thu, 14 Oct 2010 14:42:36 +0000
Subject: [issue8998] add crypto routines to stdlib
In-Reply-To: <4CB6F87E.2070705@egenix.com>
Message-ID: <AANLkTi=adNK1v4o2uKaLYOEict_hc6Caz+Xz0s-X3sY5@mail.gmail.com>


geremy condra <debatem1 at gmail.com> added the comment:

> Besides there are already patches available which do add the
> ciphers and hashs to pyOpenSSL, so the development could be
> sped up by using those as references.

I don't think that's the case. I admit that development on this has
been very slow (curse you, Real Life!) but it is nearing a release,
and I doubt that this would save any time even if I didn't have to
rewrite half of the keyphrene code.

Geremy Condra

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8998>
_______________________________________

From report at bugs.python.org  Thu Oct 14 16:56:46 2010
From: report at bugs.python.org (Alexander Ljungberg)
Date: Thu, 14 Oct 2010 14:56:46 +0000
Subject: [issue9205] Parent process hanging in multiprocessing if children
	terminate unexpectedly
In-Reply-To: <1278619251.36.0.833806205056.issue9205@psf.upfronthosting.co.za>
Message-ID: <1287068206.34.0.468153216678.issue9205@psf.upfronthosting.co.za>


Changes by Alexander Ljungberg <stillfire at gmail.com>:


----------
nosy: +aljungberg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9205>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:02:03 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Thu, 14 Oct 2010 15:02:03 +0000
Subject: [issue10086] test_sysconfig failure with site-packages
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1287068523.57.0.755996040346.issue10086@psf.upfronthosting.co.za>


Hallvard B Furuseth <h.b.furuseth at usit.uio.no> added the comment:

It's with 'purelib' because my prefix "/site" matches "/site-packages".
This fixes it for me, but maybe you should also assert that
global_path.startswith(os.path.join(base, "")).

--- Lib/test/test_sysconfig.py~	2010-09-20
+++ Lib/test/test_sysconfig.py	2010-10-14
@@ -278 +278 @@ class TestSysConfig(unittest.TestCase):
-            self.assertEquals(user_path, global_path.replace(base, user))
+            self.assertEquals(user_path, global_path.replace(base, user, 1))

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:16:40 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 14 Oct 2010 15:16:40 +0000
Subject: [issue10103] use the SOABI for GNU/kfreeBSD and the GNU Hurd
In-Reply-To: <1287069400.41.0.250908287876.issue10103@psf.upfronthosting.co.za>
Message-ID: <1287069400.41.0.250908287876.issue10103@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

use the SOABI for GNU/kfreeBSD and the GNU Hurd

afaik, the only distribution for GNU/kfreeBSD and the GNU Hurd currently is Debian, and Debian already has this turned on for Linux too.

----------
assignee: doko
components: Build
files: soabi.diff
keywords: needs review, patch
messages: 118665
nosy: doko
priority: normal
severity: normal
status: open
title: use the SOABI for GNU/kfreeBSD and the GNU Hurd
versions: Python 3.2
Added file: http://bugs.python.org/file19233/soabi.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10103>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:18:43 2010
From: report at bugs.python.org (Retro)
Date: Thu, 14 Oct 2010 15:18:43 +0000
Subject: [issue10101] a bug in built-in function round() ?
In-Reply-To: <1287060918.13.0.131332755047.issue10101@psf.upfronthosting.co.za>
Message-ID: <1287069523.11.0.708456115914.issue10101@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

Gee, thanks for the insight. I didn't thought about the fact that binary floating point is so imprecise and can cause the round() to "error" in some situations.

In this case, the representation and the actual value are (way) off. How can that be? There are just 3 decimal numbers (.255) and Python at parsing the float is already off at the third decimal number. I'll never trust round() again. Well, actually I trust round() to do its job well -- it's the binary floating point I'm affraid of!

We must implement the decimal API to the core of Python in order to have precision.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10101>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:18:54 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 14 Oct 2010 15:18:54 +0000
Subject: [issue10103] use the SOABI for GNU/kfreeBSD and the GNU Hurd
In-Reply-To: <1287069400.41.0.250908287876.issue10103@psf.upfronthosting.co.za>
Message-ID: <1287069534.7.0.486676298549.issue10103@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Looks good to me.

----------
nosy: +barry
resolution:  -> accepted

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10103>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:22:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 15:22:39 +0000
Subject: [issue7523] add SOCK_NONBLOCK and SOCK_CLOEXEC to socket module
In-Reply-To: <1260961239.34.0.37704260724.issue7523@psf.upfronthosting.co.za>
Message-ID: <1287069759.79.0.00795481331468.issue7523@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch committed in r85480, thanks!

----------
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7523>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:27:55 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 14 Oct 2010 15:27:55 +0000
Subject: [issue10094] test_urllib.py fails in py3k r85440 with RuntimeError
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1287070075.05.0.613776193842.issue10094@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This may not be a Python bug.

The failure is consistent on all Ubuntu 10.10 machines I've tried, including both i386 and x86_64 platforms.  I've gone back many svn revisions and even pulled down earlier alpha tarballs and the failure is consistent.

This does *not* fail on the one Ubuntu 10.04 x86_64 VM I've tried.  Will try on Debian squeeze next.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:30:22 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Oct 2010 15:30:22 +0000
Subject: [issue10094] test_urllib.py fails in py3k r85440 with RuntimeError
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1287070222.58.0.299969130073.issue10094@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I have seen this in very inconsistent manner.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:35:26 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 14 Oct 2010 15:35:26 +0000
Subject: [issue10094] test_urllib.py fails in py3k r85440 with RuntimeError
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1287070526.83.0.946002567948.issue10094@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Senthil, can you provide any additional information on where/when you've seen this?  AFAICT, test_urllib.py is the only test it shows up, but it's totally consistent.  What OS/platforms have you seen this happen on?  Same test or different one?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:36:15 2010
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 14 Oct 2010 15:36:15 +0000
Subject: [issue10103] use the SOABI for GNU/kfreeBSD and the GNU Hurd
In-Reply-To: <1287069400.41.0.250908287876.issue10103@psf.upfronthosting.co.za>
Message-ID: <1287070575.53.0.344457861657.issue10103@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

checked in, r85481

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10103>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:37:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 14 Oct 2010 15:37:32 +0000
Subject: [issue10102] mktime adding an hour in April (naive struct)?
In-Reply-To: <1287065285.33.0.306092502984.issue10102@psf.upfronthosting.co.za>
Message-ID: <1287070652.68.0.205655495576.issue10102@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like you have just discovered the joys of daylight saving time.  The problem with your example is that datetime(2003,4,6,2,58,17) is not a valid time in your timezone (most likely you are in the US).  In the US, prior to 2007, the clocks moved 1 hour ahead at 2AM on the first Sunday in April. An thus 1:59 AM was followed by 3:00 AM and 2:58:17 never occurred.

See the following link for detailed discussion of these issues:

http://docs.python.org/dev/py3k/library/datetime.html#tzinfo-objects

----------
nosy: +belopolsky
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10102>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:42:32 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Thu, 14 Oct 2010 15:42: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: <1287070952.48.0.17320157943.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

I am not able to build or test a 64-bit version. The update was to the source files to ensure that if it is compiled for 64 bits then the string positions will also be 64-bit.

This change was prompted by a poster who tried to use the re module of a 64-bit Python build on a 30GB memmapped file but found that the string positions were still limited to 32 bits.

It looked like a 64-bit build of the regex module would have the same limitation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:52:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 14 Oct 2010 15:52:25 +0000
Subject: [issue9527] Add aware local time support to datetime module
In-Reply-To: <1281066500.35.0.441616276688.issue9527@psf.upfronthosting.co.za>
Message-ID: <1287071545.82.0.785083925071.issue9527@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Would anyone like to review this? The Rietveld link works (thanks Martin!) and I would like to get some feedback on the python version before I invest effort into coding this in C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9527>
_______________________________________

From report at bugs.python.org  Thu Oct 14 17:58:44 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Oct 2010 15:58:44 +0000
Subject: [issue10098] intermittent failure in test_os
In-Reply-To: <1287045270.71.0.765573711319.issue10098@psf.upfronthosting.co.za>
Message-ID: <1287071924.05.0.404892840294.issue10098@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I've noticed this a few times since r85315. It raises a dialog box saying "The application was unable to start correctly" for some reason.

----------
nosy: +ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10098>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:09:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 16:09:33 +0000
Subject: [issue10104] test_socket failures on Debian unstable
In-Reply-To: <1287072573.8.0.312091305807.issue10104@psf.upfronthosting.co.za>
Message-ID: <1287072573.8.0.312091305807.issue10104@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is following r85480 (issue #7523). It seems the Debian unstable system on one of the buildbots has SOCK_NONBLOCK and SOCK_CLOEXEC, but doesn't support creating sockets using these flags:

======================================================================
ERROR: testInitNonBlocking (test.test_socket.NonBlockingTCPTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_socket.py", line 914, in testInitNonBlocking
    socket.SOCK_NONBLOCK)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/socket.py", line 94, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
socket.error: [Errno 22] Invalid argument

======================================================================
ERROR: test_SOCK_CLOEXEC (test.test_socket.CloexecConstantTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_socket.py", line 1834, in test_SOCK_CLOEXEC
    socket.SOCK_STREAM | socket.SOCK_CLOEXEC)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/socket.py", line 94, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
socket.error: [Errno 22] Invalid argument

======================================================================
ERROR: test_SOCK_NONBLOCK (test.test_socket.NonblockConstantTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/test/test_socket.py", line 1854, in test_SOCK_NONBLOCK
    socket.SOCK_STREAM | socket.SOCK_NONBLOCK)
  File "/home/doko/buildarea/3.x.klose-debian-alpha/build/Lib/socket.py", line 94, in __init__
    _socket.socket.__init__(self, family, type, proto, fileno)
socket.error: [Errno 22] Invalid argument

(full log at http://www.python.org/dev/buildbot/3.x/builders/alpha%20Debian%203.x/builds/258/steps/test/logs/stdio)

----------
components: Tests
keywords: buildbot
messages: 118677
nosy: doko, lekma, nvetoshkin, pitrou
priority: normal
severity: normal
status: open
title: test_socket failures on Debian unstable
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10104>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:16:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Oct 2010 16:16:09 +0000
Subject: [issue10101] a bug in built-in function round() ?
In-Reply-To: <1287060918.13.0.131332755047.issue10101@psf.upfronthosting.co.za>
Message-ID: <1287072969.79.0.749556118075.issue10101@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Maybe something like http://docs.python.org/library/decimal ?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10101>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:16:11 2010
From: report at bugs.python.org (RLS0812)
Date: Thu, 14 Oct 2010 16:16:11 +0000
Subject: [issue10105] Strings failing to print
In-Reply-To: <1287072971.15.0.392234959257.issue10105@psf.upfronthosting.co.za>
Message-ID: <1287072971.15.0.392234959257.issue10105@psf.upfronthosting.co.za>


New submission from RLS0812 <RLS0812 at YAHOO.COM>:

Attempting to print a string fails in 3.1.2, throwing up an "invalid syntax" 
 I included a screen shot with the same codes ran in 2.7 and 3.1.2 .

----------
components: None
files: 3_1_2_bug.jpg
messages: 118679
nosy: RLS0812
priority: normal
severity: normal
status: open
title: Strings failing to print
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file19234/3_1_2_bug.jpg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10105>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:17:57 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 14 Oct 2010 16:17:57 +0000
Subject: [issue10094] test_urllib.py fails with RuntimeError on Ubuntu 10.10
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1287073077.02.0.463071296694.issue10094@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
title: test_urllib.py fails in py3k r85440 with RuntimeError -> test_urllib.py fails with RuntimeError on Ubuntu 10.10

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:20:26 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Thu, 14 Oct 2010 16:20:26 +0000
Subject: [issue10104] test_socket failures on Debian unstable
In-Reply-To: <1287072573.8.0.312091305807.issue10104@psf.upfronthosting.co.za>
Message-ID: <1287073226.12.0.245261066019.issue10104@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

What about kernel version? As far as I know 2.6.27 is minimum requirement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10104>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:21:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Oct 2010 16:21:03 +0000
Subject: [issue10105] Strings failing to print
In-Reply-To: <1287072971.15.0.392234959257.issue10105@psf.upfronthosting.co.za>
Message-ID: <1287073263.7.0.49819046153.issue10105@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

print is a function now.  See for example http://docs.python.org/py3k/whatsnew/3.0

In the future, please copy input and output in your message if it's a few line, else attache a plain text file.  Text beats images.  Thank you!

----------
nosy: +eric.araujo
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10105>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:22:32 2010
From: report at bugs.python.org (Vlastimil Brom)
Date: Thu, 14 Oct 2010 16:22: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: <1287073352.5.0.336683549284.issue2636@psf.upfronthosting.co.za>


Vlastimil Brom <vlastimil.brom at gmail.com> added the comment:

Sorry for the noise,
it seems, I can go back to the 32-bit python for now then...
vbr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:24:36 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 14 Oct 2010 16:24:36 +0000
Subject: [issue7537] test_format fails with -j combined with -v
In-Reply-To: <1261107735.71.0.830554169199.issue7537@psf.upfronthosting.co.za>
Message-ID: <1287073476.04.0.317375007259.issue7537@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Unable to reproduce, here. It seems fixed.

----------
nosy: +haypo
resolution:  -> works for me
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7537>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:26:10 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Thu, 14 Oct 2010 16:26:10 +0000
Subject: [issue10104] test_socket failures on Debian unstable
In-Reply-To: <1287072573.8.0.312091305807.issue10104@psf.upfronthosting.co.za>
Message-ID: <1287073570.37.0.273804678735.issue10104@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Here's the patch from debian's issue http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529920
Patch URL: https://patches.ubuntu.com/by-release/extracted/ubuntu/n/neon27/0.28.4-2/01_runtime_detect_sock_cloexec.dpatch

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10104>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:35:40 2010
From: report at bugs.python.org (S S)
Date: Thu, 14 Oct 2010 16:35:40 +0000
Subject: [issue10106] missing packages
In-Reply-To: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>
Message-ID: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>


New submission from S S <senya72 at gmail.com>:

when trying to install beutifulsoup package on windows xp x86 with python 2.6.6 getting the following error

C:\Python26>python C:\temp\BeautifulSoup-3.0.8.1\setup.py install
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "C:\temp\BeautifulSoup-3.0.8.1\setup.py", line 1, in <module>
    from distutils.core import setup
ImportError: No module named distutils.core


installing the same package with python 2.7 gives a different error about site module missing. 

these errors i am getting with any packages  installs actually.

----------
components: Installation
messages: 118685
nosy: S.S
priority: normal
severity: normal
status: open
title: missing packages
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10106>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:35:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 16:35:50 +0000
Subject: [issue10104] test_socket failures on Debian unstable
In-Reply-To: <1287072573.8.0.312091305807.issue10104@psf.upfronthosting.co.za>
Message-ID: <1287074150.79.0.327857173034.issue10104@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the research. Given that it only happens on Debian unstable, and it only happens if you explicitly use SOCK_{CLOEXEC,NONBLOCK}, I would vote for not adding a workaround until some supported OS also exhibits the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10104>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:39:37 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Thu, 14 Oct 2010 16:39:37 +0000
Subject: [issue10104] test_socket failures on Debian unstable
In-Reply-To: <1287072573.8.0.312091305807.issue10104@psf.upfronthosting.co.za>
Message-ID: <1287074377.26.0.713751421505.issue10104@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Agree.
Already written code won't suffer, new code should be ready to use new linux kernel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10104>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:43:15 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Oct 2010 16:43:15 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1287074595.82.0.253080632437.issue2775@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

No. Best I can do is suggest you perform an internet search on the term as it makes it obvious what python-dev is.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:51:28 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Oct 2010 16:51:28 +0000
Subject: [issue10106] missing packages
In-Reply-To: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>
Message-ID: <1287075088.83.0.0322118637216.issue10106@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Double-check your install. Errors like this typically means that your Python executable is not able to read the standard library files. Either that or something got moved and so the files are not where Python expects them to be.

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10106>
_______________________________________

From report at bugs.python.org  Thu Oct 14 18:54:06 2010
From: report at bugs.python.org (Kevin Barnhart)
Date: Thu, 14 Oct 2010 16:54:06 +0000
Subject: [issue10102] mktime adding an hour in April (naive struct)?
In-Reply-To: <1287065285.33.0.306092502984.issue10102@psf.upfronthosting.co.za>
Message-ID: <1287075246.62.0.498323409883.issue10102@psf.upfronthosting.co.za>


Kevin Barnhart <barnburnr at gmail.com> added the comment:

Wow.  Should have caught that.  Thanks for the response.

Kevin

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10102>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:02:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 17:02:04 +0000
Subject: [issue10097] platform.uname gives UnicodeError for non-ASCII
	computer	names on Windows
In-Reply-To: <4CB6C181.6070109@egenix.com>
Message-ID: <4CB73789.2010007@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> There are two issues here:

There are two issues, but not here :-)

> 1. socket.gethostname() shouldn't raise an error on Windows, but
>    return the Unicode host name

This is issue 9377, please keep that out of this issue.

> Could someone please check whether using the environment
> variable COMPUTERNAME would work in the described case ?

No - I didn't personally encounter the problem.

> What we could do is use the socket.gethostname() and fall back
> to COMPUTERNAME in case of decoding problems.

I think using socket.gethostname() is conceptually wrong: the
what uname returns is *not* the name the machine has in DNS,
but what is configured in the kernel.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10097>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:03:29 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Thu, 14 Oct 2010 17:03:29 +0000
Subject: [issue10101] a bug in built-in function round() ?
In-Reply-To: <1287069523.11.0.708456115914.issue10101@psf.upfronthosting.co.za>
Message-ID: <19639.14300.875478.466702@montanaro.dyndns.org>


Skip Montanaro <skip at pobox.com> added the comment:

Retro> I didn't thought about the fact that binary floating point is so
    Retro> imprecise and can cause the round() to "error" in some
    Retro> situations.

Details on the limitations of floating point arithmetic are here:

    http://docs.python.org/tutorial/floatingpoint.html

Skip

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10101>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:07:38 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 14 Oct 2010 17:07:38 +0000
Subject: [issue9183] Intern UTC timezone
In-Reply-To: <1278453353.29.0.0260229757511.issue9183@psf.upfronthosting.co.za>
Message-ID: <1287076058.09.0.0156314488415.issue9183@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r85485.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9183>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:15:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 17:15:04 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <1287076504.72.0.973773564959.issue9377@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As a further note: I think socket.gethostname() is a special case, since this is just about a local setting (i.e. not related to DNS). We should then assume that it is encoded in the locale encoding (in particular, that it is encoded in mbcs on Windows).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:15:34 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 17:15:34 +0000
Subject: [issue10097] platform.uname gives UnicodeError for non-ASCII
	computer	names on Windows
In-Reply-To: <4CB6C502.3090202@egenix.com>
Message-ID: <4CB73AB2.1010901@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> More evidence that the NetBIOS name is used:
> 
> http://msdn.microsoft.com/en-us/library/aa368009(VS.85).aspx
> http://msdn.microsoft.com/en-us/library/ms724295(v=VS.85).aspx
> 
> One problem with this approach is that changes to the NetBIOS name
> are not seen by those APIs and variables, e.g. if the machine
> get's an update via DHCP. The other is that NetBIOS itself is
> being phased out in favor of DNS names - which socket.gethostname()
> returns, so we'd be replacing a new technology with an old one.

I think you misunderstand. It's not that this API returns the NetBIOS
name, but that NetBIOS really uses the same name that people understand
as their "computer name".

It's incorrect to use DNS names when implementing platform.uname():
on POSIX, uname() *also* does not return the DNS name. If you want
some API to return the DNS name of the computer, you need a different
function (e.g. socket.getfqdn()).

> BTW: Why doesn't socket.gethostname() use GetComputerNameEx()
> which does support Unicode ?

gethostname was specified by Berkeley Unix (4.2BSD specifically).
Microsoft can't just change the signature of the function.

If you are asking whether Python's socket.gethostname calls
gethostname: because this is the whole point of this function.
It would be very confusing if the function didn't call the
same-named platform API.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10097>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:19:41 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 14 Oct 2010 17:19:41 +0000
Subject: [issue10094] test_urllib.py fails in py3k r85440 with RuntimeError
In-Reply-To: <1287070526.83.0.946002567948.issue10094@psf.upfronthosting.co.za>
Message-ID: <20101014171930.GA13994@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I had seen with test_urllib, but it was inconsistent for me. Sometimes
make distclean and run had worked fine.

This was on Ubuntu 10.04, Intel 64 bit.

It is surprising, if it is seen consistently on Ubuntu 10.10 ( I have
not upgraded to this yet, so have not tried).

----------
title: test_urllib.py fails with RuntimeError on Ubuntu 10.10 -> test_urllib.py fails in py3k r85440 with RuntimeError

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:22:47 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Thu, 14 Oct 2010 17:22:47 +0000
Subject: [issue10107] Quitting IDLE on Mac doesn't save unsaved code
In-Reply-To: <1287076967.07.0.270311596559.issue10107@psf.upfronthosting.co.za>
Message-ID: <1287076967.07.0.270311596559.issue10107@psf.upfronthosting.co.za>


New submission from Bruce Sherwood <bruce.sherwood at gmail.com>:

It has just been discovered that at least since Python 2.6 on the Mac, quitting IDLE does not prompt to save unsaved code, which is then lost. The recently submitted diff for bringing Guilherme Polo's Google Summer of Code improvements into IDLE on Python 3 (ID 10079) does not fix the problem.

----------
components: IDLE
messages: 118697
nosy: Bruce.Sherwood
priority: normal
severity: normal
status: open
title: Quitting IDLE on Mac doesn't save unsaved code
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:32:23 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Thu, 14 Oct 2010 17:32:23 +0000
Subject: [issue8900] IDLE crashes if Preference set to At Startup -> Open Edit
	Window
In-Reply-To: <1275695898.02.0.763223364629.issue8900@psf.upfronthosting.co.za>
Message-ID: <1287077543.25.0.189252890155.issue8900@psf.upfronthosting.co.za>


Bruce Sherwood <bruce.sherwood at gmail.com> added the comment:

Putting print statements in that part of the world shows that the reason why the list.remove fails is that while a ColorDelegator.toggle_colorize_event object is in the list, it has a different memory address than the ColorDelegator.toggle_colorize_event object to be removed. I've seen this NOT fail occasionally (the memory addresses were the same, so the list.remove succeeded), all of which would seem to imply that something has moved in memory.

I'll mention that when the failure occurs, the list always has just one object, a ColorDelegator.toggle_colorize_event object.

----------
nosy: +Bruce.Sherwood

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8900>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:46:52 2010
From: report at bugs.python.org (S S)
Date: Thu, 14 Oct 2010 17:46:52 +0000
Subject: [issue10106] missing packages
In-Reply-To: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>
Message-ID: <1287078412.62.0.0722755921637.issue10106@psf.upfronthosting.co.za>


S S <senya72 at gmail.com> added the comment:

Brett,
the installation did not had any issues.
its running on windows xp, i am administrator of the machine so no permission issues. 

nothing got moved either as it fresh install

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10106>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:54:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 14 Oct 2010 17:54:49 +0000
Subject: [issue4086] support %z format in time.strftime and _strptime?
In-Reply-To: <1223551646.15.0.164355592546.issue4086@psf.upfronthosting.co.za>
Message-ID: <1287078889.04.0.0143429885832.issue4086@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Closing as a duplicate of (closed) issue 6641.

time.strftime appears to support %z on the platforms that support it in C strftime:


>>> time.strftime("%z", time.localtime())
'-0400'

----------
dependencies:  -No obvious and correct way to get the time zone offset
resolution:  -> duplicate
superseder:  -> datetime.strptime doesn't support %z format ?

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4086>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:56:13 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Oct 2010 17:56:13 +0000
Subject: [issue10106] missing packages
In-Reply-To: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>
Message-ID: <1287078973.58.0.300617861093.issue10106@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'm now a Windows user, so there might be a better way to solve this, but...

Run ``python -v`` and see what it says about why 'site' was not imported. You can also verify that site.py is readable by Python by checking that its directory location is listed in sys.path and that you can read the file from the prompt.

Beyond that I am out of my element as it is probably a Windows-specific issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10106>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:56:24 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Oct 2010 17:56:24 +0000
Subject: [issue10106] missing packages
In-Reply-To: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>
Message-ID: <1287078984.45.0.930960541606.issue10106@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
Removed message: http://bugs.python.org/msg118702

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10106>
_______________________________________

From report at bugs.python.org  Thu Oct 14 19:56:34 2010
From: report at bugs.python.org (Brett Cannon)
Date: Thu, 14 Oct 2010 17:56:34 +0000
Subject: [issue10106] missing packages
In-Reply-To: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>
Message-ID: <1287078994.27.0.811380376906.issue10106@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I'm not a Windows user, so there might be a better way to solve this, but...

Run ``python -v`` and see what it says about why 'site' was not imported. You can also verify that site.py is readable by Python by checking that its directory location is listed in sys.path and that you can read the file from the prompt.

Beyond that I am out of my element as it is probably a Windows-specific issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10106>
_______________________________________

From report at bugs.python.org  Thu Oct 14 20:00:02 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 18:00:02 +0000
Subject: [issue10101] a bug in built-in function round() ?
In-Reply-To: <1287060918.13.0.131332755047.issue10101@psf.upfronthosting.co.za>
Message-ID: <1287079202.61.0.362850051882.issue10101@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please note that the error is not in the third decimal position, but only in the 16th (i.e. the difference between the intended value and the actual value is smaller than 0.0000000000000001).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10101>
_______________________________________

From report at bugs.python.org  Thu Oct 14 20:09:12 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 14 Oct 2010 18:09:12 +0000
Subject: [issue10094] test_urllib.py fails in py3k r85440 with RuntimeError
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1287079752.25.0.596134475889.issue10094@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

The problem occurs on Ubuntu 10.10 because there's a new environment variable called $UBUNTU_MENUPROXY in the default user environment.  This is why it suddenly showed up in Python 3.1 and why it does not occur on other OS (even Ubuntu 10.04).

ProxyTests.setUp() conditional is too naive.  Will attach patch, commit and backport.

----------
Added file: http://bugs.python.org/file19235/10094.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Thu Oct 14 20:09:25 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 14 Oct 2010 18:09:25 +0000
Subject: [issue10094] test_urllib.py fails in py3k r85440 with RuntimeError
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1287079765.67.0.758721282965.issue10094@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Thu Oct 14 20:14:12 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 14 Oct 2010 18:14:12 +0000
Subject: [issue10097] platform.uname gives UnicodeError for non-ASCII
	computer	names on Windows
In-Reply-To: <1287036613.43.0.313046805894.issue10097@psf.upfronthosting.co.za>
Message-ID: <1287080052.91.0.813293888215.issue10097@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

>It's incorrect to use DNS names when implementing platform.uname():
>on POSIX, uname() *also* does not return the DNS name. If you want
>some API to return the DNS name of the computer, you need a different
>function (e.g. socket.getfqdn()).

Even more importantly, the computer may have (and these days, usually has) more than one network interface and/or multiple IP addresses bound to a single interface.  Each IP address usually has a unique DNS name, but not necessarily.  In general, there can be no one-to-one mapping of platform name to DNS name.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10097>
_______________________________________

From report at bugs.python.org  Thu Oct 14 20:22:36 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 14 Oct 2010 18:22:36 +0000
Subject: [issue9013] Implement tzinfo.dst() method in timezone
In-Reply-To: <1276711111.49.0.476665122732.issue9013@psf.upfronthosting.co.za>
Message-ID: <1287080556.61.0.808437981727.issue9013@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

After thinking some more about this issue, I am going to withdraw this proposal.  If we want to support storing dst flag in datetime instances, it should be stored in the datetime object itself, not in tzinfo. 

See

http://mail.python.org/pipermail/python-dev/2010-August/102842.html

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9013>
_______________________________________

From report at bugs.python.org  Thu Oct 14 20:22:38 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Oct 2010 18:22:38 +0000
Subject: [issue10097] platform.uname gives UnicodeError for non-ASCII
	computer	names on Windows
In-Reply-To: <4CB73AB2.1010901@v.loewis.de>
Message-ID: <4CB74A6A.3040508@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:
> 
>> More evidence that the NetBIOS name is used:
>>
>> http://msdn.microsoft.com/en-us/library/aa368009(VS.85).aspx
>> http://msdn.microsoft.com/en-us/library/ms724295(v=VS.85).aspx
>>
>> One problem with this approach is that changes to the NetBIOS name
>> are not seen by those APIs and variables, e.g. if the machine
>> get's an update via DHCP. The other is that NetBIOS itself is
>> being phased out in favor of DNS names - which socket.gethostname()
>> returns, so we'd be replacing a new technology with an old one.
> 
> I think you misunderstand. It's not that this API returns the NetBIOS
> name, but that NetBIOS really uses the same name that people understand
> as their "computer name".
> 
> It's incorrect to use DNS names when implementing platform.uname():
> on POSIX, uname() *also* does not return the DNS name. If you want
> some API to return the DNS name of the computer, you need a different
> function (e.g. socket.getfqdn()).

If think you are misunderstanding. The DNS name of a machine *is*
it's node name.

>From the gethostname man page:

   Glibc Notes
       The  GNU  C library implements gethostname() as a library function that calls
       uname(2) and copies up to len bytes from the  returned  nodename  field  into
       name.

>> BTW: Why doesn't socket.gethostname() use GetComputerNameEx()
>> which does support Unicode ?
> 
> gethostname was specified by Berkeley Unix (4.2BSD specifically).
> Microsoft can't just change the signature of the function.
> 
> If you are asking whether Python's socket.gethostname calls
> gethostname: because this is the whole point of this function.
> It would be very confusing if the function didn't call the
> same-named platform API.

The MS API returns the DNS name as Unicode, so you don't into
those encoding in the first place.

I'll close this report as won't fix, since it's not platform.uname()
that needs to be fixed, but socket.gethostname() and that's issue
9377.

I'll copy the URLs to that issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10097>
_______________________________________

From report at bugs.python.org  Thu Oct 14 20:22:53 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Oct 2010 18:22:53 +0000
Subject: [issue10097] platform.uname gives UnicodeError for non-ASCII
	computer	names on Windows
In-Reply-To: <1287036613.43.0.313046805894.issue10097@psf.upfronthosting.co.za>
Message-ID: <1287080573.7.0.191280076515.issue10097@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10097>
_______________________________________

From report at bugs.python.org  Thu Oct 14 20:24:18 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 14 Oct 2010 18:24:18 +0000
Subject: [issue10094] test_urllib.py fails in py3k r85440 with RuntimeError
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1287080658.09.0.0341403373442.issue10094@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Thu Oct 14 20:29:05 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Oct 2010 18:29:05 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <1287080945.04.0.827985557963.issue9377@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Regarding fixing the issue at hand on Windows, I think Python should use the corresponding win32 API for getting the hostname: GetComputerNameEx().

It supports Unicode, so the encoding issue doesn't arise.

See  http://msdn.microsoft.com/en-us/library/ms724301(v=VS.85).aspx for details.

This also solves the platform.uname() issue mentioned here, since the uname() emulation for Windows relies on socket.gethostname() to determine the node name.

FWIW: Glib C does the reverse...

       The  GNU  C library implements gethostname() as a library function that calls
       uname(2) and copies up to len bytes from the  returned  nodename  field  into
       name.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Thu Oct 14 20:29:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 18:29:58 +0000
Subject: [issue10094] test_urllib.py fails in py3k r85440 with RuntimeError
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1287080998.48.0.444228637633.issue10094@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Er, this patch is horrible. You should fix the generic bug, not workaround it on your particular environment. The test still fails with NO_PROXY:

$ NO_PROXY=1 ./python -m test.regrtest test_urllib
[1/1] test_urllib
Warning -- os.environ was modified by test_urllib
test test_urllib failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/test_urllib.py", line 121, in setUp
    for k in os.environ.keys():
  File "/home/antoine/py3k/__svn__/Lib/_abcoll.py", line 410, in __iter__
    for key in self._mapping:
  File "/home/antoine/py3k/__svn__/Lib/os.py", line 441, in __iter__
    for key in self._data:
RuntimeError: dictionary changed size during iteration

----------
assignee:  -> barry
nosy: +pitrou
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Thu Oct 14 20:32:09 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 18:32:09 +0000
Subject: [issue10094] test_urllib.py fails in py3k r85440 with RuntimeError
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1287081129.06.0.188447272338.issue10094@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r85489, please backport.

----------
versions:  -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Thu Oct 14 21:26:11 2010
From: report at bugs.python.org (Tiago Teresa Teodosio)
Date: Thu, 14 Oct 2010 19:26:11 +0000
Subject: [issue8293] HTTPSConnection.close() does not immediately close the
	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1287084371.03.0.0755051211656.issue8293@psf.upfronthosting.co.za>


Tiago Teresa Teodosio <ttt at ist.utl.pt> added the comment:

I can make the connection really get closed by running the garbage collector. It seems that the SSL socket has some kind of lazy close.

import gc
gc.collect()

----------
nosy: +TTT

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8293>
_______________________________________

From report at bugs.python.org  Thu Oct 14 21:43:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 19:43:07 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287085387.45.0.0929814834764.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch adding ResourceWarning, adding new tests, and fixing failures in existing tests.
Feedback welcome.

----------
Added file: http://bugs.python.org/file19236/deallocwarn3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 21:56:01 2010
From: report at bugs.python.org (karl)
Date: Thu, 14 Oct 2010 19:56:01 +0000
Subject: [issue6098] xml.dom.minidom incorrectly claims DOM Level 3 conformance
In-Reply-To: <1243197780.58.0.272636351535.issue6098@psf.upfronthosting.co.za>
Message-ID: <1287086161.23.0.986972928264.issue6098@psf.upfronthosting.co.za>


karl <karl+pythonbugs at la-grange.net> added the comment:

The source of 3.1/lib/python3.1/xml/dom/__init__.py is correct 

===========
minidom -- A simple implementation of the Level 1 DOM with namespace
           support added (based on the Level 2 specification) and other
           minor Level 2 functionality.
===========

Even the level 2  implementation is partial. Some of the Level 3 implementation are based on a 9 April 2002 Working Draft. Comments like these ones are into the code.

# Node interfaces from Level 3 (WD 9 April 2002)

To note that there will be a need for a big code change in xml.dom to implement in the future webdomcore. Maybe a xml.dom.webdomcore would be welcome. http://www.w3.org/TR/domcore/

The request is valid.

----------
nosy: +karlcow

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6098>
_______________________________________

From report at bugs.python.org  Thu Oct 14 22:49:00 2010
From: report at bugs.python.org (Paul Bolle)
Date: Thu, 14 Oct 2010 20:49:00 +0000
Subject: [issue815646] thread unsafe file objects cause crash
Message-ID: <1287089340.09.0.0394862706045.issue815646@psf.upfronthosting.co.za>


Paul Bolle <pebolle at tiscali.nl> added the comment:

0) I ran into some (small) problems with the documentation added by revision 62195. It seems more efficient to reuse this issue to report these. Feel free to ask me to open another issue if that's not appreciated.

1) A small patch that addresses two problems with the current (ie, 2.7) documentation should be attached:
- link three occurrences of "GIL" to the GIL entry in the glossary; and
- add some example code to clarify the usage of PyFile_IncUseCount() andPyFile_DecUseCount().

2) That patch also adds a link to the "Thread State and the Global Interpreter Lock" section to the GIL entry in the Documentation index. That is a separate problem. But fixing that minor problem could also be of help to people (like me) that need to better understand the GIL aspects of those two functions.

----------
nosy: +pebolle
Added file: http://bugs.python.org/file19237/python-2.7-Doc-gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue815646>
_______________________________________

From report at bugs.python.org  Thu Oct 14 23:04:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Oct 2010 21:04:02 +0000
Subject: [issue10066] xmlrpclib does not handle some non-printable characters
	properly
In-Reply-To: <1286813801.19.0.762560466895.issue10066@psf.upfronthosting.co.za>
Message-ID: <1287090242.43.0.334620489168.issue10066@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

My bad, I read too fast.

Peter: Can you rework your patch to address Martin?s review?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10066>
_______________________________________

From report at bugs.python.org  Thu Oct 14 23:17:05 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 14 Oct 2010 21:17:05 +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: <1287091025.44.0.584867082711.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Let's try splitting this issue into separate patches.  This first one just exposes the ABI flags in the sys module and in the python-config script.  It doesn't change any installation behavior.

http://codereview.appspot.com/2478042/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Thu Oct 14 23:27:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Oct 2010 21:27:34 +0000
Subject: [issue9418] Move _formatter_* methods from string type into _string
	module
In-Reply-To: <1280416899.1.0.0890176421306.issue9418@psf.upfronthosting.co.za>
Message-ID: <1287091654.24.0.0623608755672.issue9418@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/issue9418>
_______________________________________

From report at bugs.python.org  Thu Oct 14 23:33:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 21:33:53 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287092033.03.0.00943639569575.issue10093@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file19236/deallocwarn3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 23:34:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 21:34:15 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287092055.05.0.74122137812.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I committed the test fixes to py3k, so here is an updated patch.

----------
Added file: http://bugs.python.org/file19238/deallocwarn3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Thu Oct 14 23:48:32 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Thu, 14 Oct 2010 21:48:32 +0000
Subject: [issue9409] doctest in python2.7 can't handle non-ascii characters
In-Reply-To: <1280366647.79.0.277931146737.issue9409@psf.upfronthosting.co.za>
Message-ID: <1287092912.55.0.351985007306.issue9409@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

Fixed in 2.7 with r85496 and r85501. Thank you.

(in 3.2 only tests, r85495 and r85500)

----------
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9409>
_______________________________________

From report at bugs.python.org  Thu Oct 14 23:48:49 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Oct 2010 21:48:49 +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: <1287092929.94.0.548201221902.issue10027@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Jason, any idea on #2?

----------
nosy: +jaraco

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Thu Oct 14 23:54:30 2010
From: report at bugs.python.org (Leo Shklovskii)
Date: Thu, 14 Oct 2010 21:54:30 +0000
Subject: [issue10108] ExpatError not property wrapped
In-Reply-To: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>
Message-ID: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>


New submission from Leo Shklovskii <leos at thermopylae.net>:

>From my understanding of the documentation, the expected behavior is for xmlrpclib to raise an xmlrpclib.Fault wrapping the original error from whatever parser it chose to use if there's an error in parsing the response.

If, however, its using Expat under the hood and the response is completely blank, the ExpatError percolates up to the calling code unwrapped.

The following stack trace
/usr/lib/python2.6/xmlrpclib.pyc in __call__(self, *args)
   1197         return _Method(self.__send, "%s.%s" % (self.__name, name))
   1198     def __call__(self, *args):
-> 1199         return self.__send(self.__name, args)
   1200
   1201 ##


/usr/lib/python2.6/xmlrpclib.pyc in __request(self, methodname, params)
   1487             self.__handler,
   1488             request,
-> 1489             verbose=self.__verbose
   1490             )
   1491

/usr/lib/python2.6/xmlrpclib.pyc in request(self, host, handler, request_body, verbose)
   1251             sock = None
   1252
-> 1253         return self._parse_response(h.getfile(), sock)
   1254
   1255     ##


/usr/lib/python2.6/xmlrpclib.pyc in _parse_response(self, file, sock)
   1388
   1389         file.close()
-> 1390         p.close()
   1391
   1392         return u.close()

/usr/lib/python2.6/xmlrpclib.pyc in close(self)
    602
    603         def close(self):
--> 604             self._parser.Parse("", 1) # end of data
    605             del self._target, self._parser # get rid of circular references
    606

ExpatError: no element found: line 1, column 0

Please let me know if I'm misinterpreting the docs or if you need any other information to repro this bug.

----------
components: XML
messages: 118721
nosy: leos
priority: normal
severity: normal
status: open
title: ExpatError not property wrapped
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10108>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:08:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 22:08:43 +0000
Subject: [issue10108] ExpatError not property wrapped
In-Reply-To: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>
Message-ID: <4CB77F68.6070802@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> From my understanding of the documentation, the expected behavior
> is for xmlrpclib to raise an xmlrpclib.Fault [...]

What specific wording in the documentation makes you thinks so?

If anything, I'd expect a ResponseError (which appears undocumented).

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10108>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:09:47 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 14 Oct 2010 22:09:47 +0000
Subject: [issue815646] thread unsafe file objects cause crash
Message-ID: <1287094187.85.0.435933199257.issue815646@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Paul, please open a new issue and attach your patch(s) there; it should address issues in 2.7 and 3.2 only.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue815646>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:11:33 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 14 Oct 2010 22:11:33 +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: <1287094293.96.0.708205149208.issue10107@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ned.deily
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:11:57 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 14 Oct 2010 22:11:57 +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: <1287094317.64.0.544929058527.issue10107@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/issue10107>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:15:37 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Thu, 14 Oct 2010 22:15:37 +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: <1287094537.29.0.686712655495.issue10027@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm unsure. I think when I addressed the issue, I was only concerned with symlinks. The Vista behavior sounds correct to me, so it may be that XP was left with the legacy behavior as it doesn't have native symlink support. It sounds as if the behavior on XP should be modified to follow the same technique as in Vista. I don't know when I'll have a moment to look at it in depth, but I'll try to in the next week or two.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:23:11 2010
From: report at bugs.python.org (Leo Shklovskii)
Date: Thu, 14 Oct 2010 22:23:11 +0000
Subject: [issue10108] ExpatError not property wrapped
In-Reply-To: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>
Message-ID: <1287094991.78.0.493262215499.issue10108@psf.upfronthosting.co.za>


Leo Shklovskii <leos at thermopylae.net> added the comment:

Looking at the docs more closely, you're right, I'm not entirely sure what error should come out in that case but my main point with the bug is that the error should be an xmlrpclib error rather than one from the specific parser that its choosing to use.

Should it be a separate bug that ReponseError is undocumented then?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10108>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:24:06 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Oct 2010 22:24:06 +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: <1287095046.23.0.467771448329.issue10107@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:24:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 14 Oct 2010 22:24:47 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1287095087.53.0.358276088454.issue10079@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:32:14 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 14 Oct 2010 22:32:14 +0000
Subject: [issue10108] ExpatError not property wrapped
In-Reply-To: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>
Message-ID: <1287095534.06.0.571656942108.issue10108@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Not necessarily a separate report. Would you be interested in writing a patch that clears that all up (for 2.7 and/or 3.2)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10108>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:40:32 2010
From: report at bugs.python.org (Tom O'Connor)
Date: Thu, 14 Oct 2010 22:40:32 +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: <1287096032.39.0.592707968306.issue10052@psf.upfronthosting.co.za>


Tom O'Connor <ichasepucks at gmail.com> added the comment:

Same problem on SGI IRIX 6.5.28 GCC 3.3.

Adding the following to pyport.h got me through as well.

#define UINT32_MAX 0xffffffff
#define INT32_MAX 0x7fffffff

----------
nosy: +Tom.OConnor

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:43:10 2010
From: report at bugs.python.org (Leo Shklovskii)
Date: Thu, 14 Oct 2010 22:43:10 +0000
Subject: [issue10108] ExpatError not property wrapped
In-Reply-To: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>
Message-ID: <1287096190.81.0.257565924533.issue10108@psf.upfronthosting.co.za>


Leo Shklovskii <leos at thermopylae.net> added the comment:

I'm sorry, I would like to but I don't have the time in the near future. I'm running into this as a secondary symptom of a bigger issue (in our own setup, not in Python) that I'm troubleshooting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10108>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:46:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Oct 2010 22:46:13 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1287096373.62.0.376710683578.issue10079@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/issue10079>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:53:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Oct 2010 22:53:10 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1287096790.44.0.870076204408.issue10089@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Seems like a good idea to me.  Would other VMs have to implement sys.xoptions too?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Fri Oct 15 00:55:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Oct 2010 22:55:03 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1287096790.44.0.870076204408.issue10089@psf.upfronthosting.co.za>
Message-ID: <1287096898.3343.8.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Seems like a good idea to me.  Would other VMs have to implement sys.xoptions too?

I don't think we should mandate that, no.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Fri Oct 15 01:08:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Oct 2010 23:08:07 +0000
Subject: [issue10106] missing packages
In-Reply-To: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>
Message-ID: <1287097687.2.0.172764151107.issue10106@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/issue10106>
_______________________________________

From report at bugs.python.org  Fri Oct 15 01:12:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Oct 2010 23:12:31 +0000
Subject: [issue2919] Merge profile/cProfile in 3.0
In-Reply-To: <1211227334.77.0.551300594218.issue2919@psf.upfronthosting.co.za>
Message-ID: <1287097951.58.0.0879745758246.issue2919@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/issue2919>
_______________________________________

From report at bugs.python.org  Fri Oct 15 01:24:33 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Thu, 14 Oct 2010 23:24:33 +0000
Subject: [issue7425] [PATCH] Improve the robustness of "pydoc -k" in the face
	of broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <1287098673.69.0.672929499999.issue7425@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I notice this issue is in stage "unit test needed".

It's not clear to me how to add a unit test for this: one idea I had is to create a broken module in some subdir somewhere, and invoke "pydoc -k" as a subprocess with PYTHONPATH containing the extra subdir (and assert no traceback seen in stderr of the child).

Does that sound sane?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7425>
_______________________________________

From report at bugs.python.org  Fri Oct 15 01:28:31 2010
From: report at bugs.python.org (karl)
Date: Thu, 14 Oct 2010 23:28:31 +0000
Subject: [issue5762] AttributeError: 'NoneType' object has no attribute
	'replace'
In-Reply-To: <1239798874.6.0.325655580097.issue5762@psf.upfronthosting.co.za>
Message-ID: <1287098911.44.0.0149945785957.issue5762@psf.upfronthosting.co.za>


karl <karl+pythonbugs at la-grange.net> added the comment:

This following markup creates the mistake as described earlier in the comments

<element xmlns="">
<b class="foo" alt=""/>
</element>

This markup doesn't

<element xmlns="bla">
<b class="foo" alt=""/>
</element>

It returns

<?xml version="1.0" ?><element xmlns="bla">
<b alt="" class="foo"/>
</element>

When using this markup

<element bar="">
<b class="foo" alt=""/>
</element>

It outputs the right markup,

<?xml version="1.0" ?><element bar="">
<b alt="" class="foo"/>
</element>

So the mistake occurs really when xmlns="".  I have checked and the following markup is a conformant markup according to the XML specification so xmlns="" or bar="" are conformant on the root element.

<element xmlns="">
<b class="foo" alt=""/>
</element>

XML Namespaces are defined in another specification. http://www.w3.org/TR/REC-xml-names/. In the section of Namespaces default http://www.w3.org/TR/REC-xml-names/#defaulting, The specification is clear.

"The attribute value in a default namespace declaration MAY be empty. This has the same effect, within the scope of the declaration, of there being no default namespace."

the proposed "if data:" earlier in the comment solves the issue. I have attached a unit testcase as required by Mark Lawrence (BreamoreBoy)

----------
keywords: +patch
nosy: +karlcow
Added file: http://bugs.python.org/file19239/test-minidom-xmlns.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5762>
_______________________________________

From report at bugs.python.org  Fri Oct 15 01:30:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Oct 2010 23:30:12 +0000
Subject: [issue9539] python-2.6.4: test failure in test_distutils due to
	linking to system libpython2.6
In-Reply-To: <1281222795.64.0.211558756173.issue9539@psf.upfronthosting.co.za>
Message-ID: <1287099012.57.0.371300072264.issue9539@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If it still exists in 2.6, I don?t think it could be fixed, that version being in security mode now.  (Barry is the release manager, he?ll chime in if I?m wrong.)

Valeo, can you reproduces the bug on 2.7?  Distutils code has been reverted to a prior version recently, which may be the explanation for the apparent fix, but the bug could still exist with distutils2.  Can you clone http://hg.python.org/distutils2/ and run the test suite on your machine?

----------
assignee: tarek -> eric.araujo
components: +Distutils, Distutils2 -Tests
versions: +3rd party, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9539>
_______________________________________

From report at bugs.python.org  Fri Oct 15 01:32:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Oct 2010 23:32:35 +0000
Subject: [issue8335] distutils test_build_ext's test_get_outputs fails in
	bootstrap environment
In-Reply-To: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>
Message-ID: <1287099155.77.0.52438439458.issue8335@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/issue8335>
_______________________________________

From report at bugs.python.org  Fri Oct 15 01:35:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 14 Oct 2010 23:35:25 +0000
Subject: [issue9539] python-2.6.4: test failure in test_distutils due to
	linking to system libpython2.6
In-Reply-To: <1281222795.64.0.211558756173.issue9539@psf.upfronthosting.co.za>
Message-ID: <1287099325.05.0.652686161547.issue9539@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Jan, do you think we should close this as a duplicate of #8335?  I?ve just read that one and it looks like the same bug.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9539>
_______________________________________

From report at bugs.python.org  Fri Oct 15 02:31:52 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 15 Oct 2010 00:31:52 +0000
Subject: [issue10106] missing packages
In-Reply-To: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>
Message-ID: <1287102712.94.0.371939853484.issue10106@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10106>
_______________________________________

From report at bugs.python.org  Fri Oct 15 02:45:02 2010
From: report at bugs.python.org (Jeong-Min Lee)
Date: Fri, 15 Oct 2010 00:45:02 +0000
Subject: [issue10109] itertools.product with infinite iterator cause
	MemoryError.
In-Reply-To: <1287103502.64.0.571191585998.issue10109@psf.upfronthosting.co.za>
Message-ID: <1287103502.64.0.571191585998.issue10109@psf.upfronthosting.co.za>


New submission from Jeong-Min Lee <falsetru at gmail.com>:

According to the documentation, itertools.product is equivalent to nested for-loops in a generator expression.
But, itertools.product(itertools.count(2010)) is not.

>>> import itertools
>>> (year for year in itertools.count(2010))
<generator object <genexpr> at 0x026367D8>
>>> itertools.product(itertools.count(2010))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError

----------
components: Library (Lib)
messages: 118735
nosy: falsetru
priority: normal
severity: normal
status: open
title: itertools.product with infinite iterator cause MemoryError.
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10109>
_______________________________________

From report at bugs.python.org  Fri Oct 15 03:25:05 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 15 Oct 2010 01:25:05 +0000
Subject: [issue10110] Queue doesn't recognize it is full after shrinking
	maxsize
In-Reply-To: <1287105905.32.0.568830983004.issue10110@psf.upfronthosting.co.za>
Message-ID: <1287105905.32.0.568830983004.issue10110@psf.upfronthosting.co.za>


New submission from Jason R. Coombs <jaraco at jaraco.com>:

The Queue object has a maxsize parameter and attribute, but due to the test for a full queue, shrinking the maxsize could result in the Queue not recognizing that it is full.

The attached patch (against the Python 3 trunk) demonstrates this limitation with a unit test and fixes the failing test case.

----------
files: shrinking_queue_not_full.patch
keywords: patch
messages: 118736
nosy: jaraco
priority: normal
severity: normal
status: open
title: Queue doesn't recognize it is full after shrinking maxsize
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19240/shrinking_queue_not_full.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10110>
_______________________________________

From report at bugs.python.org  Fri Oct 15 03:25:41 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 15 Oct 2010 01:25:41 +0000
Subject: [issue10109] itertools.product with infinite iterator cause
	MemoryError.
In-Reply-To: <1287103502.64.0.571191585998.issue10109@psf.upfronthosting.co.za>
Message-ID: <1287105941.25.0.560001689723.issue10109@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10109>
_______________________________________

From report at bugs.python.org  Fri Oct 15 04:00:57 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Oct 2010 02:00:57 +0000
Subject: [issue7425] [PATCH] Improve the robustness of "pydoc -k" in the face
	of broken modules
In-Reply-To: <1259786972.24.0.35920903506.issue7425@psf.upfronthosting.co.za>
Message-ID: <1287108057.73.0.260971801249.issue7425@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, and I can't think of any other way to approach it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7425>
_______________________________________

From report at bugs.python.org  Fri Oct 15 05:27:05 2010
From: report at bugs.python.org (Muhammad Alkarouri)
Date: Fri, 15 Oct 2010 03:27:05 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1287113225.65.0.478794069673.issue9980@psf.upfronthosting.co.za>


Muhammad Alkarouri <malkarouri at gmail.com> added the comment:

I cam across another issue that was triggered by the same problem. I am explaining it here though I am not sure if it is going to affect the solution one way or the other.

The issue is explained in the post http://stackoverflow.com/questions/3933851/nan-giving-an-error-depending-on-python-startup

Namely, running the command

float('nan')

on a Python (tested with version 2.6.4) embedded in a Delphi 2009 application gives a EInvalidOp Delphi exception.

The solution as given in the link is to change the FPY control word (and revert it back when done).

The issue is important because it may break unexpected Python code. In my case, it broke the command

import json

because of the line

NaN, PosInf, NegInf = float('nan'), float('inf'), float('-inf')

in json.decoder. I have no idea what else may break in the standard library.

The reason I bring this up here is because the problem with the mismatch in FPU control world expectations between Delphi and Python is not localised. Given that the behaviour of float('nan') is assumed to be guaranteed by library developers (see PEP 754), this may come up anywhere.

----------
nosy: +Muhammad.Alkarouri

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Fri Oct 15 07:36:25 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Oct 2010 05:36:25 +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: <1287120985.75.0.77448594097.issue10107@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The problem is that, by default on OS X, Tkinter uses Tk/Aqua which is itself a bona-fide OS X application and it creates the default menu options including a standard application quit.  Looks like IDLE needs to register a hook provided by Tk/Aqua for a "quit" callback.  (See http://permalink.gmane.org/gmane.comp.python.tkinter/1857).  I'm working on a patch for it.

----------
assignee:  -> ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Fri Oct 15 07:52:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 15 Oct 2010 05:52:06 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1287121926.33.0.377767099778.issue9980@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Interesting. I'd like to propose than that this is resolved as "won't fix", i.e. embedding Python into Delphi is declared as just not supported (or using floating-point operations in such an environment is not supported).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Fri Oct 15 08:28:15 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 15 Oct 2010 06:28:15 +0000
Subject: [issue10076] Regex objects became uncopyable in 2.5
In-Reply-To: <1286916324.24.0.772801528988.issue10076@psf.upfronthosting.co.za>
Message-ID: <1287124095.29.0.567749023168.issue10076@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The patch looks reasonable to me.

I was trying to find out why they got disabled after 2.5, but I don't see any reason. (There was an issue open and it was closed for no reason). So, I think, this should move forward, unless there is any technical objection to the patch.

----------
nosy: +orsenthil, pitrou
stage:  -> patch review
superseder:  -> MatchObjects not deepcopy()able
versions: +Python 3.1 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10076>
_______________________________________

From report at bugs.python.org  Fri Oct 15 08:50:08 2010
From: report at bugs.python.org (Paul Bolle)
Date: Fri, 15 Oct 2010 06:50:08 +0000
Subject: [issue10111] Minor problems with PyFileObject documentation
	(Doc/c-api/file.rst)
In-Reply-To: <1287125408.14.0.853619758536.issue10111@psf.upfronthosting.co.za>
Message-ID: <1287125408.14.0.853619758536.issue10111@psf.upfronthosting.co.za>


New submission from Paul Bolle <pebolle at tiscali.nl>:

0) I ran into some (small) problems with the documentation added by revision 62195 (see issue 815646 for background).

1) A small patch that addresses two problems with the Python 2.7 documentation should be attached:
- link three occurrences of "GIL" to the GIL entry in the glossary; and
- add some example code to clarify the usage of PyFile_IncUseCount() andPyFile_DecUseCount().

2) That patch also adds a link to the "Thread State and the Global Interpreter Lock" section to the GIL entry in the Documentation index. That is a separate problem. But fixing that minor problem could also be of help to people (like me) that need to better understand the GIL aspects of those two functions.

----------
assignee: docs at python
components: Documentation
files: python-2.7-Doc-gil.patch
keywords: patch
messages: 118742
nosy: docs at python, pebolle
priority: normal
severity: normal
status: open
title: Minor problems with PyFileObject documentation (Doc/c-api/file.rst)
versions: Python 2.7
Added file: http://bugs.python.org/file19241/python-2.7-Doc-gil.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10111>
_______________________________________

From report at bugs.python.org  Fri Oct 15 08:52:42 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 15 Oct 2010 06:52:42 +0000
Subject: [issue10100] fromfd is now available on all platforms
In-Reply-To: <1287053589.11.0.994213576919.issue10100@psf.upfronthosting.co.za>
Message-ID: <1287125562.29.0.936168350795.issue10100@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

You already changed the test in r84449!
The doc still needs updating.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10100>
_______________________________________

From report at bugs.python.org  Fri Oct 15 08:54:53 2010
From: report at bugs.python.org (Paul Bolle)
Date: Fri, 15 Oct 2010 06:54:53 +0000
Subject: [issue815646] thread unsafe file objects cause crash
Message-ID: <1287125693.49.0.794301111899.issue815646@psf.upfronthosting.co.za>


Paul Bolle <pebolle at tiscali.nl> added the comment:

> please open a new issue and attach your patch(s) there

Issue 10111 now tracks the documentation problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue815646>
_______________________________________

From report at bugs.python.org  Fri Oct 15 09:11:51 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 15 Oct 2010 07:11:51 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1287126711.97.0.387403352296.issue10089@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Why wouldn't they? A standard way to extend the command line options seems useful in all environments.
Now the interpretation of these options are subject to variations of course...

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From orsenthil at gmail.com  Fri Oct 15 09:18:11 2010
From: orsenthil at gmail.com (Senthil Kumaran)
Date: Fri, 15 Oct 2010 12:48:11 +0530
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
References: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
	<1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <20101015071811.GC14818@remy>

On Wed, Oct 13, 2010 at 07:01:40PM +0000, Antoine Pitrou wrote:
> $ ./python -Xa,b=c,d -Xe,f=g=h -c "import sys; print(sys.xoptions)"
> {'a': True, 'b': 'c', 'e': True, 'd': True, 'f': 'g=h'}

Docs should be updated too. I see that the values could either be True
or a string? Would this be perceived as a limitation?

From report at bugs.python.org  Fri Oct 15 09:18:21 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 15 Oct 2010 07:18:21 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <20101015071811.GC14818@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Wed, Oct 13, 2010 at 07:01:40PM +0000, Antoine Pitrou wrote:
> $ ./python -Xa,b=c,d -Xe,f=g=h -c "import sys; print(sys.xoptions)"
> {'a': True, 'b': 'c', 'e': True, 'd': True, 'f': 'g=h'}

Docs should be updated too. I see that the values could either be True
or a string? Would this be perceived as a limitation?

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Fri Oct 15 09:22:29 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 15 Oct 2010 07:22:29 +0000
Subject: [issue10098] intermittent failure in test_os
In-Reply-To: <1287045270.71.0.765573711319.issue10098@psf.upfronthosting.co.za>
Message-ID: <1287127349.8.0.413710583378.issue10098@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

_kill_with_event() does not wait for the subprocess to be ready.
It seems to me that the following test is wrong:
    if m[0] == 0:
It should be "if m[0] == 1", since we want to check that the subprocess updated the shared memory.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10098>
_______________________________________

From report at bugs.python.org  Fri Oct 15 09:29:29 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 15 Oct 2010 07:29:29 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1287127769.7.0.475880877325.issue10089@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Well, the syntax allows to pass either a string value (because it's a substring of the command line), or nothing.

When no value is passed, True seems better than None, because this allows the usage of the get() method::
    x = sys.xoptions.get('a')
or::
    if sys.xoptions.get('a'):
this returns None if the option was not set, True if set to a empty value, and a non-empty string if set to an actual value.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Fri Oct 15 09:43:53 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Oct 2010 07:43:53 +0000
Subject: [issue10110] Queue doesn't recognize it is full after shrinking
	maxsize
In-Reply-To: <1287105905.32.0.568830983004.issue10110@psf.upfronthosting.co.za>
Message-ID: <1287128633.94.0.868531659464.issue10110@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +rhettinger
stage:  -> patch review
versions:  -Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10110>
_______________________________________

From report at bugs.python.org  Fri Oct 15 10:42:40 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Fri, 15 Oct 2010 08:42:40 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1287132160.48.0.588726781101.issue10019@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

+1 to merge simplejson 2.1+ before 3.2 beta 1 (mid-november)

----------
nosy: +flox
resolution:  -> accepted
stage:  -> patch review
type:  -> behavior
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10019>
_______________________________________

From report at bugs.python.org  Fri Oct 15 10:59:49 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 15 Oct 2010 08:59:49 +0000
Subject: [issue10099] socket.fromfd() documentation problem
In-Reply-To: <1287045765.45.0.437204596645.issue10099@psf.upfronthosting.co.za>
Message-ID: <1287133189.07.0.631257704063.issue10099@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I think, the original docs *is* pretty intuitive. It says "Duplicate the file descriptor fd and build a socket object".  No one will think that the this method will close the original fd. Person using this method might of course, explicitly close the original fd in some other part of the code (as he may use it after creating the socket object too).

If at all anything is required, a line may be "The original file descriptor is unaffected", but again that seems redundant to me.

----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10099>
_______________________________________

From report at bugs.python.org  Fri Oct 15 11:02:52 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 15 Oct 2010 09:02:52 +0000
Subject: [issue10100] fromfd is now available on all platforms
In-Reply-To: <1287053589.11.0.994213576919.issue10100@psf.upfronthosting.co.za>
Message-ID: <1287133372.07.0.589189996487.issue10100@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Docs changed committed in revision 85514.

----------
nosy: +orsenthil
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10100>
_______________________________________

From report at bugs.python.org  Fri Oct 15 11:04:30 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 15 Oct 2010 09:04:30 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1287133470.53.0.494495638585.issue10089@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I suggest using sys._xoptions to make it clearer that this is for CPython specific internal implementation runtime tweaks. We're putting it in sys so *we* can get at it, not applications.

(It also makes it clear that other implementations aren't obliged to implement *any* particular interface to the -X options. Requiring that would go against the whole spirit of -X)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Fri Oct 15 11:14:25 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 15 Oct 2010 09:14:25 +0000
Subject: [issue10106] missing packages
In-Reply-To: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>
Message-ID: <1287134065.19.0.154441752638.issue10106@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

I would suggest to OP, to take it with python-help for the problem to be fixed. It's raised on python26 as well. Highly unlikely that anything is wrong with Python installation here. Marking it invalid and closing it.

----------
nosy: +orsenthil
resolution:  -> invalid
stage:  -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10106>
_______________________________________

From report at bugs.python.org  Fri Oct 15 11:17:29 2010
From: report at bugs.python.org (=?utf-8?q?Gergely_K=C3=A1lm=C3=A1n?=)
Date: Fri, 15 Oct 2010 09:17:29 +0000
Subject: [issue10099] socket.fromfd() documentation problem
In-Reply-To: <1287045765.45.0.437204596645.issue10099@psf.upfronthosting.co.za>
Message-ID: <1287134249.94.0.837599769533.issue10099@psf.upfronthosting.co.za>


Gergely K?lm?n <kalman.gergely at duodecad.hu> added the comment:

You are perfectly right, the docs are pretty clear. Although fromfd means (or at least to me) to "attach object to fd" and not "duplicate then attach to the duplicate". If someone forgets this particular behaviour and thinks that the function works as the name implies they're in trouble.

Gergely Kalman

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10099>
_______________________________________

From report at bugs.python.org  Fri Oct 15 11:43:47 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 15 Oct 2010 09:43:47 +0000
Subject: [issue10099] socket.fromfd() documentation problem
In-Reply-To: <1287045765.45.0.437204596645.issue10099@psf.upfronthosting.co.za>
Message-ID: <1287135827.68.0.753412957838.issue10099@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

So, I assume that we just leave it as such and close the issue.
I was thinking if anything needs to be updated for function __doc__ but even there 'the duplicate' word is explained.

----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10099>
_______________________________________

From report at bugs.python.org  Fri Oct 15 12:11:32 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 15 Oct 2010 10:11:32 +0000
Subject: [issue10107] Quitting IDLE on Mac doesn't save unsaved code
In-Reply-To: <1287076967.07.0.270311596559.issue10107@psf.upfronthosting.co.za>
Message-ID: <1287137492.92.0.602556435045.issue10107@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Fri Oct 15 12:13:50 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 10:13:50 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1287137630.99.0.191255614883.issue10079@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +kbk

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Fri Oct 15 12:16:25 2010
From: report at bugs.python.org (Jan Kratochvil)
Date: Fri, 15 Oct 2010 10:16:25 +0000
Subject: [issue10112] Use -Wl, --dynamic-list=x.list,
	not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>


New submission from Jan Kratochvil <jan.kratochvil at redhat.com>:

FSF GDB (and future Fedora GDBs) became 250KB smaller than before.  Python recently disabled this GDB build optimization so GDB is 250KB larger again.

-rwxr-xr-x 1 4524488 gdb-7.1-19.fc13.x86_64/usr/bin/gdb
-rwxr-xr-x 1 4266728 gdb-7.1-19dynamiclist.fc13.x86_64/usr/bin/gdb
-rw-r--r-- 1 2364656 gdb-7.1-19.fc13.x86_64.rpm
-rw-r--r-- 1 2274300 gdb-7.1-19dynamiclist.fc13.x86_64.rpm

Some Python binaries/libraries could probably also benefit from smaller pageable code image.

GDB regressed due to /usr/lib*/python*/config/Makefile contains:
  LINKFORSHARED=-Xlinker -export-dynamic

and GDB thus has to use it even for its own link, effectively disabling its:
  -Wl,--dynamic-list=./proc-service.list

AFAIK Python already contains the required exports list but it is used only on MS-Windows.  It should be utilized even for GNU/Linux builds.

----------
components: Library (Lib)
messages: 118756
nosy: dmalcolm, jankratochvil
priority: normal
severity: normal
status: open
title: Use -Wl,--dynamic-list=x.list, not -Xlinker -export-dynamic
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10112>
_______________________________________

From report at bugs.python.org  Fri Oct 15 12:22:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 10:22:03 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1287138123.98.0.156570806097.issue10089@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> (It also makes it clear that other implementations aren't obliged to
> implement *any* particular interface to the -X options. Requiring that 
> would go against the whole spirit of -X)

Agreed. I'll update the patch to use sys._xoptions.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Fri Oct 15 12:57:52 2010
From: report at bugs.python.org (Vladimir Dmitriev)
Date: Fri, 15 Oct 2010 10:57:52 +0000
Subject: [issue10113] UnicodeDecodeError in mimetypes.guess_type on Windows
Message-ID: <1287140272.47.0.635588224312.issue10113@psf.upfronthosting.co.za>


Changes by Vladimir Dmitriev <vldmit at gmail.com>:


----------
components: Library (Lib), Windows
files: mime content types.reg
nosy: vldmit
priority: normal
severity: normal
status: open
title: UnicodeDecodeError in mimetypes.guess_type on Windows
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19242/mime content types.reg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10113>
_______________________________________

From report at bugs.python.org  Fri Oct 15 13:05:05 2010
From: report at bugs.python.org (Vladimir Dmitriev)
Date: Fri, 15 Oct 2010 11:05:05 +0000
Subject: [issue10113] UnicodeDecodeError in mimetypes.guess_type on Windows
In-Reply-To: <1287140705.94.0.131601408046.issue10113@psf.upfronthosting.co.za>
Message-ID: <1287140705.94.0.131601408046.issue10113@psf.upfronthosting.co.za>


New submission from Vladimir Dmitriev <vldmit at gmail.com>:

Windows 7, Python 2.7

Some windows applications (QuickTime) add content-types to Windows registry with non-ascii names. mimetypes in unaware of that and fails with UnicodeDecodeError:

>>> mimetypes.guess_type('test.js')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\Python27\lib\mimetypes.py", line 294, in guess_type
    init()
  File "c:\Python27\lib\mimetypes.py", line 355, in init
    db.read_windows_registry()
  File "c:\Python27\lib\mimetypes.py", line 260, in read_windows_registry
    for ctype in enum_types(mimedb):
  File "c:\Python27\lib\mimetypes.py", line 250, in enum_types
    ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)

Example registry leaf is attached to previous message.

I believe the correct behavior would be either to wrap UnicodeDecodeError exception and skip those content-typer or use .decode() method for registry keys and get encoding using locale.getdefaultlocale()

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10113>
_______________________________________

From report at bugs.python.org  Fri Oct 15 13:10:10 2010
From: report at bugs.python.org (Paul Bolle)
Date: Fri, 15 Oct 2010 11:10:10 +0000
Subject: [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1287141010.82.0.967120384005.issue8340@psf.upfronthosting.co.za>


Changes by Paul Bolle <pebolle at tiscali.nl>:


----------
nosy: +pebolle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8340>
_______________________________________

From report at bugs.python.org  Fri Oct 15 13:49:47 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 15 Oct 2010 11:49:47 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287143387.43.0.196401102846.issue10093@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Please add a similar warning in PC/_subprocess.c::sp_handle_dealloc()
I just got caught by this in PyPy because some pipe handle relies on reference counting to be closed.

This ad-hoc fix would suppress the warning:
   http://codespeak.net/pipermail/pypy-svn/2010-October/043746.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 15 14:04:45 2010
From: report at bugs.python.org (Kiriakos Vlahos)
Date: Fri, 15 Oct 2010 12:04:45 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1287144285.58.0.401049498708.issue9980@psf.upfronthosting.co.za>


Kiriakos Vlahos <pyscripter at gmail.com> added the comment:

I would like to say that these are two separate issues.  One is about the precision flag and the second about the exception masking flags of the FPU control words. Both issues affect a wider number of users than Python embedders using Delphi. For example C# uses 80 bit precision if I understand http://blogs.msdn.com/b/davidnotario/archive/2005/08/08/449092.aspx well.

Also both issues are primarily documentation issues.  If Python libraries make certain assumptions about the state of the FPU control word, these assumptions should be documented and users can then accommodate them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Fri Oct 15 14:25:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 12:25:47 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287143387.43.0.196401102846.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287145543.3347.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Please add a similar warning in PC/_subprocess.c::sp_handle_dealloc()
> I just got caught by this in PyPy because some pipe handle relies on reference counting to be closed.

Do you want to provide a patch?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 15 14:34:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2010 12:34:51 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Example:

$ ./python
Python 3.2a3+ (py3k, Oct 15 2010, 14:31:59) 
>>> compile('', 'abc\uDC80', 'exec')
...
UnicodeEncodeError: 'utf-8' codec can't encode character '\udc80' in position 3: surrogates not allowed

Attached patch encodes manually the filename to utf-8 with surrogateescape.

I found this problem while testing Python with an ASCII locale encoding (LANG=C ./python Lib/test/regrtest.py). Example:

  $ LANG=C ./python -m base64 -e setup.py 
  ...
  UnicodeEncodeError: 'utf-8' codec can't encode character '\udcc3' ...

----------
components: Interpreter Core, Unicode
files: compile_surrogates.patch
keywords: patch
messages: 118762
nosy: haypo
priority: normal
severity: normal
status: open
title: compile() doesn't support the PEP 383 (surrogates)
versions: Python 3.2
Added file: http://bugs.python.org/file19243/compile_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Fri Oct 15 14:43:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Oct 2010 12:43:32 +0000
Subject: [issue8293] HTTPSConnection.close() does not immediately close the
	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1287146612.08.0.425277552334.issue8293@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If I'm reading this thread correctly, this bug should be closed and a new one opened about SSL socket close.  Antoine, does that sound correct?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8293>
_______________________________________

From report at bugs.python.org  Fri Oct 15 14:47:47 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 15 Oct 2010 12:47:47 +0000
Subject: [issue8293] HTTPSConnection.close() does not immediately close the
	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1287146867.48.0.728386276262.issue8293@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/issue8293>
_______________________________________

From report at bugs.python.org  Fri Oct 15 14:52:39 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Oct 2010 12:52:39 +0000
Subject: [issue10113] UnicodeDecodeError in mimetypes.guess_type on Windows
In-Reply-To: <1287140705.94.0.131601408046.issue10113@psf.upfronthosting.co.za>
Message-ID: <1287147159.97.0.108775018023.issue10113@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

This is a duplicate of #9291.

----------
nosy: +r.david.murray
resolution:  -> duplicate
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/issue10113>
_______________________________________

From report at bugs.python.org  Fri Oct 15 14:53:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Oct 2010 12:53:03 +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: <1287147183.17.0.432066446918.issue9291@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +vldmit

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9291>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:03:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 13:03:41 +0000
Subject: [issue8293] HTTPSConnection.close() does not immediately close the
	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1287147821.15.0.904136050072.issue8293@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Probably, yes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8293>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:07:56 2010
From: report at bugs.python.org (Muhammad Alkarouri)
Date: Fri, 15 Oct 2010 13:07:56 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1287121926.33.0.377767099778.issue9980@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=hq_eAY_mkrgktoJDOrQx2rgs9g3sPHquSqnE5@mail.gmail.com>


Muhammad Alkarouri <malkarouri at gmail.com> added the comment:

On 15 October 2010 06:52, Martin v. L?wis <report at bugs.python.org> wrote:
>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Interesting. I'd like to propose than that this is resolved as "won't fix", i.e. embedding Python into Delphi is declared as just not supported (or using floating-point operations in such an environment is not supported).

The problem is defining what does "such an environment" mean. It is
not necessarily Delphi, as this can happen whenever the FPU control
word is changed by an embedding application.
Kiriakos makes a good point. The underlying issue is that Python make
certain assumptions about the FPU control words, and there are
probably other global assumptions lurking elsewhere.
As I see it, the easiest solution is to document these assumptions as
and when they are found. Then it becomes the responsibility of the
hosting application to satisfy them.
Delphi already has to accomodate Python C heritage, for example by
defining functions used from Python with the C calling convention.
This would be just one more thing to remember, and in fact can be done
inside the Python4Delphi libraries once the Python behaviour is
defined and documented.

Also, banning floating-point operations is not a solution in my
opinion because Python libraries (standard and external) do not have
such a distinction. So an unknown of unexpected libraries (like json)
would break. And large parts of Python functionality wouldn't be
available.

On 15 October 2010 13:04, Kiriakos Vlahos?<report at bugs.python.org>?wrote:
>
> Kiriakos Vlahos <pyscripter at gmail.com> added the comment:
>
> I would like to say that these are two separate issues. ?One is about the precision flag and the second about the exception masking flags of the FPU control words. Both issues affect a wider number of users than Python embedders using Delphi. For example C# uses 80 bit precision if I understand?http://blogs.msdn.com/b/davidnotario/archive/2005/08/08/449092.aspx?well.

Technically they are, yes. But they are both affected by any solution
that would incorporate preserving or documenting the FPU control word
for embedding applications. May be I should have opened a new issue.

----------
nosy: +malkarouri

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:23:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 13:23:24 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

When a machine has a newer glibc and an old kernel, accept4 can fail and then Python accept() is unusable. For example:

Traceback (most recent call last):
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/threading.py", line 525, in _bootstrap_inner
    self.run()
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/test/test_asynchat.py", line 37, in run
    conn, client = self.sock.accept()
  File "/home/pybot/buildarea-sid/3.x.klose-debian-sparc/build/Lib/socket.py", line 132, in accept
    fd, addr = self._accept()
socket.error: [Errno 90] Function not implemented

(from http://www.python.org/dev/buildbot/builders/sparc%20Debian%203.x/builds/147/steps/test/logs/stdio )


Improving our configure check wouldn't do a lot of good, since people can reuse Python binaries with different kernels. Perhaps we have to use some kind of runtime fallback.

(Strangely, errno 90 is EMSGSIZE here, and ENOSYS is 38)

----------
components: Extension Modules
messages: 118767
nosy: doko, lekma, nvetoshkin, pitrou
priority: critical
severity: normal
stage: needs patch
status: open
title: accept4 can fail with errno 90
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:29:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 13:29:45 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287149385.1.0.988808172419.issue10115@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Or perhaps we should back out the accept4 change and live with the fact that SOCK_CLOEXEC and SOCK_NONBLOCK can't be inherited by calling accept().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:30:50 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Fri, 15 Oct 2010 13:30:50 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287149450.83.0.292805054985.issue10115@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Falling back on result 90 is not that difficult, I think I can submit a patch today. What should be checked ENOSYS or 90?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:33:57 2010
From: report at bugs.python.org (Kevin Walzer)
Date: Fri, 15 Oct 2010 13:33:57 +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: <1287149637.03.0.983029816576.issue10107@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Try something like this: 

root.createcommand('::tk::mac::Quit', <insert IDLE's shutdown function here>)

This will map whatever function IDLE calls to prompt the user to save data before closing, to the Apple quit event.

----------
nosy: +wordtech

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:39:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 13:39:32 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149450.83.0.292805054985.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287149968.3347.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Falling back on result 90 is not that difficult, I think I can submit
> a patch today. What should be checked ENOSYS or 90?

That's a rather good question. I will enable some debug printout on the
buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:41:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 13:41:07 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287150067.06.0.715662342192.issue10114@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/issue10114>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:44:42 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Fri, 15 Oct 2010 13:44:42 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>


New submission from Stephen Hansen <me+python at ixokai.io>:

Ever since running the snow leopard buildslave, I've had sporadic failures in test_urllibnet. At first I thought it was just a net glitch on my machine or something, as immediately re-running the tests made it go away: but this most recent one:

http://www.python.org/dev//buildbot/builders/x86%20Snow%20Leopard%203.1/builds/20/steps/test/logs/stdio

happened while I was very much monitoring and using the network on the machine for other purposes, and everything was fine in general.

So, I went and looked into test_urllibnet to try to figure out why, and I notice that some of the tests use code to retry on IOErrors, and some don't-- and this test that failed in particular is one that doesn't. 

So: anyone have a better idea of what's going wrong, or is it just that hey, the active network tests are a bit flaky and all should use _open_with_retry instead of just some as is the case now?

[If the latter, I can do a patch]

FWIW, I've only seen this on the 3.1 and 3.x buildslaves, but have seen it on both of those more then once. But I don't know that its a 3.x specific issue: those builds get run more often then the 2.7 one, so have more chances to run into a sporadic issue.

----------
components: Tests
messages: 118772
nosy: ixokai
priority: normal
severity: normal
status: open
title: Sporadic failures in test_urllibnet
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:45:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Oct 2010 13:45:40 +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: <1287150340.96.0.239057506166.issue9291@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/issue9291>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:50:59 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 15 Oct 2010 13:50:59 +0000
Subject: [issue9980] str(float) failure
In-Reply-To: <1285729892.65.0.25912191442.issue9980@psf.upfronthosting.co.za>
Message-ID: <1287150658.99.0.234896634953.issue9980@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> For example C# uses 80 bit precision

No, I don't think that's true.  It uses the x87, with its 64-bit internal precision, but I'm fairly sure that (as is almost always true in a Windows environment, except if you're using Delphi, apparently) the FPU precision is still set to 53-bit precision.

> if I understand http://blogs.msdn.com/b/davidnotario/archive/2005/08/08/449092.aspx well.

And that article explicitly confirms the use of 53-bit precision:

"Precision is set by default in VC++ and CLR apps to ?double precision?, which means that if you are operating with operands of type float, results of operations done with floats actually exist in the x87 stack as if there were of type double. In fact, it?s even weirder than that. They will have the mantissa of a double, but the range (exponent) of an extended double (80 bit)."

i.e., it's using the x87 FPU with precision set to 53 bits.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9980>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:51:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 13:51:27 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1287150687.04.0.232728521756.issue10116@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Rather than the hand-made _open_with_retry, I think it would be better to use support.transient_internet() (it's already used in other tests). Retrying is not very helpful if the other end is down.

Also, EBADF (bad file descriptor) looks like a bug. httplib should not use closed/non-existent file descriptors.

----------
nosy: +orsenthil, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:52:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 13:52:35 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287150755.41.0.244838028905.issue10115@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, 90 is ENOSYS on that buildbot :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Fri Oct 15 15:53:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Oct 2010 13:53:12 +0000
Subject: [issue10108] ExpatError not property wrapped
In-Reply-To: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>
Message-ID: <1287150792.23.0.0973373119122.issue10108@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +docs at python
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10108>
_______________________________________

From report at bugs.python.org  Fri Oct 15 16:00:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Oct 2010 14:00:05 +0000
Subject: [issue10099] socket.fromfd() documentation problem
In-Reply-To: <1287045765.45.0.437204596645.issue10099@psf.upfronthosting.co.za>
Message-ID: <1287151205.86.0.764132667943.issue10099@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution: invalid -> works for me

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10099>
_______________________________________

From report at bugs.python.org  Fri Oct 15 16:04:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Oct 2010 14:04:57 +0000
Subject: [issue10111] Minor problems with PyFileObject documentation
	(Doc/c-api/file.rst)
In-Reply-To: <1287125408.14.0.853619758536.issue10111@psf.upfronthosting.co.za>
Message-ID: <1287151497.79.0.553732756059.issue10111@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/issue10111>
_______________________________________

From report at bugs.python.org  Fri Oct 15 16:09:02 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 15 Oct 2010 14:09:02 +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: <1287151742.26.0.848254693156.issue10107@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Kevin, 

which versions of Tk does this work with?

IDLE should at least work with the versions of Tk 8.4 and 8.5 that Apple ships with OSX 10.4, 10.5 and 10.6 (the last one being the only one with built-in support for Tk 8.5)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Fri Oct 15 16:12:13 2010
From: report at bugs.python.org (Kevin Walzer)
Date: Fri, 15 Oct 2010 14:12:13 +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: <1287151933.87.0.078073480794.issue10107@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

Ronald--I think it works with both 8.4 and 8.5.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Fri Oct 15 16:19:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Oct 2010 14:19:44 +0000
Subject: [issue10109] itertools.product with infinite iterator cause
	MemoryError.
In-Reply-To: <1287103502.64.0.571191585998.issue10109@psf.upfronthosting.co.za>
Message-ID: <1287152384.45.0.936605203448.issue10109@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/issue10109>
_______________________________________

From report at bugs.python.org  Fri Oct 15 16:20:46 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Oct 2010 14:20:46 +0000
Subject: [issue10110] Queue doesn't recognize it is full after shrinking
	maxsize
In-Reply-To: <1287105905.32.0.568830983004.issue10110@psf.upfronthosting.co.za>
Message-ID: <1287152446.73.0.247241406255.issue10110@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/issue10110>
_______________________________________

From report at bugs.python.org  Fri Oct 15 16:23:05 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Oct 2010 14:23:05 +0000
Subject: [issue10098] intermittent failure in test_os
In-Reply-To: <1287045270.71.0.765573711319.issue10098@psf.upfronthosting.co.za>
Message-ID: <1287152585.63.0.327094084433.issue10098@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

That works for me locally. Checked in that 0 to 1 change in r85525 - waiting to see if it works on the slower buildbots.

----------
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10098>
_______________________________________

From report at bugs.python.org  Fri Oct 15 16:26:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Oct 2010 14:26:51 +0000
Subject: [issue10112] Use -Wl, --dynamic-list=x.list,
	not -Xlinker -export-dynamic
In-Reply-To: <1287137785.61.0.962664170792.issue10112@psf.upfronthosting.co.za>
Message-ID: <1287152811.77.0.2295492181.issue10112@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10112>
_______________________________________

From report at bugs.python.org  Fri Oct 15 16:46:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 14:46:57 +0000
Subject: [issue5355] Expat parser error constants are string descriptions
In-Reply-To: <1235432445.32.0.505326147132.issue5355@psf.upfronthosting.co.za>
Message-ID: <1287154017.41.0.512650273815.issue5355@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r85526.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5355>
_______________________________________

From report at bugs.python.org  Fri Oct 15 17:15:08 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 15 Oct 2010 15:15:08 +0000
Subject: [issue5355] Expat parser error constants are string descriptions
In-Reply-To: <1235432445.32.0.505326147132.issue5355@psf.upfronthosting.co.za>
Message-ID: <1287155708.25.0.206523585539.issue5355@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Please, add a tiny unit test for the presence of this feature.
This is the only way for vm implementers to follow CPython development.

----------
nosy: +amaury.forgeotdarc
stage:  -> unit test needed
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5355>
_______________________________________

From report at bugs.python.org  Fri Oct 15 17:23:06 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Fri, 15 Oct 2010 15:23:06 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287156186.98.0.266059993304.issue10115@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

What about exposing accept4() to python level?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Fri Oct 15 17:25:45 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 15:25:45 +0000
Subject: [issue5355] Expat parser error constants are string descriptions
In-Reply-To: <1235432445.32.0.505326147132.issue5355@psf.upfronthosting.co.za>
Message-ID: <1287156345.61.0.0666671901589.issue5355@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You're completely correct, added one in r85528. Thanks!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5355>
_______________________________________

From report at bugs.python.org  Fri Oct 15 17:26:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 15:26:25 +0000
Subject: [issue8340] bytearray undocumented on trunk
In-Reply-To: <1270682579.64.0.491172746908.issue8340@psf.upfronthosting.co.za>
Message-ID: <1287156385.76.0.169967538025.issue8340@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: docs at python -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8340>
_______________________________________

From report at bugs.python.org  Fri Oct 15 17:31:17 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 15:31:17 +0000
Subject: [issue8267] Tutorial section on dictionary keys recommends sort
	instead of sorted
In-Reply-To: <1269976733.25.0.679757604507.issue8267@psf.upfronthosting.co.za>
Message-ID: <1287156677.49.0.662325772558.issue8267@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r85529.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8267>
_______________________________________

From report at bugs.python.org  Fri Oct 15 17:34:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 15:34:17 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287156857.53.0.171830407591.issue10115@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> What about exposing accept4() to python level?

That's another possibility, in which case we would first remove the current accept4-calling code in order to fix the buildbot failure.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Fri Oct 15 17:41:01 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Oct 2010 15:41:01 +0000
Subject: [issue9308] Remove redundant coding cookies from 3.x stdlib
In-Reply-To: <1279565829.31.0.797750861129.issue9308@psf.upfronthosting.co.za>
Message-ID: <1287157261.95.0.161905903937.issue9308@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching an updated patch, issue9308b.diff.  Compared to the "a" patch, I added test/encoded_modules to the makefile so that it gets installed and removed cookies from some more test and Tools files.

----------
Added file: http://bugs.python.org/file19244/issue9308b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9308>
_______________________________________

From report at bugs.python.org  Fri Oct 15 17:49:57 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Oct 2010 15:49:57 +0000
Subject: [issue10110] Queue doesn't recognize it is full after shrinking
	maxsize
In-Reply-To: <1287105905.32.0.568830983004.issue10110@psf.upfronthosting.co.za>
Message-ID: <1287157797.3.0.735228637196.issue10110@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10110>
_______________________________________

From report at bugs.python.org  Fri Oct 15 17:58:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 15:58:02 +0000
Subject: [issue2830] Copy cgi.escape() to html
In-Reply-To: <1210563693.47.0.635782576194.issue2830@psf.upfronthosting.co.za>
Message-ID: <1287158282.19.0.601563043376.issue2830@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Refined and applied the patch in r85531.  Thanks all!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2830>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:02:52 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Fri, 15 Oct 2010 16:02:52 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287158572.75.0.802130262576.issue10115@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Weekend is coming, so I can lend a hand in implementing whatever you choose.

Summary:
  * remove accept4() as default and expose it as separate method
  * add runtime fallback if accept4() returns ENOSYS

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:03:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 16:03:22 +0000
Subject: [issue7771] dict view comparison methods are not documented
In-Reply-To: <1264353566.74.0.804981752433.issue7771@psf.upfronthosting.co.za>
Message-ID: <1287158602.67.0.341778664555.issue7771@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied in r85532. Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7771>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:04:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 16:04:21 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287158661.52.0.538683053291.issue9778@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:07:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 16:07:38 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287158858.71.0.63838345454.issue10115@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/issue10115>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:07:53 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 16:07:53 +0000
Subject: [issue9683] Dead code in py3k inspect module
In-Reply-To: <1282763623.07.0.68649497821.issue9683@psf.upfronthosting.co.za>
Message-ID: <1287158872.99.0.0897544316431.issue9683@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed both in r85533.  Thanks!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9683>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:08:39 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Fri, 15 Oct 2010 16:08:39 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1287158919.66.0.732026978978.issue9344@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Did a bit of digging and found that getgrouplist signature differs on (at least) Linux and Mac OS:
 - http://www.kernel.org/doc/man-pages/online/pages/man3/getgrouplist.3.html
 -http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/getgrouplist.3.html

----------
nosy: +nvetoshkin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9344>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:09:01 2010
From: report at bugs.python.org (Tal Einat)
Date: Fri, 15 Oct 2010 16:09:01 +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: <1287158941.38.0.582920730005.issue10107@psf.upfronthosting.co.za>


Tal Einat <taleinat at gmail.com> added the comment:

Note that some discussion about this issue is taking place on the idle-dev mailing list.

Bruce Sherwood found the line "root.bind('<<close-all-windows>>', flist.close_all_callback)", which seems to be an unsuccessful attempt to achieve the wanted behavior.

Kevin Walzer mentioned that a grep on the idlelib code doesn't turn up any references to "tk::mac::Quit".

I don't have access to OSX for testing. Could someone please replace the root.bind call with what Kevin suggested, and see if it solves the problem?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:13:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 16:13:07 +0000
Subject: [issue1699594] shlex fails to parse strings correctly
Message-ID: <1287159187.08.0.0381006783299.issue1699594@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That particular commit can't be the reason, but some other must be.  Closing as wfm.

----------
dependencies:  -shlex.split() does not tokenize like the shell
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699594>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:20:29 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 16:20:29 +0000
Subject: [issue9801] Can not use append/extend to lists in a multiprocessing
	manager dict
In-Reply-To: <1283973802.38.0.869176624785.issue9801@psf.upfronthosting.co.za>
Message-ID: <1287159629.82.0.692510126725.issue9801@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

For now, documented the current behavior in r85534.  If a different solution is desired, a new issue can be opened.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9801>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:26:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 16:26:40 +0000
Subject: [issue9054] pyexpat configured with "--with-system-expat" is
	incompatible with expat 2.0.1
In-Reply-To: <1277158370.27.0.787157062055.issue9054@psf.upfronthosting.co.za>
Message-ID: <1287160000.16.0.773663303865.issue9054@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied in r85536, will backport to other branches as well.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9054>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:29:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Oct 2010 16:29:30 +0000
Subject: [issue9308] Remove redundant coding cookies from 3.x stdlib
In-Reply-To: <1279565829.31.0.797750861129.issue9308@psf.upfronthosting.co.za>
Message-ID: <1287160170.08.0.522515900337.issue9308@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r85537.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9308>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:36:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 16:36:07 +0000
Subject: [issue7303] pkgutil lacks documentation for useful functions
In-Reply-To: <1257891153.41.0.767469344024.issue7303@psf.upfronthosting.co.za>
Message-ID: <1287160567.48.0.515998454764.issue7303@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed markup a bit and committed in r85538.  Thanks!

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7303>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:42:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 16:42:48 +0000
Subject: [issue6798] Argument for sys.settrace() callbacks documented
	incorrectly
In-Reply-To: <1251503525.6.0.896923124912.issue6798@psf.upfronthosting.co.za>
Message-ID: <1287160968.6.0.943971017958.issue6798@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Should be fixed in r85540.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6798>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:44:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 16:44:19 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1287161059.27.0.986953382811.issue8954@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Raising priority.

----------
priority: normal -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:53:26 2010
From: report at bugs.python.org (Ned Deily)
Date: Fri, 15 Oct 2010 16:53:26 +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: <1287161606.58.0.217261631121.issue10107@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

It looks like the '::tk::mac::Quit' callback does not exist in the Apple-supplied Tk 8.4.7 in OS X 10.5 and 10.4, although it does work with the Apple-supplied Tk 8.4.19(?) and 8.5 in 10.6 and with a current ActiveState 8.4.19 on 10.4 through 10.6.  However, instead of that, it looks like overriding the 'exit' callback will work fine on all of them.  In a simple test, I'm able to intercept the Tk app quitting, post a yes/no message, and then terminate the Tk app by destroying the root.  Next I'll try integrating into IDLE.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:53:39 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 16:53:39 +0000
Subject: [issue4968] Clarify inspect.is<callable> method docs
In-Reply-To: <1232162769.03.0.624026715862.issue4968@psf.upfronthosting.co.za>
Message-ID: <1287161619.83.0.806775659691.issue4968@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed suggestions with a few changes in r85541.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4968>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:54:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 16:54:26 +0000
Subject: [issue5729] Allows tabs for indenting JSON output
In-Reply-To: <1239297330.19.0.24635332127.issue5729@psf.upfronthosting.co.za>
Message-ID: <1287161666.74.0.0372061037282.issue5729@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Bob, any chance you get to that merge before 3.2b1?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5729>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:54:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Oct 2010 16:54:42 +0000
Subject: [issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Tools/scripts/reindent.py -d Lib/test/encoded_modules/module_koi8_r.py
Traceback (most recent call last):
  File "Tools/scripts/reindent.py", line 310, in <module>
    main()
  File "Tools/scripts/reindent.py", line 93, in main
    check(arg)
  File "Tools/scripts/reindent.py", line 114, in check
    r = Reindenter(f)
  File "Tools/scripts/reindent.py", line 162, in __init__
    self.raw = f.readlines()
  File "Lib/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode byte 0xf0 in position 59: invalid continuation byte

Attached patch fixes this issue.

----------
components: Demos and Tools
files: reindent.diff
keywords: needs review, patch
messages: 118804
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Tools/scripts/reindent.py fails on non-UTF-8 encodings
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19245/reindent.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10117>
_______________________________________

From report at bugs.python.org  Fri Oct 15 18:56:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Oct 2010 16:56:41 +0000
Subject: [issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1287161801.68.0.0793739059546.issue10117@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +christian.heimes, flox, tim_one

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10117>
_______________________________________

From report at bugs.python.org  Fri Oct 15 19:01:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 17:01:21 +0000
Subject: [issue7790] struct_time documentation entry should point to the table
	defining the tuple
In-Reply-To: <1264538314.16.0.129243655657.issue7790@psf.upfronthosting.co.za>
Message-ID: <1287162081.66.0.676243575715.issue7790@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, moved the table down in r85542.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7790>
_______________________________________

From report at bugs.python.org  Fri Oct 15 19:04:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 17:04:57 +0000
Subject: [issue4785] json.JSONDecoder() strict argument undocumented and
	potentially confusing
In-Reply-To: <1230658934.34.0.991784557371.issue4785@psf.upfronthosting.co.za>
Message-ID: <1287162297.95.0.831312868432.issue4785@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r85543 and r85544.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4785>
_______________________________________

From report at bugs.python.org  Fri Oct 15 19:20:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 17:20:22 +0000
Subject: [issue7450] document that os.chmod accepts an octal digit mode
In-Reply-To: <1260201260.24.0.734078851389.issue7450@psf.upfronthosting.co.za>
Message-ID: <1287163222.49.0.165887148935.issue7450@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

We now have the S_IXXX constants documented explicitly, so I don't think this change is needed.

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7450>
_______________________________________

From report at bugs.python.org  Fri Oct 15 19:30:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Oct 2010 17:30:57 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1287163857.89.0.0269295752629.issue5150@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

reindent.py is very much a script: It lacks a nice, full programmatic API, I mean standalone functions to check a file object or a filename and functions implementing the command-line interface.  As it is now, you see for example print calls in the middle of functions, so it?s not usable as a module.

Maybe bring this to python-dev or -ideas?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Fri Oct 15 19:39:56 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Oct 2010 17:39:56 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1287164396.6.0.963004498995.issue5150@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

There's no need to go to python-dev or python-ideas with this one.  If someone wants to figure-out a way to add reindent functionality to IDLE, patches are welcome.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Fri Oct 15 19:45:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 15 Oct 2010 17:45:27 +0000
Subject: [issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1287164727.66.0.541073526331.issue10117@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10117>
_______________________________________

From report at bugs.python.org  Fri Oct 15 19:53:14 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 17:53:14 +0000
Subject: [issue10111] Minor problems with PyFileObject documentation
	(Doc/c-api/file.rst)
In-Reply-To: <1287125408.14.0.853619758536.issue10111@psf.upfronthosting.co.za>
Message-ID: <1287165194.86.0.0350283020424.issue10111@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r85545.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10111>
_______________________________________

From report at bugs.python.org  Fri Oct 15 19:53:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 17:53:46 +0000
Subject: [issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1287165226.05.0.0893994195812.issue10117@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

LGTM.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10117>
_______________________________________

From report at bugs.python.org  Fri Oct 15 19:54:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 17:54:36 +0000
Subject: [issue4086] support %z format in time.strftime and _strptime?
In-Reply-To: <1223551646.15.0.164355592546.issue4086@psf.upfronthosting.co.za>
Message-ID: <1287165276.7.0.231178927664.issue4086@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/issue4086>
_______________________________________

From report at bugs.python.org  Fri Oct 15 19:59:05 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 17:59:05 +0000
Subject: [issue5762] AttributeError: 'NoneType' object has no attribute
	'replace'
In-Reply-To: <1239798874.6.0.325655580097.issue5762@psf.upfronthosting.co.za>
Message-ID: <1287165545.92.0.0855349554261.issue5762@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the test case, committed the fix and the new test in r85546.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5762>
_______________________________________

From report at bugs.python.org  Fri Oct 15 19:59:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Oct 2010 17:59:09 +0000
Subject: [issue9317] Incorrect coverage file from trace test_pickle.py
In-Reply-To: <1279677265.36.0.322549269298.issue9317@psf.upfronthosting.co.za>
Message-ID: <1287165549.0.0.94218186327.issue9317@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have verified that the original issue is still present.  I will try to narrow it down to a smaller test case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9317>
_______________________________________

From report at bugs.python.org  Fri Oct 15 20:02:41 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 18:02:41 +0000
Subject: [issue6098] xml.dom.minidom incorrectly claims DOM Level 3 conformance
In-Reply-To: <1243197780.58.0.272636351535.issue6098@psf.upfronthosting.co.za>
Message-ID: <1287165761.34.0.052267037241.issue6098@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied in r85547.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6098>
_______________________________________

From report at bugs.python.org  Fri Oct 15 20:03:44 2010
From: report at bugs.python.org (David Watson)
Date: Fri, 15 Oct 2010 18:03:44 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1287076504.72.0.973773564959.issue9377@psf.upfronthosting.co.za>
Message-ID: <20101015180336.GA3180@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

> As a further note: I think socket.gethostname() is a special case, since this is just about a local setting (i.e. not related to DNS).

But the hostname *is* commonly intended to be looked up in the
DNS or whatever name resolution mechanisms are used locally -
socket.getfqdn(), for instance, works by looking up the result
using gethostbyaddr() (actually the C function getaddrinfo(),
followed by gethostbyaddr()).  So I don't see the rationale for
treating it differently from the results of gethostbyaddr(),
getnameinfo(), etc.

POSIX says of the name lookup functions that "in many cases" they
are implemented by the Domain Name System, not that they always
are, so a name intended for lookup need not be ASCII-only either.

> We should then assume that it is encoded in the locale encoding (in particular, that it is encoded in mbcs on Windows).

I can see the point of returning the characters that were
intended, but code that looked up the returned name would then
have to be changed to re-encode it to bytes to avoid the
round-tripping issue when non-ASCII characters are returned.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Fri Oct 15 20:28:36 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 15 Oct 2010 18:28:36 +0000
Subject: [issue9539] python-2.6.4: test failure in test_distutils due to
	linking to system libpython2.6
In-Reply-To: <1281222795.64.0.211558756173.issue9539@psf.upfronthosting.co.za>
Message-ID: <1287167316.24.0.452944983993.issue9539@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm afraid this can't be fixed in 2.6.

----------
versions:  -3rd party, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9539>
_______________________________________

From report at bugs.python.org  Fri Oct 15 20:32:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 15 Oct 2010 18:32:18 +0000
Subject: [issue9317] Incorrect coverage file from trace test_pickle.py
In-Reply-To: <1279677265.36.0.322549269298.issue9317@psf.upfronthosting.co.za>
Message-ID: <1287167538.68.0.75102110303.issue9317@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have found the cause of at least part of the issue.  Apparently, module level statements for some of the modules such as pickle do not show up in trace because they are imported by trace itself.  In other words, by the time traced script gets executed, pickle is already in sys.module and the code therein does not run.

Maybe we should consider clearing sys.modules in Trace.run, but this can cause problems if not done carefully.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9317>
_______________________________________

From report at bugs.python.org  Fri Oct 15 20:40:43 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Oct 2010 18:40:43 +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: <1287168043.3.0.152388895744.issue7140@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Since that revision only touched py3k, I am guessing that it only broke 3.2.

----------
nosy: +terry.reedy
versions: +Python 3.2 -Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7140>
_______________________________________

From report at bugs.python.org  Fri Oct 15 20:58:42 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 15 Oct 2010 18:58:42 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287169122.65.0.857197892617.issue9778@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Not that anybody needs my input on this, but...

Given the range of people advocating for this change, this looks to me
like it should be a release blocker for 3.2.  Raymond's comment about
performance seems especially important, and since the world seems to
be moving toward 64-bit operating systems (certainly should happen in
a big way during the lifetime of Python 3) it seems worthwhile to hold
up further 3.2 releases until this is solved.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Fri Oct 15 21:01:28 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Oct 2010 19:01:28 +0000
Subject: [issue10058] Unclear PyString_AsStringAndSize return value
In-Reply-To: <1286667477.81.0.428824967814.issue10058@psf.upfronthosting.co.za>
Message-ID: <1287169288.28.0.247584361258.issue10058@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I am not much familiar with the C api but I presume that all functions return -1 on error and that this is documented somewhere in the beginning. I also presume that functions that return values thru passed in pointers and that are documented as returning an integer type return 0 on success. And ditto on some general note somewhere. I do not think that such should be repeated for each function. So without further justification, I would be inclined to close this.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10058>
_______________________________________

From report at bugs.python.org  Fri Oct 15 21:07:47 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Oct 2010 19:07:47 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1287169667.29.0.306804246668.issue10060@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


Removed file: http://bugs.python.org/file19192/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Fri Oct 15 21:08:30 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Oct 2010 19:08:30 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1287169710.86.0.237035353345.issue10060@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The unnamed quasi-html file loaded with msg118397 was a unless, essentially unreadable duplicate of that message, hence removed.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Fri Oct 15 21:12:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 19:12:28 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1287169122.65.0.857197892617.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287169943.3422.7.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Given the range of people advocating for this change, this looks to me
> like it should be a release blocker for 3.2.  Raymond's comment about
> performance seems especially important, and since the world seems to
> be moving toward 64-bit operating systems (certainly should happen in
> a big way during the lifetime of Python 3) it seems worthwhile to hold
> up further 3.2 releases until this is solved.

I think this is a bit exagerated. The performance issues will only
appear if you have huge dicts and sets.
The issue Raymond raised is the potential impossibility of making the
change /after/ we settle on a stable ABI. The question is whether the
ABI will be enforced starting from 3.2, or from a later date.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Fri Oct 15 21:21:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 19:21:55 +0000
Subject: [issue10058] Unclear PyString_AsStringAndSize return value
In-Reply-To: <1286667477.81.0.428824967814.issue10058@psf.upfronthosting.co.za>
Message-ID: <1287170515.2.0.22900522496.issue10058@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Same here.  There is only ever one return value on error unless documented otherwise, since the type of error is already contained in the exception that is set on return.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10058>
_______________________________________

From report at bugs.python.org  Fri Oct 15 21:37:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 19:37:25 +0000
Subject: [issue10064] link to page with documentation bugs
In-Reply-To: <1286722559.84.0.874686130461.issue10064@psf.upfronthosting.co.za>
Message-ID: <1287171445.13.0.538274447198.issue10064@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The reference you're referring to is in the section about bugs in Python:

"""
Bug reports for Python itself should be submitted via the Python Bug Tracker (http://bugs.python.org/).
"""

and it is placed below the section dealing with documentation bugs.  As such, this request is a "works for me".

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10064>
_______________________________________

From report at bugs.python.org  Fri Oct 15 21:46:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 19:46:34 +0000
Subject: [issue10072] ftplib documentation is unclear
In-Reply-To: <1286890330.18.0.528330532597.issue10072@psf.upfronthosting.co.za>
Message-ID: <1287171994.29.0.751778799201.issue10072@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed after review in r85548.  Thanks!

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10072>
_______________________________________

From report at bugs.python.org  Fri Oct 15 21:52:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 19:52:15 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287172335.76.0.588072264789.issue10073@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't see the point.  If you file one such bug per day, you won't be finished in a year -- there's no reason to start adding typechecking in this function.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Fri Oct 15 21:54:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Fri, 15 Oct 2010 19:54:12 +0000
Subject: [issue10098] intermittent failure in test_os
In-Reply-To: <1287045270.71.0.765573711319.issue10098@psf.upfronthosting.co.za>
Message-ID: <1287172452.28.0.866160945077.issue10098@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10098>
_______________________________________

From report at bugs.python.org  Fri Oct 15 22:29:52 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 15 Oct 2010 20:29:52 +0000
Subject: [issue10110] Queue doesn't recognize it is full after shrinking
	maxsize
In-Reply-To: <1287105905.32.0.568830983004.issue10110@psf.upfronthosting.co.za>
Message-ID: <1287174592.7.0.793134004812.issue10110@psf.upfronthosting.co.za>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I should point out that in Python 2.5, it was possible for a subclass to override the _full method to account for this situation, but with Python 2.6 and later, the calculation in _full was hand-inlined... so it's not readily possible for a subclass to correct for this behavior. It might be desirable to refactor that calculation into a _full method, though I suspect this would have performance implications, which is why I stuck with just adjusting the comparison in its various uses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10110>
_______________________________________

From report at bugs.python.org  Fri Oct 15 22:45:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Oct 2010 20:45:34 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287175534.05.0.683235795744.issue10073@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

To me, Alexander's example
  >>> calendar.isleap("%d")
  False
is a buggy result. So I would reclassify the issue.

The rationale for not checking input types is that bad types result in an error, but that does not happen here due to a design decision that some consider clever and some buggy, and some both. (Guido himself would like to deprecate it.)

I am in favor of the 'year & 3 == 0' fix so that any input string (and indeed, anything that does not implement both % and & operators) raises an error. Intermediate to expert programmers should know or learn about bit masking. Add a comment to explain the reason -- and a test case.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Fri Oct 15 22:51:17 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 15 Oct 2010 20:51:17 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287175877.62.0.0641198447943.issue10073@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> To me, Alexander's example
>   >>> calendar.isleap("%d")
>   False
> is a buggy result. So I would reclassify the issue.

You'll always find plenty "wrong" inputs for which a function doesn't
raise an exception.  That's the downside of duck typing.

> The rationale for not checking input types is that bad types result
> in an error, but that does not happen here due to a design decision
> that some consider clever and some buggy, and some both. (Guido
> himself would like to deprecate it.)

You're talking of % string formatting?  Well, that's just one operation
where duck typing applies.  There may be a bit less chance of namespace
collisions when calling methods, but it's the same issue at heart.

> I am in favor of the 'year & 3 == 0' fix so that any input string
> (and indeed, anything that does not implement both % and & operators)
> raises an error. Intermediate to expert programmers should know or
> learn about bit masking. Add a comment to explain the reason -- and
> a test case.

I agree that ``year & 3 == 0`` in this place is okay, and if it helps
avoid confusion, all the better.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Fri Oct 15 23:18:45 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Oct 2010 21:18:45 +0000
Subject: [issue10109] itertools.product with infinite iterator cause
	MemoryError.
In-Reply-To: <1287103502.64.0.571191585998.issue10109@psf.upfronthosting.co.za>
Message-ID: <1287177525.4.0.175854710696.issue10109@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The input to itertools.product must be a finite sequence of finite iterables. itertools.count(startvalue) produces an infinite sequence of ints (which are not iterable). Passing the latter to the former causes the latter to run until memory is exhausted. You should get the same result with tuple(itertools.count()), which is what happens within itertools.product.

Your generator example does not show the same problem because it is not nested and never runs.

If you are unfamiliar with Python and its stdlib, please ask questions on python-list (mirror on comp.lang.python and gmane.comp.python.general) before reporting what you think might be an error.

----------
nosy: +terry.reedy
resolution:  -> invalid
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10109>
_______________________________________

From report at bugs.python.org  Fri Oct 15 23:21:22 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Fri, 15 Oct 2010 21:21:22 +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: <1287177682.97.0.34493879243.issue9807@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Summarizing IRC discussion:

Tested on Fedora 13 x86_64 with:
  --enable-shared --with-wide-unicode
and with confdir != srcdir with:
  ../configure --enable-shared --with-wide-unicode --with-pydebug

Mostly working but, test_distutils fails:
  test_get_outputs (distutils.tests.test_build_ext.BuildExtTestCase) ... /usr/bin/ld: cannot find -lpython3.2
  collect2: ld returned 1 exit status

Each build makes a "libpython3.2.a"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Fri Oct 15 23:50:14 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Oct 2010 21:50:14 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287179414.3.0.16191843819.issue10114@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think the title is slightly misleading. As I read the patch, the issue is that PyArg_ParseTupleAndKeywords requires that string args to C functions be valid Unicode strings (and that it does this by trying to encode to utf-8). Your patch subverts this by redefining filename to be a generic object, with a looser custom-coded test. It is not clear to me that filename, out of all string args to builtins, should be excepted this way. It seems to me that any real filename should be real unicode and there is no need for fake names that are not.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Fri Oct 15 23:50:54 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Oct 2010 21:50:54 +0000
Subject: [issue10110] Queue doesn't recognize it is full after shrinking
	maxsize
In-Reply-To: <1287105905.32.0.568830983004.issue10110@psf.upfronthosting.co.za>
Message-ID: <1287179454.74.0.207466416135.issue10110@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I've briefly looked at the patch and it seems reasonable.  Will look it in more detail by 3.2 goes out. 

I'm curious about your use case for wanting to change the maxsize of an existing Queue that is already in use.  That seems like a odd design.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10110>
_______________________________________

From report at bugs.python.org  Sat Oct 16 00:00:36 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 15 Oct 2010 22:00:36 +0000
Subject: [issue10110] Queue doesn't recognize it is full after shrinking
	maxsize
In-Reply-To: <1287179454.74.0.207466416135.issue10110@psf.upfronthosting.co.za>
Message-ID: <12C7AB425F0DD546B6049311F827C74E097C38683A@VA3DIAXVS141.RED001.local>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

I'm not sure what our use case is. I discovered this when I was looking at our project's util library, and we have a Queue subclass that overrides _full to handle the scenario where the queue shrinks. I'm guessing it's being used to dynamically adjust the queue size for performance reasons. Consider where you have a queue of items, but depending on the run time environment, that queue might need to be more or less limiting. Maybe the queue is larger during the day when requests are heavier and shrinks at night (so it's not accepting more items than it can handle when day breaks).

Surely that's a contrived example, and I suspect our actual usage is more concrete. I'll see if I can learn where we're using that functionality.

If shrinking maxsize is not allowed, that should be enforced in the interface (such as with a read-only/increase-only property) and documented. If you would rather proceed that way, I'll draft the patch for that instead.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10110>
_______________________________________

From report at bugs.python.org  Sat Oct 16 00:04:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2010 22:04:56 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287180296.5.0.930149495777.issue10114@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

#6543 changed code->co_filename encoding from filesystem encoding+surrogateescape to utf-8+strict.

With my patch, compile('', '\udcc3\udca9', 'exec').co_filename gives '?', it doesn't depend on the filesystem encoding. But '?' cannot be used with all filesystem encodings, eg. with ascii locale encoding (C locale), use it raises an error.

I now think that it was a bad idea to use utf-8 instead of the fileystem encoding. All filenames should use the filesystem encoding in Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Sat Oct 16 00:08:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2010 22:08:58 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287180538.48.0.921057856768.issue10114@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #9713.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Sat Oct 16 00:26:47 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2010 22:26:47 +0000
Subject: [issue9713] Py_CompileString fails on non decode-able paths.
In-Reply-To: <1283154413.35.0.877915229941.issue9713@psf.upfronthosting.co.za>
Message-ID: <1287181607.95.0.520534570993.issue9713@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also issue #10114.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9713>
_______________________________________

From report at bugs.python.org  Sat Oct 16 00:30:51 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 15 Oct 2010 22:30:51 +0000
Subject: [issue10110] Queue doesn't recognize it is full after shrinking
	maxsize
In-Reply-To: <1287105905.32.0.568830983004.issue10110@psf.upfronthosting.co.za>
Message-ID: <1287181851.8.0.929567582634.issue10110@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

That won't be necessary.  The change from == to <= is innocuous.

There's no need to lock-up maxsize in a read-only property.  We're consenting adults.  Besides, it would probably break someone-else's odd use case.  I don't want to expand the API, nor do I want to cripple anyone's ability to do weird stuff with it.

FWIW, the full() and empty() methods are usually not a good idea.  It's better to catch a Full exception.  Otherwise, the information can be out of date by the time you try to use it.

I'm going to mark this as a 3.2 only change.  There were no guarantees about the behavior when maxsize is changed, nor should we make such guarantees.

----------
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10110>
_______________________________________

From report at bugs.python.org  Sat Oct 16 00:43:42 2010
From: report at bugs.python.org (Jason R. Coombs)
Date: Fri, 15 Oct 2010 22:43:42 +0000
Subject: [issue10110] Queue doesn't recognize it is full after shrinking
	maxsize
In-Reply-To: <1287181851.8.0.929567582634.issue10110@psf.upfronthosting.co.za>
Message-ID: <12C7AB425F0DD546B6049311F827C74E097C386880@VA3DIAXVS141.RED001.local>


Jason R. Coombs <jaraco at jaraco.com> added the comment:

Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10110>
_______________________________________

From report at bugs.python.org  Sat Oct 16 00:51:00 2010
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 15 Oct 2010 22:51:00 +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: <1287183060.19.0.285931982484.issue1589@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

Can you confirm that the exception raised both on "too early" and "too late" is something like "...SSL3_GET_SERVER_CERTIFICATE:certificate verify failed"?

(If so: It would be nice if a slightly more helpful message could be given. I don't know if that is possible.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Sat Oct 16 00:58:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2010 22:58:16 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287183496.13.0.656008419995.issue10114@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> All filenames should use the filesystem encoding in Python.

Here is a new patch [code_encoding.patch] implementing this idea:

 - Use filesystem encoding (and surrogateescape) to encode/decode paths in compile() and the parser, instead of utf-8 in strict mode
 - Ensure that co_filename attribute can be used as a filename (eg. to not raise UnicodeEncodeError on Linux)
 - compile() builtin supports bytes filenames
 - _Py_FindSourceFile() (traceback.c) encodes paths of sys.path into the filesystem encoding, as do find_module() (import.c)
 - PyRun_SimpleFileExFlags() sets __file__ attribute using the filesystem encoding

The patch restores the situation before #6543.

----------
Added file: http://bugs.python.org/file19246/code_encoding.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Sat Oct 16 00:58:42 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 15 Oct 2010 22:58:42 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287183522.61.0.653674968096.issue10114@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Pardon my ignorance, but given that code.co_filename is a string attribute given as a string, which is to say, unicode in 3.x, I do not see what filesystem encodings, or any other encoding to bytes should really have to do with the attribute. I actually would have expected compile to take your example argument 'abc\uDC80' and paste it onto the code object unchanged. The only issue to me is whether any string should be allowed or only legal-unicode strings. Anything else would seem like a 2.x holdover.

If PyBytes_AS_STRING (macro version of PyBytes_AsString) is the implementation of str(bytes_object) (as I would guess from the doc), then as I read your patch, it will produce rather strange 'filenames'.
>>> str('abc\uDC80'.encode("utf-8", "surrogateescape"))
"b'abc\\x80'"
always wrapped in b'...'.

If not that, what does it do (with no decoding specified)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Sat Oct 16 01:00:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 15 Oct 2010 23:00:32 +0000
Subject: [issue1589] New SSL module doesn't seem to verify hostname against
	commonName in certificate
In-Reply-To: <1287183060.19.0.285931982484.issue1589@psf.upfronthosting.co.za>
Message-ID: <1287183627.3422.33.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le vendredi 15 octobre 2010 ? 22:51 +0000, Mads Kiilerich a ?crit :
> Mads Kiilerich <mads at kiilerich.com> added the comment:
> 
> Can you confirm that the exception raised both on "too early" and "too
> late" is something like "...SSL3_GET_SERVER_CERTIFICATE:certificate
> verify failed"?

Yes.

> (If so: It would be nice if a slightly more helpful message could be
> given. I don't know if that is possible.)

Agreed. I don't know how to do that, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1589>
_______________________________________

From report at bugs.python.org  Sat Oct 16 01:15:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 15 Oct 2010 23:15:43 +0000
Subject: [issue9862] PIPE_BUF is invalid on AIX
In-Reply-To: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>
Message-ID: <1287184543.25.0.469647831718.issue9862@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> r.david.murray
nosy: +r.david.murray
stage:  -> commit review
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9862>
_______________________________________

From report at bugs.python.org  Sat Oct 16 01:17:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2010 23:17:37 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287184657.96.0.471896442106.issue10114@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I do not see what filesystem encodings, or any other encoding 
> to bytes should really have to do with the [code.co_filename].

co_filename attribute is used to display the traceback: Python opens the related file, read the source code line and display it. On Windows, co_filename is directly used because Windows accepts unicode for filenames. But on other OSes, you have to encode the filename to the filesystem encoding.

If your filesystem encoding is 'ascii' (eg. C locale) and co_filename is a non-ascii filename (eg. 'test_?.py'), encode co_filename will raise a UnicodeEncodeError. You can test it simply by using os.fsencode():

$ ./python 
Python 3.2a3+ (py3k:85551:85553M, Oct 16 2010, 00:54:03) 
>>> import sys; sys.getfilesystemencoding()
'utf-8'
>>> import os; os.fsencode('?')
b'\xc3\xa9'

$ LANG= ./python 
Python 3.2a3+ (py3k:85551:85553M, Oct 16 2010, 00:54:03) 
>>> import sys; sys.getfilesystemencoding()
'ascii'
>>> import os; os.fsencode('\xe9')
...
UnicodeEncodeError: 'ascii' codec can't encode character '\xe9' ...

Said differently, co_filename should be encodable to the filesystem encoding (os.fsencode(co_filename) should not raise an error).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Sat Oct 16 01:18:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2010 23:18:56 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287184736.98.0.460997565558.issue10114@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Remove [compile_surrogates.patch] because it creates filenames unencode to the filesystem encoding. Eg. compile('', '\udcc3\udca9', 'exec').co_filename gives '?' even if the filesystem encoding is 'ascii'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Sat Oct 16 01:19:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 15 Oct 2010 23:19:17 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287184757.21.0.779291886718.issue10114@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Removed file: http://bugs.python.org/file19243/compile_surrogates.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Sat Oct 16 01:28:12 2010
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 15 Oct 2010 23:28:12 +0000
Subject: [issue5150] IDLE to support reindent.py
In-Reply-To: <1233736664.4.0.115705275626.issue5150@psf.upfronthosting.co.za>
Message-ID: <1287185292.5.0.843798739128.issue5150@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

I grabbed the core of reindent.py and put it into an extension, unmodified. 

The original reindent.py will emit Indentation Errors if they exist. 
ScriptBinding already has nice code to handle these problems by highlighting the error, placing the cursor at the error, and presenting a message box. Rather than duplicate this code, this extension makes calls into ScriptBinding to check for syntax errors when the core reindent code throws exceptions.

----------
Added file: http://bugs.python.org/file19247/ReindentExtension.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5150>
_______________________________________

From report at bugs.python.org  Sat Oct 16 01:56:46 2010
From: report at bugs.python.org (Roger Serwy)
Date: Fri, 15 Oct 2010 23:56:46 +0000
Subject: [issue6014] No shell prompt when a graphics window that was started
	from IDLE is closed
In-Reply-To: <1242252085.07.0.824128250707.issue6014@psf.upfronthosting.co.za>
Message-ID: <1287187006.9.0.0414694071137.issue6014@psf.upfronthosting.co.za>


Roger Serwy <roger.serwy at gmail.com> added the comment:

This issue can be closed.

The natural language toolkit uses Tk for its GUI, the same as IDLE. Under Ubuntu 8.10, IDLE is launched from the menu without a subprocess. Running nltk as described without a subprocess causes this problem.

Try launching IDLE without "-n".

----------
nosy: +serwy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6014>
_______________________________________

From report at bugs.python.org  Sat Oct 16 02:49:09 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Oct 2010 00:49:09 +0000
Subject: [issue9862] PIPE_BUF is invalid on AIX
In-Reply-To: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>
Message-ID: <1287190149.82.0.248723177043.issue9862@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in r85554, 2.7 in r85556.  S?bastien, from what you say it sounds like this does not apply to 3.1, so I blocked it there.  If this is incorrect let me know and I'll backport it.

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9862>
_______________________________________

From report at bugs.python.org  Sat Oct 16 03:30:30 2010
From: report at bugs.python.org (mark saaltink)
Date: Sat, 16 Oct 2010 01:30:30 +0000
Subject: [issue10118] Tkinter does not find font
In-Reply-To: <1287192630.89.0.924571330725.issue10118@psf.upfronthosting.co.za>
Message-ID: <1287192630.89.0.924571330725.issue10118@psf.upfronthosting.co.za>


New submission from mark saaltink <platonic.liquid at gmail.com>:

Tkinter, since tk 8.5 apparently, does not find all the fonts that tk knows about.

I'm using Python 2.6.5 on Linux but have seen this on previous versions.  I have added the font with "xset fp+ <some font directory>"".  The font is Richard Jones' zed font, available from http://www.cs.kent.ac.uk/people/staff/rej/Zedfont/latest/

xlsfonts shows the font.

tk sees the font; in wish if I type "font families" there it is:

% font families
{fangsong ti} fixed {clearlyu alternate glyphs} charter lucidatypewriter zedfont {latin modern roman}  ...

In Tkinter I do not see the font:
>>> from Tkinter import *
>>> r = Tk()
>>> import tkFont
>>> tkFont.families(r)
... no sign of the zedfont here.

Is this expected behaviour?  Is there another way to install the font that avoids this problem?

----------
components: Tkinter
messages: 118850
nosy: mark.saaltink
priority: normal
severity: normal
status: open
title: Tkinter does not find font
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10118>
_______________________________________

From report at bugs.python.org  Sat Oct 16 04:00:17 2010
From: report at bugs.python.org (Nikolaus Rath)
Date: Sat, 16 Oct 2010 02:00:17 +0000
Subject: [issue10058] C-API Intro should be more explicit about error return
	codes
In-Reply-To: <1286667477.81.0.428824967814.issue10058@psf.upfronthosting.co.za>
Message-ID: <1287194417.21.0.0527383572279.issue10058@psf.upfronthosting.co.za>


Nikolaus Rath <Nikolaus at rath.org> added the comment:

Georg, this is an important piece of information, but I think it is not yet clearly stated in the documentation. Here is what  http://docs.python.org/c-api/intro.html says about return codes:

"In general, when a function encounters an error, it sets an exception, discards any object references that it owns, and returns an error indicator ? usually NULL or -1. A few functions return a Boolean true/false result, with false indicating an error. Very few functions return no explicit error indicator or have an ambiguous return value, and require explicit testing for errors with PyErr_Occurred()."

If this is meant to say that a function returns *only* -1 or NULL in case of an error, *unless documented otherwise* I suggest that the wording be changed to reflect that. Maybe like this:

"In general, when a function encounters an error, it sets an exception, discards any object references that it owns, and returns either NULL or -1 (depending on what is compatible with the function's type). If a functions documentation does not say otherwise, the function can be assumed to follow this convention. Nevertheless, a few functions return a Boolean true/false result, with false indicating an error, and very few functions return no explicit error indicator or have an ambiguous return value, and require explicit testing for errors with PyErr_Occurred()."



Wouldn't that be a reasonable change?

----------
title: Unclear PyString_AsStringAndSize return value -> C-API Intro should be more explicit about error return codes

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10058>
_______________________________________

From report at bugs.python.org  Sat Oct 16 04:04:39 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Oct 2010 02:04:39 +0000
Subject: [issue10119] test_urllibnet failure when using
	support.transient_internet
In-Reply-To: <1287194679.07.0.887400455499.issue10119@psf.upfronthosting.co.za>
Message-ID: <1287194679.07.0.887400455499.issue10119@psf.upfronthosting.co.za>


New submission from Senthil Kumaran <orsenthil at gmail.com>:

I am attaching the script which exhibits the problem.

wrapping the urllib.request.urlopen, with the support.transient_internet contextmanager exhibits an Unexpected Behavior. Without the context manager, reading the file using the filedescriptor succeeds, but when wrapping it with the context manager, it fails with a TypeError.

----------
files: simple_test.py
messages: 118852
nosy: orsenthil
priority: normal
severity: normal
stage: needs patch
status: open
title: test_urllibnet failure when using support.transient_internet
type: behavior
Added file: http://bugs.python.org/file19248/simple_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10119>
_______________________________________

From report at bugs.python.org  Sat Oct 16 04:06:33 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Oct 2010 02:06:33 +0000
Subject: [issue10119] test_urllibnet failure when using
	support.transient_internet
In-Reply-To: <1287194679.07.0.887400455499.issue10119@psf.upfronthosting.co.za>
Message-ID: <1287194793.26.0.848183933151.issue10119@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10119>
_______________________________________

From report at bugs.python.org  Sat Oct 16 05:46:08 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Oct 2010 03:46:08 +0000
Subject: [issue9997] function named 'top' gets unexpected namespace/scope
	behaviour
In-Reply-To: <1285849061.79.0.383989167237.issue9997@psf.upfronthosting.co.za>
Message-ID: <1287200768.14.0.106058840883.issue9997@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85562.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9997>
_______________________________________

From report at bugs.python.org  Sat Oct 16 05:52:20 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Oct 2010 03:52:20 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1287201140.63.0.653513690029.issue10116@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Issue10119 is related too and both I guess, is boiling down to httplib either not properly using an open socket or closing it prematurely.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Sat Oct 16 05:58:18 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 16 Oct 2010 03:58:18 +0000
Subject: [issue10107] Quitting IDLE on Mac doesn't save unsaved code
In-Reply-To: <1287076967.07.0.270311596559.issue10107@psf.upfronthosting.co.za>
Message-ID: <1287201498.41.0.335324332745.issue10107@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Looks like the "exit" callback will work for IDLE but there are the usual edge cases and odd differences among the various branches and build options to work through and fix up.  Patch forthcoming.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Sat Oct 16 06:16:02 2010
From: report at bugs.python.org (Ned Deily)
Date: Sat, 16 Oct 2010 04:16:02 +0000
Subject: [issue6014] No shell prompt when a graphics window that was started
	from IDLE is closed
In-Reply-To: <1242252085.07.0.824128250707.issue6014@psf.upfronthosting.co.za>
Message-ID: <1287202562.06.0.341207371675.issue6014@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy:  -BreamoreBoy
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6014>
_______________________________________

From report at bugs.python.org  Sat Oct 16 06:40:34 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 16 Oct 2010 04:40:34 +0000
Subject: [issue10058] C-API Intro should be more explicit about error return
	codes
In-Reply-To: <1286667477.81.0.428824967814.issue10058@psf.upfronthosting.co.za>
Message-ID: <1287204034.18.0.272092469837.issue10058@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Assuming it is true, the rewrite strikes me as an improvement.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10058>
_______________________________________

From report at bugs.python.org  Sat Oct 16 08:35:56 2010
From: report at bugs.python.org (Bob Ippolito)
Date: Sat, 16 Oct 2010 06:35:56 +0000
Subject: [issue5729] Allows tabs for indenting JSON output
In-Reply-To: <1239297330.19.0.24635332127.issue5729@psf.upfronthosting.co.za>
Message-ID: <1287210956.02.0.276700290583.issue5729@psf.upfronthosting.co.za>


Bob Ippolito <bob at redivi.com> added the comment:

Sorry but I don't think I will be able to. I'd be happy to accept patches into simplejson that make it easier to merge with Python 3 in the future, but I simply do not have the time to maintain the Python 3 branch of the code that we don't use.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5729>
_______________________________________

From report at bugs.python.org  Sat Oct 16 09:04:51 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 16 Oct 2010 07:04:51 +0000
Subject: [issue10120] concurrent.futures module is not installed properly
In-Reply-To: <1287212691.14.0.409015662426.issue10120@psf.upfronthosting.co.za>
Message-ID: <1287212691.14.0.409015662426.issue10120@psf.upfronthosting.co.za>


New submission from Neil Muller <drnlmuller+bugs at gmail.com>:

with make install (r85564), lib/python3.2/concurrent is created, but the futures module is not installed there. The attached trivial patch fixes this here.

----------
files: futures-Makefile.diff
keywords: patch
messages: 118858
nosy: Neil Muller
priority: normal
severity: normal
status: open
title: concurrent.futures module is not installed properly
Added file: http://bugs.python.org/file19249/futures-Makefile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10120>
_______________________________________

From report at bugs.python.org  Sat Oct 16 10:29:42 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sat, 16 Oct 2010 08:29:42 +0000
Subject: [issue10119] test_urllibnet failure when using
	support.transient_internet
In-Reply-To: <1287194679.07.0.887400455499.issue10119@psf.upfronthosting.co.za>
Message-ID: <1287217782.56.0.486138963058.issue10119@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Actually, this is not related to transient_internet call. Just that file handle not behaving as expected due to some delays.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10119>
_______________________________________

From report at bugs.python.org  Sat Oct 16 11:19:57 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 16 Oct 2010 09:19:57 +0000
Subject: [issue10120] concurrent.futures module is not installed properly
In-Reply-To: <1287212691.14.0.409015662426.issue10120@psf.upfronthosting.co.za>
Message-ID: <1287220797.09.0.830033808246.issue10120@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

There isn't an entry for anyone in maintainers.rst for concurrent.futures either. That should probably also be fixed.

----------
nosy: +bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10120>
_______________________________________

From report at bugs.python.org  Sat Oct 16 11:34:37 2010
From: report at bugs.python.org (Neil Muller)
Date: Sat, 16 Oct 2010 09:34:37 +0000
Subject: [issue1343] XMLGenerator: nice <empty/> elements
In-Reply-To: <1193492035.12.0.0580891111126.issue1343@psf.upfronthosting.co.za>
Message-ID: <1287221677.83.0.357649292651.issue1343@psf.upfronthosting.co.za>


Neil Muller <drnlmuller+bugs at gmail.com> added the comment:

So what still needs to happen to get this in? 

Patch still applies to current python 3.2 trunk (r85564).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1343>
_______________________________________

From report at bugs.python.org  Sat Oct 16 11:57:18 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Sat, 16 Oct 2010 09:57:18 +0000
Subject: [issue10120] concurrent.futures module is not installed properly
In-Reply-To: <1287212691.14.0.409015662426.issue10120@psf.upfronthosting.co.za>
Message-ID: <1287223038.02.0.695785530056.issue10120@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

I added myself as the maintainer of concurrent.futures.

I'll look at the patch now.

----------
assignee:  -> bquinlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10120>
_______________________________________

From report at bugs.python.org  Sat Oct 16 12:29:08 2010
From: report at bugs.python.org (Retro)
Date: Sat, 16 Oct 2010 10:29:08 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1287224948.44.0.468790907226.issue2775@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

My patch "zipfile-patch.diff" was sent to python-dev. Please act on it as you see fit. Thank you.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Sat Oct 16 12:36:49 2010
From: report at bugs.python.org (Brian Quinlan)
Date: Sat, 16 Oct 2010 10:36:49 +0000
Subject: [issue10120] concurrent.futures module is not installed properly
In-Reply-To: <1287212691.14.0.409015662426.issue10120@psf.upfronthosting.co.za>
Message-ID: <1287225409.32.0.294377415102.issue10120@psf.upfronthosting.co.za>


Brian Quinlan <brian at sweetapp.com> added the comment:

Patch committed in r85567.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10120>
_______________________________________

From report at bugs.python.org  Sat Oct 16 14:11:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Oct 2010 12:11:58 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287231118.41.0.139043613499.issue10114@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Here is a new patch [code_encoding.patch] implementing this idea:
> - Use filesystem encoding (and surrogateescape) to encode/decode
> paths in compile() and the parser, instead of utf-8 in strict mode
> (...)
> The patch restores the situation before #6543.

About Python 3.1 compatibility: Python 3.1 doesn't support non-ascii paths with a locale different than utf-8 (see issue #8611), so it doesn't change anything for Python 3.1 (it doesn't work anyway, with utf-8 or filesystem encoding).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Sat Oct 16 14:22:20 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Oct 2010 12:22:20 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287231740.82.0.627690313762.issue10114@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Oh, I just realized that Python 3.1.2 (last Python 3.1 release) was released the 21st March, whereas r82063 (commit for #6543) was made the 17st June. So the encoding change was not released yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Sat Oct 16 14:39:33 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Sat, 16 Oct 2010 12:39:33 +0000
Subject: [issue10121] test_multiprocessing stuck in test_make_pool if run in a
	loop
In-Reply-To: <1287232773.28.0.893033557088.issue10121@psf.upfronthosting.co.za>
Message-ID: <1287232773.28.0.893033557088.issue10121@psf.upfronthosting.co.za>


New submission from Sandro Tosi <sandro.tosi at gmail.com>:

Hello,
when trying to see if issue6661 was still valid, I run test_multiprocessing in a tight loop and I got it reproducibly stuck on test_make_pool:

...

test_imap_unordered (test.test_multiprocessing.WithManagerTestPool) ... ok
test_make_pool (test.test_multiprocessing.WithManagerTestPool) ... 

when I enter Ctrl+C here's the traceback (on 2.7 HEAD):

test_make_pool (test.test_multiprocessing.WithManagerTestPool) ... ^CProcess PoolWorker-5:3:
Traceback (most recent call last):
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
Process PoolWorker-5:2:
Traceback (most recent call last):
Process PoolWorker-5:4:
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
Traceback (most recent call last):
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
Process PoolWorker-5:1:
Traceback (most recent call last):
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
Process PoolWorker-79:
Process PoolWorker-80:
Traceback (most recent call last):
Traceback (most recent call last):
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 232, in _bootstrap
    self.run()
    self.run()
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 88, in run
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/pool.py", line 59, in worker
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/pool.py", line 59, in worker
    task = get()
    task = get()
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/queues.py", line 352, in get
  File "/home/morph/python-dev/release2.7-maint/Lib/multiprocessing/queues.py", line 350, in get

Test suite interrupted by signal SIGINT.
1 test omitted:
    test_multiprocessing

and on py3k:

test_make_pool (test.test_multiprocessing.WithProcessesTestPool) ... ^CProcess PoolWorker-5:1:
Process PoolWorker-3:
Process PoolWorker-5:3:
Process PoolWorker-5:4:
Process PoolWorker-5:2:
Process PoolWorker-4:
Process PoolWorker-2:
Process PoolWorker-1:
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
Traceback (most recent call last):
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
Traceback (most recent call last):
Traceback (most recent call last):
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap
Process PoolWorker-29:
Traceback (most recent call last):
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 233, in _bootstrap

Test suite interrupted by signal SIGINT.
1 test omitted:
    self.run()
    self.run()
    self.run()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
    self._target(*self._args, **self._kwargs)
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
    self.run()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
    self.run()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
    self.run()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
    self.run()
    self.run()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/process.py", line 88, in run
    self._target(*self._args, **self._kwargs)
    self._target(*self._args, **self._kwargs)
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/pool.py", line 59, in worker
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
    racquire()
KeyboardInterrupt
    racquire()
KeyboardInterrupt
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 352, in get
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
    return recv()
    racquire()
KeyboardInterrupt
KeyboardInterrupt
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
    racquire()
    task = get()
    task = get()
KeyboardInterrupt
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 350, in get
    racquire()
KeyboardInterrupt
    racquire()
KeyboardInterrupt
    task = get()
  File "/home/morph/python-dev/py3k/Lib/multiprocessing/queues.py", line 352, in get
    return recv()
KeyboardInterrupt
    test_multiprocessing

It's reproducible here so I can make any tests you want to verify the problem (I don't know what to look at, sorry); just to give some more info, here's a Debian sid on AMD64.

Cheers,
Sandro

PS: it's my first bug report to python, so please be gentle and forgive any mistakes I could have made :)

----------
components: Tests
messages: 118867
nosy: jnoller, sandro.tosi
priority: normal
severity: normal
status: open
title: test_multiprocessing stuck in test_make_pool if run in a loop
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10121>
_______________________________________

From report at bugs.python.org  Sat Oct 16 15:51:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Oct 2010 13:51:24 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287237084.87.0.966704688984.issue10114@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited to 3.2 (r85569+r85570). I wait for the buildbot before porting the patch to 3.1 and close the issue. There is already a regression on Gentoo buildbot with ascii locale encoding, test_doctest test_zipimport_support:

http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/106

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Sat Oct 16 16:09:04 2010
From: report at bugs.python.org (Retro)
Date: Sat, 16 Oct 2010 14:09:04 +0000
Subject: [issue10122] Documentation typo fix and a side question
In-Reply-To: <1287238144.34.0.432770346734.issue10122@psf.upfronthosting.co.za>
Message-ID: <1287238144.34.0.432770346734.issue10122@psf.upfronthosting.co.za>


New submission from Retro <vinetouu at gmail.com>:

Please read the first sentence of the docs for the built-in function getattr() here: http://docs.python.org/library/functions.html?highlight=getattr#getattr

Fix the word 'attributed' to 'attribute', because the former is a typo.



A side question. When you document an object's API in the docstring, you write it like this:
getattr(object, name[, default]) -> value

Don't you find it nicer if that would look like this:
getattr(object, name, [default]) -> value

Note the cosmetic fix between the arguments 'name' and 'default'. Do you find my fix acceptable? If yes, please fix docstrings in Python that document the object's API from the '...name[, default]...' format to '...name, [default]...' format.

----------
assignee: docs at python
components: Documentation
messages: 118869
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Documentation typo fix and a side question
versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10122>
_______________________________________

From report at bugs.python.org  Sat Oct 16 16:15:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Oct 2010 14:15:54 +0000
Subject: [issue10123] test_doctest failure with ASCII filesystem encoding
In-Reply-To: <1287238554.77.0.835644404703.issue10123@psf.upfronthosting.co.za>
Message-ID: <1287238554.77.0.835644404703.issue10123@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

In #10114, I changed parser filename encoding from utf-8/strict to the filesystem encoding/surrogateescape. With C locale, the filesystem encoding is ASCII and test_doctest fails because it uses an unencoable filename (foo-b?r at baz.py).

A solution is to write a test specific to non-ascii filenames and skip it if the filename is not encodable (try if os.fsencode() raises an UnicodeEncodeError or not), and use only ascii filenames in the other tests.

----------
components: Tests, Unicode
messages: 118870
nosy: haypo
priority: normal
severity: normal
status: open
title: test_doctest failure with ASCII filesystem encoding
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10123>
_______________________________________

From report at bugs.python.org  Sat Oct 16 16:16:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Oct 2010 14:16:13 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287238573.46.0.359926896469.issue10114@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I created #10123 for the test_doctest regression.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Sat Oct 16 16:23:54 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 16 Oct 2010 14:23:54 +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: <1287239034.63.0.413889841773.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Interestingly enough, the distutils failure that dmalcolm found was present in the trunk even before my patch.  If you build Python with --enable-shared, that distutils test fails because of the default path used for the -L option.  I fixed that in my patch, but it was unrelated to the changes I made to expose sys.abiflags.

I wonder if we should try to get a buildbot up that uses --enable-shared?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Sat Oct 16 17:19:26 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 16 Oct 2010 15:19:26 +0000
Subject: [issue10098] intermittent failure in test_os
In-Reply-To: <1287045270.71.0.765573711319.issue10098@psf.upfronthosting.co.za>
Message-ID: <1287242366.1.0.46330167468.issue10098@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry about this. And thank you for fix.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10098>
_______________________________________

From report at bugs.python.org  Sat Oct 16 17:31:52 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 16 Oct 2010 15:31:52 +0000
Subject: [issue5736] Add the iterator protocol to dbm modules
In-Reply-To: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
Message-ID: <1287243112.16.0.414931763933.issue5736@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


Removed file: http://bugs.python.org/file13673/issue5736.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5736>
_______________________________________

From report at bugs.python.org  Sat Oct 16 17:32:02 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 16 Oct 2010 15:32:02 +0000
Subject: [issue5736] Add the iterator protocol to dbm modules
In-Reply-To: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
Message-ID: <1287243122.16.0.739034138638.issue5736@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


Removed file: http://bugs.python.org/file13674/issue5736.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5736>
_______________________________________

From report at bugs.python.org  Sat Oct 16 17:32:06 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 16 Oct 2010 15:32:06 +0000
Subject: [issue5736] Add the iterator protocol to dbm modules
In-Reply-To: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
Message-ID: <1287243126.08.0.998441780203.issue5736@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


Removed file: http://bugs.python.org/file13682/test_issue5736.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5736>
_______________________________________

From report at bugs.python.org  Sat Oct 16 17:32:10 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 16 Oct 2010 15:32:10 +0000
Subject: [issue5736] Add the iterator protocol to dbm modules
In-Reply-To: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
Message-ID: <1287243130.16.0.835714599084.issue5736@psf.upfronthosting.co.za>


Changes by Akira Kitada <akitada at gmail.com>:


Removed file: http://bugs.python.org/file13676/issue5736.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5736>
_______________________________________

From report at bugs.python.org  Sat Oct 16 17:47:03 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sat, 16 Oct 2010 15:47:03 +0000
Subject: [issue5736] Add the iterator protocol to dbm modules
In-Reply-To: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
Message-ID: <1287244023.3.0.342173560313.issue5736@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

This patch just uses PyObject_GetIter to get an iter.
(I just copied the idea from issue9523)

----------
nosy: +ysj.ray
versions: +Python 3.2 -Python 2.7
Added file: http://bugs.python.org/file19250/issue5736.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5736>
_______________________________________

From report at bugs.python.org  Sat Oct 16 17:48:48 2010
From: report at bugs.python.org (Paul Bolle)
Date: Sat, 16 Oct 2010 15:48:48 +0000
Subject: [issue10124] obvious typo in cporting HOWTO
In-Reply-To: <1287244128.31.0.267492647227.issue10124@psf.upfronthosting.co.za>
Message-ID: <1287244128.31.0.267492647227.issue10124@psf.upfronthosting.co.za>


New submission from Paul Bolle <pebolle at tiscali.nl>:

0) There's an obvious typo in the cporting HOWTO:

[...] It?s also important to remember that PyBytes and PyUnicode in 3.0 are not interchangeable like PyString and PyString are in 2.x. [...]

That PyString and PyString are interchangeable is obviously not what the author wanted to tell.

1) I'll attach a patch to change this into what I suppose the author had in mind. (If I knew for sure I wouldn't have read that HOWTO in the first place.)

----------
assignee: docs at python
components: Documentation
files: python-2.7-Doc-pystring.patch
keywords: patch
messages: 118875
nosy: docs at python, pebolle
priority: normal
severity: normal
status: open
title: obvious typo in cporting HOWTO
Added file: http://bugs.python.org/file19251/python-2.7-Doc-pystring.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10124>
_______________________________________

From report at bugs.python.org  Sat Oct 16 18:28:50 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Oct 2010 16:28:50 +0000
Subject: [issue10122] Documentation typo fix and a side question
In-Reply-To: <1287238144.34.0.432770346734.issue10122@psf.upfronthosting.co.za>
Message-ID: <1287246530.52.0.263551577672.issue10122@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

No, that would be incorrect syntax (if you omit the optional argument you should also omit the comma that precedes it).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10122>
_______________________________________

From report at bugs.python.org  Sat Oct 16 18:29:36 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Oct 2010 16:29:36 +0000
Subject: [issue10122] Documentation typo fix and a side question
In-Reply-To: <1287238144.34.0.432770346734.issue10122@psf.upfronthosting.co.za>
Message-ID: <1287246576.82.0.751373866505.issue10122@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
type:  -> behavior
versions:  -3rd party, Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10122>
_______________________________________

From report at bugs.python.org  Sat Oct 16 19:00:21 2010
From: report at bugs.python.org (intuited)
Date: Sat, 16 Oct 2010 17:00:21 +0000
Subject: [issue10125] Closing a file within its writelines method causes
	segfault
In-Reply-To: <1287248421.18.0.88895338197.issue10125@psf.upfronthosting.co.za>
Message-ID: <1287248421.18.0.88895338197.issue10125@psf.upfronthosting.co.za>


New submission from intuited <cecinemapasderange at gmail.com>:

Discovered when using the current Ubuntu 10.04 package of Python: 2.6.5-0ubuntu1

Reproducible with ::

    outfile = open("tmpout", "w")
    outfile.writelines(f() or "line" for f in (outfile.close,))

This problem is probably most likely to be encountered when using the ``fileinput`` module, because of the way it abstracts away the closing of files.  E.G.::

    from fileinput import input
    lines = input("tmpout", inplace=1)
    first = lines.next()
    from sys import stdout
    stdout.writelines(lines)

Both of the above pieces of code cause Segmentation Faults.

It looks like in line 1779 of ``Objects/fileobject.c``, ``f->fp`` is being passed to ``fwrite`` as 0.  I guess this happens because no check is done after the call to ``PyIter_Next`` on line 1730 to see if the file is still open.

I don't see this as a big issue, though it is annoying that it seemingly prevents generators from being used with the `fileinput` module.  Doing so would be a bit awkward and hacky anyway though.

----------
components: IO
messages: 118877
nosy: intuited
priority: normal
severity: normal
status: open
title: Closing a file within its writelines method causes segfault
type: crash
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10125>
_______________________________________

From report at bugs.python.org  Sat Oct 16 19:34:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Oct 2010 17:34:54 +0000
Subject: [issue9308] Remove redundant coding cookies from 3.x stdlib
In-Reply-To: <1279565829.31.0.797750861129.issue9308@psf.upfronthosting.co.za>
Message-ID: <1287250494.68.0.0473184894362.issue9308@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I yhink you need to add an svnignore property to that directory for __pycache__.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9308>
_______________________________________

From report at bugs.python.org  Sat Oct 16 20:39:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Oct 2010 18:39:25 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1287254365.77.0.126206728041.issue10089@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a new patch renaming the attribute to sys._xoptions, and adding some docs.

----------
Added file: http://bugs.python.org/file19252/xopts2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Sat Oct 16 20:51:37 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 Oct 2010 18:51:37 +0000
Subject: [issue10122] Documentation typo fix and a side question
In-Reply-To: <1287238144.34.0.432770346734.issue10122@psf.upfronthosting.co.za>
Message-ID: <1287255097.83.0.0906821721421.issue10122@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Typo fixed in r85572.  Otherwise, as David says.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10122>
_______________________________________

From report at bugs.python.org  Sat Oct 16 20:53:42 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 Oct 2010 18:53:42 +0000
Subject: [issue10124] obvious typo in cporting HOWTO
In-Reply-To: <1287244128.31.0.267492647227.issue10124@psf.upfronthosting.co.za>
Message-ID: <1287255222.18.0.216695966722.issue10124@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't think this is what was intended; rather str and unicode.  Fixed in r85573.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10124>
_______________________________________

From report at bugs.python.org  Sat Oct 16 21:20:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 16 Oct 2010 19:20:48 +0000
Subject: [issue10125] Closing a file within its writelines method causes
	segfault
In-Reply-To: <1287248421.18.0.88895338197.issue10125@psf.upfronthosting.co.za>
Message-ID: <1287256848.83.0.116235913441.issue10125@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85574

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10125>
_______________________________________

From report at bugs.python.org  Sat Oct 16 21:25:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 16 Oct 2010 19:25:06 +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: <1287257106.1.0.0111777113858.issue9807@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> I fixed that in my patch, but it was unrelated to the changes I made to expose sys.abiflags.

Would you mind committing that part independently of the rest?

> I wonder if we should try to get a buildbot up that uses --enable-shared?

If the option has significant use, why not.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Sat Oct 16 21:25:14 2010
From: report at bugs.python.org (Bill Janssen)
Date: Sat, 16 Oct 2010 19:25:14 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1287257114.62.0.283128342458.issue8845@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

PPC Tiger is using Python 2.7, so it's 3.6.11.

Python 3.X also seems to be failing the sqlite tests on PPC Leopard.  Is the required version # different between 3.1 and 3.x?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Sat Oct 16 21:36:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Oct 2010 19:36:29 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287257789.45.0.954843218718.issue10115@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Weekend is coming, so I can lend a hand in implementing whatever you
> choose.

I don't have any strong opinion about it, so it's whichever you prefer really :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Sat Oct 16 21:38:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Oct 2010 19:38:47 +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: <1287257927.54.0.276678688589.issue9807@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(barry)
> I wonder if we should try to get a buildbot up that uses --enable-
> shared?
(?ric)
> If the option has significant use, why not.

Well, it's all the more significant that most Linux distros use shared libraries, so they will use that option.
I'll look into changing a buildbot to use --enable-shared, then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Sat Oct 16 21:39:22 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 Oct 2010 19:39:22 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1287257962.53.0.389906649566.issue10089@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'd prefer "-X key[=val]" without the possibility to mention multiple key=val pairs, so that val can contain anything (commata in particular).

Otherwise, the change looks fine to me.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Sat Oct 16 21:57:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Oct 2010 19:57:01 +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: <1287259021.26.0.38292085167.issue9807@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've done so on one of the stable buildbots. Let's see how it behaves:

http://www.python.org/dev/buildbot/builders/x86%20Ubuntu%20Shared%203.x/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Sat Oct 16 22:03:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Oct 2010 20:03:17 +0000
Subject: [issue5729] Allows tabs for indenting JSON output
In-Reply-To: <1239297330.19.0.24635332127.issue5729@psf.upfronthosting.co.za>
Message-ID: <1287259397.52.0.0882056062467.issue5729@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: bob.ippolito -> 
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5729>
_______________________________________

From report at bugs.python.org  Sat Oct 16 22:15:49 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 16 Oct 2010 20:15:49 +0000
Subject: [issue9308] Remove redundant coding cookies from 3.x stdlib
In-Reply-To: <1287250494.68.0.0473184894362.issue9308@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=3pBQXnFNdABjmXweUxZ-NvMSWrHMm1YR_hCDc@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sat, Oct 16, 2010 at 1:34 PM, R. David Murray <report at bugs.python.org> wrote:
..
> I yhink you need to add an svnignore property to that directory for __pycache__.

r85576 (I hope I got it right.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9308>
_______________________________________

From report at bugs.python.org  Sat Oct 16 22:25:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Oct 2010 20:25:52 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This happens on Python 3.1:

/usr/bin/ld: cannot find -lpython3.1
collect2: ld returned 1 exit status
test test_distutils failed -- Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/unixccompiler.py", line 254, in link
    self.spawn(linker + ld_args)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/ccompiler.py", line 909, in spawn
    spawn(cmd, dry_run=self.dry_run)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/spawn.py", line 34, in spawn
    _spawn_posix(cmd, search_path, dry_run=dry_run)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/spawn.py", line 138, in _spawn_posix
    % (cmd[0], exit_status))
distutils.errors.DistutilsExecError: command 'gcc' failed with exit status 1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/tests/test_build_ext.py", line 321, in test_get_outputs
    cmd.run()
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/command/build_ext.py", line 347, in run
    self.build_extensions()
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/command/build_ext.py", line 456, in build_extensions
    self.build_extension(ext)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/command/build_ext.py", line 543, in build_extension
    target_lang=language)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/ccompiler.py", line 719, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/srv/buildbot/buildarea/3.1.bolen-ubuntu/build/Lib/distutils/unixccompiler.py", line 256, in link
    raise LinkError(msg)
distutils.errors.LinkError: command 'gcc' failed with exit status 1

(from http://www.python.org/dev/buildbot/builders/x86%20Ubuntu%20Shared%203.1/builds/1132/steps/test/logs/stdio )

Since it is on one of the stable buildbots, it might be considered release-blocking.

----------
components: Tests
messages: 118890
nosy: barry, eric.araujo, pitrou, tarek
priority: high
severity: normal
stage: needs patch
status: open
title: test_distutils failure with --enable-shared
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Sat Oct 16 22:37:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Oct 2010 20:37:05 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287261425.4.0.0738268805754.issue10126@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Similar failure on 2.7:

/usr/bin/ld: cannot find -lpython2.7
collect2: ld returned 1 exit status
test test_distutils failed -- Traceback (most recent call last):
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/distutils/tests/test_build_ext.py", line 269, in test_get_outputs
    cmd.run()
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/distutils/command/build_ext.py", line 340, in run
    self.build_extensions()
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/distutils/command/build_ext.py", line 449, in build_extensions
    self.build_extension(ext)
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/distutils/command/build_ext.py", line 531, in build_extension
    target_lang=language)
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/distutils/ccompiler.py", line 741, in link_shared_object
    extra_preargs, extra_postargs, build_temp, target_lang)
  File "/srv/buildbot/buildarea/2.7.bolen-ubuntu/build/Lib/distutils/unixccompiler.py", line 258, in link
    raise LinkError, msg
LinkError: command 'gcc' failed with exit status 1

----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Sat Oct 16 22:38:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 16 Oct 2010 20:38:17 +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: <1287261497.98.0.762086995405.issue9807@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Barry: I had misunderstood your message, so disregard my request for commit (since the fix you mention *is* committed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Sat Oct 16 22:43:51 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sat, 16 Oct 2010 20:43:51 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287261831.24.0.003427335658.issue10126@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I fixed this in py3k branch, so you just need to backport that.  I can do if you can't get to it in the next day or so.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Sat Oct 16 22:47:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Oct 2010 20:47:13 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287261831.24.0.003427335658.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287262028.3470.64.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le samedi 16 octobre 2010 ? 20:43 +0000, Barry A. Warsaw a ?crit :
> Barry A. Warsaw <barry at python.org> added the comment:
> 
> I fixed this in py3k branch, so you just need to backport that.  I can
> do if you can't get to it in the next day or so.

I don't know how to do it so, yes, it would be better if you do :)
Thanks for caring!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Sat Oct 16 23:03:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Oct 2010 21:03:54 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1287263034.07.0.0729646708387.issue8845@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The attribute and test aren't in 3.1 (or 2.7), so this issue only applies to 3.x trunk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Sat Oct 16 23:14:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Oct 2010 21:14:34 +0000
Subject: [issue10127] ssl.SSLSocket().close() does not close the connection
In-Reply-To: <1287263674.2.0.992398068639.issue10127@psf.upfronthosting.co.za>
Message-ID: <1287263674.2.0.992398068639.issue10127@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Quoting PoltoS from issue 8293:

If I do sock.close() (sock is instance of ssl.SSLSocket), the connection is not closed: I see it as Established in netstat and nothing is sent over network: tcpdump show nothing going thru the network.

----------
components: Library (Lib)
messages: 118896
nosy: PoltoS, TTT, amaury.forgeotdarc, dandrzejewski, eric.smith, giampaolo.rodola, orsenthil, pitrou, r.david.murray
priority: normal
severity: normal
status: open
title: ssl.SSLSocket().close() does not close the connection
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10127>
_______________________________________

From report at bugs.python.org  Sat Oct 16 23:16:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 16 Oct 2010 21:16:33 +0000
Subject: [issue8293] HTTPSConnection.close() does not immediately close the
	connection.
In-Reply-To: <1270234708.91.0.197021276581.issue8293@psf.upfronthosting.co.za>
Message-ID: <1287263793.67.0.879609553827.issue8293@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I opened issue 10127 for the ssl.SSLSocket().close() problem.

----------
resolution: works for me -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8293>
_______________________________________

From report at bugs.python.org  Sat Oct 16 23:24:51 2010
From: report at bugs.python.org (PoltoS)
Date: Sat, 16 Oct 2010 21:24:51 +0000
Subject: [issue10127] ssl.SSLSocket().close() does not close the connection
In-Reply-To: <1287263674.2.0.992398068639.issue10127@psf.upfronthosting.co.za>
Message-ID: <1287264291.67.0.753158338829.issue10127@psf.upfronthosting.co.za>


PoltoS <poltorak at alsenet.com> added the comment:

After some investigations it seems that a dup() is called in ssl wrap_socket(), so on sock.close() the socket is not really closed, since there is still one more reference (file descriptor) in the kernel's tcp/ip stack. Can someone confirm this?

Have not done this, but it is possible to check my supposition using linux lsof command before and after .close().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10127>
_______________________________________

From report at bugs.python.org  Sat Oct 16 23:30:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Oct 2010 21:30:46 +0000
Subject: [issue10127] ssl.SSLSocket().close() does not close the connection
In-Reply-To: <1287263674.2.0.992398068639.issue10127@psf.upfronthosting.co.za>
Message-ID: <1287264646.62.0.8894102432.issue10127@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I cannot reproduce with 2.7, 3.1 or 3.2. It seems the issue is obsolete, many changes having been made to the ssl module since 2.6.

----------
resolution:  -> out of date
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10127>
_______________________________________

From report at bugs.python.org  Sat Oct 16 23:52:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Oct 2010 21:52:14 +0000
Subject: [issue10123] test_doctest failure with ASCII filesystem encoding
In-Reply-To: <1287238554.77.0.835644404703.issue10123@psf.upfronthosting.co.za>
Message-ID: <1287265934.51.0.210716683932.issue10123@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Failures occurred on:
http://www.python.org/dev/buildbot/builders/AMD64%20Gentoo%20Wide%203.x
http://www.python.org/dev/buildbot/builders/sparc%20solaris10%20gcc%203.x

test_zipimport_support does also fail, but it is linked to test_doctest failures.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10123>
_______________________________________

From report at bugs.python.org  Sat Oct 16 23:55:17 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 16 Oct 2010 21:55:17 +0000
Subject: [issue10123] test_doctest failure with ASCII filesystem encoding
In-Reply-To: <1287238554.77.0.835644404703.issue10123@psf.upfronthosting.co.za>
Message-ID: <1287266117.65.0.897384742033.issue10123@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r85578.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10123>
_______________________________________

From report at bugs.python.org  Sun Oct 17 00:10:42 2010
From: report at bugs.python.org (benrg)
Date: Sat, 16 Oct 2010 22:10:42 +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: <1287267042.51.0.610319560609.issue5391@psf.upfronthosting.co.za>


benrg <benrudiak at gmail.com> added the comment:

With this patch, read_byte returns an integer in the range -128 to 127 instead of 0 to 255 if char is signed. Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32 is affected by this. I think it is a bug. The test code would fail if the test string contained any bytes outside the ASCII range.

(Did this really go unnoticed for a year and a half? I noticed it the moment I first tried to use read_byte (which was just now). I see that read_byte was broken in a different way in 3.0. Does anybody actually use it?)

----------
nosy: +benrg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5391>
_______________________________________

From report at bugs.python.org  Sun Oct 17 00:15:14 2010
From: report at bugs.python.org (Retro)
Date: Sat, 16 Oct 2010 22:15:14 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287267314.77.0.726888135348.issue10073@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

Please leave this function as is because it works just fine.

>>> calendar.isleap(2011)
False


The argument for isleap() must not be in quotes. That's all.

----------
nosy: +Retro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Sun Oct 17 00:21:37 2010
From: report at bugs.python.org (Retro)
Date: Sat, 16 Oct 2010 22:21:37 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287267697.78.0.466583189081.issue10073@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

I would just add an exception to the isleap() function.

def isleap(year):
    """Return 1 for leap years, 0 for non-leap years."""
    try:
        return year % 4 == 0 and (year % 100 != 0 or year % 400 == 0)
    except TypeError:
        # somehow inform the user that the argument 'year' must be an integer

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Sun Oct 17 00:32:30 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 16 Oct 2010 22:32:30 +0000
Subject: [issue5729] Allows tabs for indenting JSON output
In-Reply-To: <1239297330.19.0.24635332127.issue5729@psf.upfronthosting.co.za>
Message-ID: <1287268350.62.0.56759226536.issue5729@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/issue5729>
_______________________________________

From report at bugs.python.org  Sun Oct 17 00:41:53 2010
From: report at bugs.python.org (Michael Olson)
Date: Sat, 16 Oct 2010 22:41:53 +0000
Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py
In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>
Message-ID: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>


New submission from Michael Olson <olson at irinim.net>:

In an application with an entry point of __main__.py, multiprocessing.Pool throws the following:

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "D:\Dev\Python27\lib\multiprocessing\forking.py", line 346, in main
    prepare(preparation_data)
  File "D:\Dev\Python27\lib\multiprocessing\forking.py", line 454, in prepare
    assert main_name not in sys.modules, main_name
AssertionError: __main__

These messages repeat as long as the application is running.

Demonstration Code, must be in file named __main__.py:
--------------------
import multiprocessing
import time

if __name__ == '__main__':
    pool = multiprocessing.Pool()
    time.sleep(2)
--------------------

----------
components: Library (Lib)
messages: 118905
nosy: Michael.Olson
priority: normal
severity: normal
status: open
title: multiprocessing.Pool throws exception with __main__.py
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10128>
_______________________________________

From report at bugs.python.org  Sun Oct 17 01:17:05 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Sat, 16 Oct 2010 23:17:05 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287271025.27.0.0450994402396.issue10115@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Made a proof of concept patch (no doc updates yet). Decided to implement separate accept4() method, cause we have already spent enough time dealing with it and rollback would be pity.

----------
keywords: +patch
Added file: http://bugs.python.org/file19253/issue10115_first_attempt.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Sun Oct 17 02:03:21 2010
From: report at bugs.python.org (Akira Kitada)
Date: Sun, 17 Oct 2010 00:03:21 +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: <1287273801.77.0.093624047725.issue10052@psf.upfronthosting.co.za>


Akira Kitada <akitada at gmail.com> added the comment:

This patch is specifically targeted at FreeBSD 4.
tested on FreeBSD 4.11 and OS X 10.6.4

I don't know how to accommodate SGI IRIX's case.

----------
keywords: +patch
Added file: http://bugs.python.org/file19254/issue10052.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10052>
_______________________________________

From report at bugs.python.org  Sun Oct 17 02:31:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Oct 2010 00:31:23 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1287275483.55.0.950284360791.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Status of this issue, 5 months later: most tests pass except test_gc test_gdb test_runpy test_sys test_wsgiref test_zipimport. Said differently, 95% of the task (or more?) is done. It's possible to run Python installed in a non-ascii directory with any locale (I tested ascii, iso-8859-1 and utf-8).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Sun Oct 17 02:38:41 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Oct 2010 00:38:41 +0000
Subject: [issue1533105] NetBSD build with --with-pydebug causes SIGSEGV
Message-ID: <1287275921.23.0.212458799176.issue1533105@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I don't see this issue on netbsd 5.0.2 i386 in the py3k branch.

----------
nosy: +gregory.p.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533105>
_______________________________________

From report at bugs.python.org  Sun Oct 17 02:44:12 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Oct 2010 00:44:12 +0000
Subject: [issue5510] patches for Modules/socketmodule.c for NetBSD
In-Reply-To: <1237400494.47.0.163345338744.issue5510@psf.upfronthosting.co.za>
Message-ID: <1287276252.04.0.530145211582.issue5510@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

netbsd-wizs-mod.patch applied in 85587.

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
resolution:  -> accepted
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5510>
_______________________________________

From report at bugs.python.org  Sun Oct 17 04:04:26 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 17 Oct 2010 02:04:26 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1287281066.05.0.839429773512.issue8845@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

FYI, in a recent py3k installer build test using the same installer image (2-way i386/ppc universal with statically linked sqlite 3.6.11), the test fails on ppc G3 (10.4), ppc g4 (10.5) but passes on i386 (10.6) so I'd go along with Bill's big- vs little-endian hypothesis.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Sun Oct 17 04:26:07 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 17 Oct 2010 02:26:07 +0000
Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py
In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>
Message-ID: <1287282367.29.0.7213606857.issue10128@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10128>
_______________________________________

From report at bugs.python.org  Sun Oct 17 04:58:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Oct 2010 02:58:53 +0000
Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py
In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>
Message-ID: <1287284333.06.0.549218213591.issue10128@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10128>
_______________________________________

From report at bugs.python.org  Sun Oct 17 05:17:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Oct 2010 03:17:27 +0000
Subject: [issue3482] re.split, re.sub and re.subn should support flags
In-Reply-To: <1217575222.11.0.84305922701.issue3482@psf.upfronthosting.co.za>
Message-ID: <1287285447.83.0.526385080838.issue3482@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For reference, the py3k rev was r70091.

----------
nosy: +r.david.murray
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3482>
_______________________________________

From report at bugs.python.org  Sun Oct 17 05:37:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Oct 2010 03:37:51 +0000
Subject: [issue10090] python -m locale fails on OSX
In-Reply-To: <1286998392.83.0.0924618610068.issue10090@psf.upfronthosting.co.za>
Message-ID: <1287286671.07.0.101806296837.issue10090@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10090>
_______________________________________

From report at bugs.python.org  Sun Oct 17 05:42:27 2010
From: report at bugs.python.org (Andreas Kloeckner)
Date: Sun, 17 Oct 2010 03:42:27 +0000
Subject: [issue10129] Curious 'name not defined error' with 'python -m'
In-Reply-To: <1287286947.38.0.536856909733.issue10129@psf.upfronthosting.co.za>
Message-ID: <1287286947.38.0.536856909733.issue10129@psf.upfronthosting.co.za>


New submission from Andreas Kloeckner <inform at tiker.net>:

$ python3.1 -m a b.py

results in

Traceback (most recent call last):
  File "/usr/lib/python3.1/runpy.py", line 128, in _run_module_as_main
    "__main__", fname, loader, pkg_name)
  File "/usr/lib/python3.1/runpy.py", line 34, in _run_code
    exec(code, run_globals)
  File "/home/andreas/tmp/python-mbug/a.py", line 6, in <module>
    main()
  File "/home/andreas/tmp/python-mbug/a.py", line 3, in main
    exec(compile(open(sys.argv[1]).read(), sys.argv[1], 'exec'))
  File "b.py", line 8, in <module>
    sys.exit(main())
  File "b.py", line 5, in main
    argv = sys.argv[1:]
NameError: global name 'sys' is not defined

a.py --------------------------------------------------
def main():
    import sys
    exec(compile(open(sys.argv[1]).read(), sys.argv[1], 'exec'))

if __name__=='__main__':
    main()
-------------------------------------------------------

b.py --------------------------------------------------
import sys

def main():
  sys.argv[1:]

if __name__ == "__main__":
  main()
-------------------------------------------------------

----------
components: Interpreter Core
messages: 118913
nosy: inducer
priority: normal
severity: normal
status: open
title: Curious 'name not defined error' with 'python -m'
type: behavior
versions: Python 2.6, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10129>
_______________________________________

From report at bugs.python.org  Sun Oct 17 05:48:05 2010
From: report at bugs.python.org (Andreas Kloeckner)
Date: Sun, 17 Oct 2010 03:48:05 +0000
Subject: [issue4949] Constness in PyErr_NewException
In-Reply-To: <1231956299.48.0.0179649567226.issue4949@psf.upfronthosting.co.za>
Message-ID: <1287287285.87.0.351833014051.issue4949@psf.upfronthosting.co.za>


Andreas Kloeckner <inform at tiker.net> added the comment:

ping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4949>
_______________________________________

From report at bugs.python.org  Sun Oct 17 08:03:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 06:03:11 +0000
Subject: [issue10129] Curious 'name not defined error' with 'python -m'
In-Reply-To: <1287286947.38.0.536856909733.issue10129@psf.upfronthosting.co.za>
Message-ID: <1287295391.06.0.333949641566.issue10129@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

(This is not specific to running with -m, it occurs as well when you do "python a.py b.py".)

The issue here is your call to exec() does not execute the code as its own module.  It executes the code as part of the main() function in a.py, with (since you don't give a global namespace argument) the same global namespace as that of a.main(), and there is no "sys" in that namespace.  Further, the compiler cannot treat b.main like a nested function of a.main (which would then create a closure over the "sys" imported inside a.main).  Therefore, the reference to sys is treated as a global and not found.

If you give the exec() function an explicit dictionary as the globals argument, this "works":

def main():
    d = {'__name__': '__main__'}
    exec(compile(open(sys.argv[1]).read(), sys.argv[1], 'exec'), d)

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10129>
_______________________________________

From report at bugs.python.org  Sun Oct 17 08:34:47 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 06:34:47 +0000
Subject: [issue10058] C-API Intro should be more explicit about error return
	codes
In-Reply-To: <1286667477.81.0.428824967814.issue10058@psf.upfronthosting.co.za>
Message-ID: <1287297287.51.0.347809803759.issue10058@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed a change in that spirit in r85606.  Thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10058>
_______________________________________

From report at bugs.python.org  Sun Oct 17 08:35:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 06:35:48 +0000
Subject: [issue10024] Outdated advice in C-API tutorial?
In-Reply-To: <1286228751.32.0.127029935422.issue10024@psf.upfronthosting.co.za>
Message-ID: <1287297348.34.0.376646052647.issue10024@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10024>
_______________________________________

From report at bugs.python.org  Sun Oct 17 11:19:13 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 09:19:13 +0000
Subject: [issue8556] Confusing string formatting examples
In-Reply-To: <1272430647.21.0.217416978231.issue8556@psf.upfronthosting.co.za>
Message-ID: <1287307153.0.0.455073929131.issue8556@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r85609.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8556>
_______________________________________

From report at bugs.python.org  Sun Oct 17 11:23:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 09:23:16 +0000
Subject: [issue8686] "This isn't defined beyond that" phrase is not friendly
	to non-native English speakers.
In-Reply-To: <1273576436.16.0.861526907899.issue8686@psf.upfronthosting.co.za>
Message-ID: <1287307396.67.0.8460264315.issue8686@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Removed gloss in r85610.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8686>
_______________________________________

From report at bugs.python.org  Sun Oct 17 11:33:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 09:33:32 +0000
Subject: [issue8811] fixing sqlite3 docs for py3k
In-Reply-To: <1274731029.07.0.155563755489.issue8811@psf.upfronthosting.co.za>
Message-ID: <1287308012.01.0.214535517123.issue8811@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This was mostly fixed already, committed rest in r85611.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8811>
_______________________________________

From report at bugs.python.org  Sun Oct 17 11:35:04 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 09:35:04 +0000
Subject: [issue8818] urlsplit and urlparse add extra slash when using scheme
In-Reply-To: <1274798419.99.0.107317054505.issue8818@psf.upfronthosting.co.za>
Message-ID: <1287308104.69.0.369450505609.issue8818@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/issue8818>
_______________________________________

From report at bugs.python.org  Sun Oct 17 11:38:14 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 09:38:14 +0000
Subject: [issue8855] Shelve documentation lacks security warning
In-Reply-To: <1275180833.97.0.966181786946.issue8855@psf.upfronthosting.co.za>
Message-ID: <1287308294.62.0.333761424637.issue8855@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r85612, will be merged to the other maintained branches.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8855>
_______________________________________

From report at bugs.python.org  Sun Oct 17 11:46:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 09:46:24 +0000
Subject: [issue8968] token type constants are not documented
In-Reply-To: <1276216063.7.0.11813766705.issue8968@psf.upfronthosting.co.za>
Message-ID: <1287308784.91.0.339002134817.issue8968@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r85614.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8968>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:05:35 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 10:05:35 +0000
Subject: [issue459007] Document sys.path on Windows
Message-ID: <1287309935.08.0.504071845213.issue459007@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the patch, merged with existing info in using/windows.rst in r85615.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue459007>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:09:17 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 10:09:17 +0000
Subject: [issue5212] Incorrect note about md5 in hmac module documentation
In-Reply-To: <1234312792.25.0.547667950303.issue5212@psf.upfronthosting.co.za>
Message-ID: <1287310157.65.0.0734865905064.issue5212@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Removed note in r85617.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5212>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:15:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 10:15:55 +0000
Subject: [issue9086] Wrong linking terminology in windows FAQ
In-Reply-To: <1277546739.53.0.554976149521.issue9086@psf.upfronthosting.co.za>
Message-ID: <1287310555.04.0.898354312243.issue9086@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Okay, I removed mention of static linking and used John's terms "load-time" and "run-time" linking in r85618.  I also removed the note that pythonXY.dll is only needed in one case, since it's not true.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9086>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:26:09 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 10:26:09 +0000
Subject: [issue9105] pickle security note should be more prominent
In-Reply-To: <1277745956.4.0.951690442784.issue9105@psf.upfronthosting.co.za>
Message-ID: <1287311169.11.0.000797017930108.issue9105@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Moved pickle warning in r85621.  A warning in shelve was already added for issue8855.

For the tutorial, I don't think a warning needs to be added.  Same goes for logging.

----------
nosy: +georg.brandl
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9105>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:28:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 10:28:16 +0000
Subject: [issue9112] argparse missing documentation for error() method
In-Reply-To: <1277798810.6.0.529590004484.issue9112@psf.upfronthosting.co.za>
Message-ID: <1287311296.86.0.357893359491.issue9112@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed after review in r85622. Thanks!

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9112>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:38:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 10:38:27 +0000
Subject: [issue9117] class syntax not fully documented in reference manual
In-Reply-To: <1277830360.72.0.109155081636.issue9117@psf.upfronthosting.co.za>
Message-ID: <1287311907.81.0.22967382618.issue9117@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This patch was mostly out-of-date since PEP 3115 metaclasses are now documented; I've merged what was missing in r85626.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9117>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:44:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 10:44:51 +0000
Subject: [issue9138] Tutorial: classes intro paragraph icky
In-Reply-To: <1278020934.41.0.867324522486.issue9138@psf.upfronthosting.co.za>
Message-ID: <1287312291.69.0.422651744494.issue9138@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed Aahz' version, with the last sentence reworded to what I think is more positive than what sounds like "you can break things without doing anything".

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9138>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:44:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 10:44:59 +0000
Subject: [issue9138] Tutorial: classes intro paragraph icky
In-Reply-To: <1278020934.41.0.867324522486.issue9138@psf.upfronthosting.co.za>
Message-ID: <1287312299.96.0.0572377960329.issue9138@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

r85627.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9138>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:47:31 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 10:47:31 +0000
Subject: [issue9195] Link in docs from "String Formatting Operations" to
	"Template Strings"
In-Reply-To: <1278571007.55.0.304215462236.issue9195@psf.upfronthosting.co.za>
Message-ID: <1287312451.47.0.933485977782.issue9195@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Mostly out of date now that we have str.format().

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9195>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:52:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 10:52:11 +0000
Subject: [issue5962] Ambiguity about the semantics of sys.exit() and
	os._exit() in multithreaded program
In-Reply-To: <1241722395.44.0.880118568656.issue5962@psf.upfronthosting.co.za>
Message-ID: <1287312731.11.0.430580993613.issue5962@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added a note about threads to sys.exit(), and changed os._exit() wording to be clear about process exit, in r85629.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5962>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:54:18 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 17 Oct 2010 10:54:18 +0000
Subject: [issue10119] test_urllibnet failure when using
	support.transient_internet
In-Reply-To: <1287194679.07.0.887400455499.issue10119@psf.upfronthosting.co.za>
Message-ID: <1287312858.87.0.456813631008.issue10119@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in revision 85630. When using fileno attribute of the file-descriptor, the socket had to be in blocking mode. 
Now the results are consistent.

This may resolve the other spurious test failures that were observed too.

----------
assignee:  -> orsenthil
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10119>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:55:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 10:55:34 +0000
Subject: [issue1945] Document back ported C functions
In-Reply-To: <1201445858.91.0.21119487494.issue1945@psf.upfronthosting.co.za>
Message-ID: <1287312934.64.0.564464999933.issue1945@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, applied in r85632.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1945>
_______________________________________

From report at bugs.python.org  Sun Oct 17 12:56:47 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Sun, 17 Oct 2010 10:56:47 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1287313007.04.0.396978151609.issue10116@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

ixokai, A change made as part of issue10119 should have resolved this issue too. Please let me know if this can be closed.

----------
assignee:  -> orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Sun Oct 17 13:00:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 11:00:23 +0000
Subject: [issue9204] The documentation of PyType_Type in py3k mentions
	types.TypeType
In-Reply-To: <1278612596.78.0.246474788536.issue9204@psf.upfronthosting.co.za>
Message-ID: <1287313223.03.0.0939811444731.issue9204@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r85633.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9204>
_______________________________________

From report at bugs.python.org  Sun Oct 17 13:03:28 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 11:03:28 +0000
Subject: [issue5121] PyRun_InteractiveLoop disagrees with documentation?
In-Reply-To: <1233457621.0.0.661616898289.issue5121@psf.upfronthosting.co.za>
Message-ID: <1287313408.71.0.399070135657.issue5121@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r85635.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5121>
_______________________________________

From report at bugs.python.org  Sun Oct 17 13:06:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 11:06:24 +0000
Subject: [issue9237] Add sys.call_tracing to on-line sys module documentation
In-Reply-To: <1278973764.17.0.0501374635668.issue9237@psf.upfronthosting.co.za>
Message-ID: <1287313584.09.0.227970297506.issue9237@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Documented in r85636.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9237>
_______________________________________

From report at bugs.python.org  Sun Oct 17 13:32:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 11:32:49 +0000
Subject: [issue10130] Create epub format docs and offer them on the download
	page
Message-ID: <1287315169.0.0.39413411509.issue10130@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl
nosy: georg.brandl
priority: deferred blocker
severity: normal
status: open
title: Create epub format docs and offer them on the download page
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10130>
_______________________________________

From report at bugs.python.org  Sun Oct 17 13:37:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 11:37:25 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1287315445.17.0.69312360416.issue9730@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r85642.

----------
dependencies:  -b64decode should accept strings or bytes
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9730>
_______________________________________

From report at bugs.python.org  Sun Oct 17 14:22:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Oct 2010 12:22:11 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287318131.67.0.815151794729.issue10115@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There would need to be some tests.

Also, this last part of the patch looks strange:

@@ -3001,6 +3072,10 @@
             PyErr_SetString(PyExc_ValueError,
                             "can't use invalid socket value");
             return -1;
+#ifdef HAVE_ACCEPT4
+        /* These flags are not inherited after accept */
+        type &= ~(SOCK_NONBLOCK & SOCK_CLOEXEC);
+#endif /* HAVE_ACCEPT4 */


What is it meant for? And why does it come right after a "return" statement?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Sun Oct 17 15:10:13 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Sun, 17 Oct 2010 13:10:13 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1287321013.41.0.717377264792.issue10116@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

I'll run the test in -F mode for a few hours to see if it comes up or not: but its hard for me to say one way or the other if anything has fixed or not fixed it, as the failure only came up every once in awhile. But I'll look.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Sun Oct 17 15:27:51 2010
From: report at bugs.python.org (JJeffries)
Date: Sun, 17 Oct 2010 13:27:51 +0000
Subject: [issue9909] request for calendar.dayofyear() function
In-Reply-To: <1285039663.27.0.59327234025.issue9909@psf.upfronthosting.co.za>
Message-ID: <1287322071.8.0.846908270945.issue9909@psf.upfronthosting.co.za>


JJeffries <jamesjeffries1 at gmail.com> added the comment:

I agree, I think this would be very useful. I use a function that does this quite often.

Should also be added to calendar.py's __all__.

----------
nosy: +JJeffries

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9909>
_______________________________________

From report at bugs.python.org  Sun Oct 17 15:42:20 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Oct 2010 13:42:20 +0000
Subject: [issue10131] deepcopying an xml.dom.minidom.Document generates an
	invalid XML document
In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za>
Message-ID: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za>


New submission from Florent Xicluna <florent.xicluna at gmail.com>:

>>> import copy
>>> from xml.dom import minidom

>>> doc = minidom.parseString('<root/>')
>>> doc2 = copy.deepcopy(doc)

>>> doc.toxml()
u'<?xml version="1.0" ?><root/>'
>>> doc2.toxml()
u'<?xml version="1.0" ?><root/><root/>'
>>> minidom.parseString(doc2.toxml())
Traceback (most recent call last):
...
ExpatError: junk after document element: line 1, column 2


The workaround is to use doc.cloneNode(True).

----------
components: XML
messages: 118942
nosy: flox
priority: normal
severity: normal
stage: needs patch
status: open
title: deepcopying an xml.dom.minidom.Document generates an invalid XML document
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10131>
_______________________________________

From report at bugs.python.org  Sun Oct 17 15:47:11 2010
From: report at bugs.python.org (Florent Xicluna)
Date: Sun, 17 Oct 2010 13:47:11 +0000
Subject: [issue10131] deepcopying an xml.dom.minidom.Document generates an
	invalid XML document
In-Reply-To: <1287322940.78.0.0838139062813.issue10131@psf.upfronthosting.co.za>
Message-ID: <1287323231.68.0.864357384446.issue10131@psf.upfronthosting.co.za>


Florent Xicluna <florent.xicluna at gmail.com> added the comment:

It works fine with 2.5 and 2.6.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10131>
_______________________________________

From report at bugs.python.org  Sun Oct 17 15:54:46 2010
From: report at bugs.python.org (JJeffries)
Date: Sun, 17 Oct 2010 13:54:46 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287323686.16.0.00767338090388.issue10092@psf.upfronthosting.co.za>


Changes by JJeffries <jamesjeffries1 at gmail.com>:


----------
nosy: +JJeffries

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Sun Oct 17 16:58:05 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Sun, 17 Oct 2010 14:58:05 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1287327485.79.0.14297043168.issue10116@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

Okay, at -r85630 on branches/py3k, I ran:

./python.exe -m test.regrtest -uall -F test_urllibnet

And after 158 retries, got the same error I had before:

test test_urllibnet failed -- Traceback (most recent call last):
  File "/Users/pythonbuildbot/test/build/Lib/urllib/request.py", line 1504, in open
    return getattr(self, name)(url)
  File "/Users/pythonbuildbot/test/build/Lib/urllib/request.py", line 1676, in open_http
    return self._open_generic_http(http.client.HTTPConnection, url, data)
  File "/Users/pythonbuildbot/test/build/Lib/urllib/request.py", line 1659, in _open_generic_http
    response = http_conn.getresponse()
  File "/Users/pythonbuildbot/test/build/Lib/http/client.py", line 1027, in getresponse
    response.begin()
  File "/Users/pythonbuildbot/test/build/Lib/http/client.py", line 347, in begin
    version, status, reason = self._read_status()
  File "/Users/pythonbuildbot/test/build/Lib/http/client.py", line 303, in _read_status
    line = str(self.fp.readline(), "iso-8859-1")
  File "/Users/pythonbuildbot/test/build/Lib/socket.py", line 267, in readinto
    return self._sock.recv_into(b)
socket.error: [Errno 9] Bad file descriptor

----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Sun Oct 17 17:15:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 17 Oct 2010 15:15:57 +0000
Subject: [issue10020] docs for sqlite3 describe functions not available
	without recompiling
In-Reply-To: <1286124753.24.0.309036392806.issue10020@psf.upfronthosting.co.za>
Message-ID: <1287328557.81.0.00101696206727.issue10020@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Has this been fixed in 3.1 and 2.7 too?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10020>
_______________________________________

From report at bugs.python.org  Sun Oct 17 17:49:19 2010
From: report at bugs.python.org (Oliver Deppert)
Date: Sun, 17 Oct 2010 15:49:19 +0000
Subject: [issue1625] bz2.BZ2File doesn't support multiple streams
In-Reply-To: <1197624030.23.0.503522059328.issue1625@psf.upfronthosting.co.za>
Message-ID: <1287330559.13.0.297396956672.issue1625@psf.upfronthosting.co.za>


Oliver Deppert <Oliver.Deppert at stud.tu-darmstadt.de> added the comment:

Thanks for the update....

Like I mentioned before in my previous comment, I'm still searching for a solution/patch for python 2.x able to handle multiple streams of bz2. 

Does anybody know a work-around or have a solution porting the p3k-patch to the good old python 2.x?!

At the moment I try to use this patch with py3k and it seems to work. But I need this multistream option for pythone 2.x because the most of the time I deal with matplotlib....and matplotlib at the moment isn't able to deal with py3k....so, I would be very happy for any suggestion running multiple-streams with python 2.x ! !

Thank you very much, and best regards
Kontr-Olli

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1625>
_______________________________________

From report at bugs.python.org  Sun Oct 17 17:50:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 17 Oct 2010 15:50:30 +0000
Subject: [issue10130] Create epub format docs and offer them on the download
	page
Message-ID: <1287330630.09.0.17937294098.issue10130@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/issue10130>
_______________________________________

From report at bugs.python.org  Sun Oct 17 18:05:00 2010
From: report at bugs.python.org (Thomas Vander Stichele)
Date: Sun, 17 Oct 2010 16:05:00 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1287331500.85.0.0260347816702.issue3631@psf.upfronthosting.co.za>


Thomas Vander Stichele <thomasvs at users.sourceforge.net> added the comment:

It's too bad this is closed out of date because
 a) the macro is still there being distributed
 b) it simply hangs!
 c) there's no easy way to figure out that you should be using something else instead.

I spent a few hours of my life figuring out why it fails and writing an alternative implementation that works for me.

Instead of just closing this ticket, something should be done about the distributions of python so that they don't suggest something that you consider outdated and doesn't actually work.

Here's my working version, for reference:

# THOMAS: the test for between Py_Main and Py_GetArgcArgv is because
# code is in that order in the C file; see Modules/main.c and its comment
# print the entire Python call stack
# same for eval in Python/ceval.c

# in 2.6, PyEval_EvalFrame is only bw compatible, and code now calls
# PyEval_EvalFrameEx
define pystack
    set $__lastpc = $pc
    set $__same = -1
     
    while 1 == 1
	# select the highest frame with the same $pc
	# this will automatically terminate if we reach the top
        while $pc == $__lastpc
            up-silently
        end
        down-silently

        if $pc > PyEval_EvalFrameEx && $pc < PyEval_EvalCodeEx
	    pyframe
        else
            # frame
        end
        up-silently 1
        set $__lastpc = $pc

    end
    select-frame 0
end

----------
nosy: +thomasvs

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Sun Oct 17 18:06:39 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 17 Oct 2010 16:06:39 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287331599.02.0.718025502467.issue10126@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

If I understand correctly, only the changes you made to test_build_ext.py have to be backported.  I can do it if you want, just assign to me, or else do it and I?ll forward port to distutils2.

Note that I don?t fully understand the change, but I trust you that it is indeed the test that was faulty and not the code itself.

----------
assignee:  -> tarek
components: +Distutils2
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Sun Oct 17 18:07:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 17 Oct 2010 16:07:09 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287331629.12.0.479100988764.issue10126@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee: tarek -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Sun Oct 17 18:12:39 2010
From: report at bugs.python.org (Retro)
Date: Sun, 17 Oct 2010 16:12:39 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1287331959.92.0.330749912233.issue2775@psf.upfronthosting.co.za>


Retro <vinetouu at gmail.com> added the comment:

Did you manage to apply my fix "zipfile-patch.diff" to the trunk?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Sun Oct 17 18:52:53 2010
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 17 Oct 2010 16:52:53 +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: <1287334373.03.0.312493786653.issue9807@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

two fixes, the configure.in differentiates the name for the static library, as mentioned in msg118832.

the python-config.in fix prints the library name with the abiflags.

Index: configure.in
===================================================================
--- configure.in	(Revision 85644)
+++ configure.in	(Arbeitskopie)
@@ -585,7 +585,7 @@
 AC_MSG_CHECKING(LIBRARY)
 if test -z "$LIBRARY"
 then
-	LIBRARY='libpython$(VERSION).a'
+	LIBRARY='libpython$(VERSION)$(ABIFLAGS).a'
 fi
 AC_MSG_RESULT($LIBRARY)
 
Index: Misc/python-config.in
===================================================================
--- Misc/python-config.in	(Revision 85644)
+++ Misc/python-config.in	(Arbeitskopie)
@@ -45,7 +45,7 @@
 
     elif opt in ('--libs', '--ldflags'):
         libs = getvar('LIBS').split() + getvar('SYSLIBS').split()
-        libs.append('-lpython'+pyver)
+        libs.append('-lpython'+pyver+sys.abiflags)
         # add the prefix/lib/pythonX.Y/config dir, but only if there is no
         # shared library in prefix/lib/.
         if opt == '--ldflags':

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Sun Oct 17 19:23:58 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Sun, 17 Oct 2010 17:23:58 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287336238.86.0.601477520413.issue10115@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

>What is it meant for? And why does it come right after a "return" statement?
@Antoine, if fd was supplied and it was correct (not returned with -1), let's drop flags that can't be inherited.
It's a mistake, at that level we don't know whether we should inherit flags or not... I'm a bit confused...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Sun Oct 17 19:38:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Oct 2010 17:38:56 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <20101015180336.GA3180@dbwatson.ukfsn.org>
Message-ID: <4CBB34A8.4020600@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 15.10.2010 20:03, schrieb David Watson:
> 
> David Watson <baikie at users.sourceforge.net> added the comment:
> 
>> As a further note: I think socket.gethostname() is a special case, since this is just about a local setting (i.e. not related to DNS).
> 
> But the hostname *is* commonly intended to be looked up in the
> DNS or whatever name resolution mechanisms are used locally -
> socket.getfqdn(), for instance, works by looking up the result
> using gethostbyaddr() (actually the C function getaddrinfo(),
> followed by gethostbyaddr()).  So I don't see the rationale for
> treating it differently from the results of gethostbyaddr(),
> getnameinfo(), etc.

The result from gethostname likely comes out of machine-local
configuration. It may have non-ASCII in it, which is then likely
encoded in the local encoding. When looking it up in DNS, IDNA
should be applied.

OTOH, output from gethostbyaddr likely comes out of the DNS itself.
Guessing what encoding it may have is futile - other than guessing
that it really ought to be ASCII.

> I can see the point of returning the characters that were
> intended, but code that looked up the returned name would then
> have to be changed to re-encode it to bytes to avoid the
> round-tripping issue when non-ASCII characters are returned.

Python's socket module is clearly focused on the internet, and
intends to support that well. So if you pass a non-ASCII
string, it will have to encode that using IDNA. If that's
not what you want to get, tough luck.

----------
title: socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Sun Oct 17 19:40:21 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Oct 2010 17:40:21 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1287169943.3422.7.camel@localhost.localdomain>
Message-ID: <4CBB3500.90108@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The issue Raymond raised is the potential impossibility of making the
> change /after/ we settle on a stable ABI. The question is whether the
> ABI will be enforced starting from 3.2, or from a later date.

I'd like to repeat that it will not be impossible to fix this after the
ABI is in place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sun Oct 17 19:50:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Oct 2010 17:50:46 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <4CBB3500.90108@v.loewis.de>
Message-ID: <1287337837.3447.36.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le dimanche 17 octobre 2010 ? 17:40 +0000, Martin v. L?wis a ?crit :
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> > The issue Raymond raised is the potential impossibility of making the
> > change /after/ we settle on a stable ABI. The question is whether the
> > ABI will be enforced starting from 3.2, or from a later date.
> 
> I'd like to repeat that it will not be impossible to fix this after the
> ABI is in place.

At the cost of very annoying complications, though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sun Oct 17 19:53:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Oct 2010 17:53:02 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287337982.47.0.866130422479.issue9778@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Can't we just do it now, and be done with it regardless of the stable ABI?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sun Oct 17 19:57:26 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Oct 2010 17:57:26 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1287338246.51.0.368207248132.issue2775@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If any action regarding your patch takes place there will be a comment here about it. Until then assume nothing has happened.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Sun Oct 17 19:58:06 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Oct 2010 17:58:06 +0000
Subject: [issue4949] Constness in PyErr_NewException
In-Reply-To: <1231956299.48.0.0179649567226.issue4949@psf.upfronthosting.co.za>
Message-ID: <1287338286.75.0.685961385443.issue4949@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Assuming the patch doesn't cause warnings on the compilers that we use, it looks fine to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4949>
_______________________________________

From report at bugs.python.org  Sun Oct 17 20:01:53 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Oct 2010 18:01:53 +0000
Subject: [issue10130] Create epub format docs and offer them on the download
	page
Message-ID: <1287338513.19.0.538814531695.issue10130@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10130>
_______________________________________

From report at bugs.python.org  Sun Oct 17 20:06:01 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Oct 2010 18:06:01 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1287338761.37.0.811236284385.issue3631@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

fyi - for information on using gdb 7 with python see http://bugs.python.org/issue8032

I'm looking at the .gdbinit improvements regardless as not everyone has gdb 7 (notably OS X).

----------
resolution: out of date -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Sun Oct 17 20:07:15 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Oct 2010 18:07:15 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1287337982.47.0.866130422479.issue9778@psf.upfronthosting.co.za>
Message-ID: <4CBB3B4F.5040303@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Can't we just do it now, and be done with it regardless of the stable ABI?

Sure. Somebody needs to implement it (and consider what consequences
this has on third-party modules - I'm uncertain).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sun Oct 17 20:25:00 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Oct 2010 18:25:00 +0000
Subject: [issue10115] accept4 can fail with errno 90
In-Reply-To: <1287156857.53.0.171830407591.issue10115@psf.upfronthosting.co.za>
Message-ID: <4CBB3F75.4010006@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> That's another possibility, in which case we would first remove the
> current accept4-calling code in order to fix the buildbot failure.

In Python, the lowest layer facing the operating system always directly
exposes the API as-is, without reinterpreting the user's request. Not
following this principle leads exactly to this kind of problem.

So I think .accept() should only call accept(2), and accept4() should
only be called if explicitly requested by the application.

Exposing it as .accept4(flags) is certainly the most straight-forward
way of doing it, but I could also live with .accept(flags) (i.e.
call accept4 if flags are being passed, hoping that no other system
comes up with another accept extension that has a different integer
argument).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Sun Oct 17 20:51:33 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Oct 2010 18:51:33 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1287341493.25.0.952718760129.issue3631@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

everything except the lineno change from gdbinit_python26.patch has been committed in r85646.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Sun Oct 17 20:55:31 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Oct 2010 18:55:31 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1287341731.43.0.564434693857.issue3631@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

and the py_decref in there isn't quite right, fixing...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Sun Oct 17 20:59:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Oct 2010 18:59:04 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1287341944.93.0.0280064249181.issue3631@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think the reference to EasierPythonDebugging is outdated and should be corrected. Dave Malcolm's work is already part of Python, and available with every Python build.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:03:24 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Oct 2010 19:03:24 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1287342204.38.0.807215289879.issue3631@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

do we have official python docs on this that I should point to?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:10:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Oct 2010 19:10:24 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1287342204.38.0.807215289879.issue3631@psf.upfronthosting.co.za>
Message-ID: <4CBB4A1D.5020302@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> do we have official python docs on this that I should point to?

I only know of the doc string of libpython.py itself, in Tools/gdb

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:17:36 2010
From: report at bugs.python.org (Atsushi Odagiri)
Date: Sun, 17 Oct 2010 19:17:36 +0000
Subject: [issue10132] mkpkg.py is lacked.
In-Reply-To: <1287343056.23.0.00370138188039.issue10132@psf.upfronthosting.co.za>
Message-ID: <1287343056.23.0.00370138188039.issue10132@psf.upfronthosting.co.za>


New submission from Atsushi Odagiri <aodagx at gmail.com>:

I try to install distutils2-1.0a3 to python 2.5.
But I got error such a below.

$ python -V
Python 2.5.2
$ python setup.py build
running build
running build_py
running build_scripts
error: file 'distutils2/mkpkg.py' does not exist
$ ls distutils2/mkpkg.pyls: cannot access distutils2/mkpkg.py: No such file or directory

----------
assignee: tarek
components: Distutils2
messages: 118966
nosy: Atsushi.Odagiri, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: mkpkg.py is lacked.
versions: Python 2.5

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10132>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:20:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Oct 2010 19:20:56 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1287343256.1.0.821424912665.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Updated list of failing test with py3k and a non-ascii path:
 * Linux, LANG=C: test_gc test_gdb test_runpy test_zipimport
 * Windows: test_email test_httpservers test_zipimport

Possible reasons:
 * test_httpservers (CGIHTTPServerTestCase.setUp): test should be skipped if sys.executable is not pure ASCII (and it's not possible to create ASCII path using a symlink)
 * test_zipimport: zipimport uses utf-8 (in strict mode) for the prefix, instead of the filesystem encoding
 * test_gc (test_get_count): "The following two tests are fragile: ..." :-/
 * test_gdb: libpython doesn't support surrogates if paths
 * test_email: issue with the end of line (\n vs \r\n?)
 * test_runpy: ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:35:37 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Sun, 17 Oct 2010 19:35:37 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287344137.07.0.41947840388.issue9778@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I'm the maintainer of a third-party library (gmpy) that would be impacted by this and I'm definately in favor of this change. With ever increasing amounts of memory becoming standard in computers, more users will encounter performance issues with large dictionaries. I see 3.2 as the version of Python 3.x that gains wide-spread use. Regardless of the timing of a stable ABI, it's popularity will make it more difficult change the hash size in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:36:59 2010
From: report at bugs.python.org (Michael Olson)
Date: Sun, 17 Oct 2010 19:36:59 +0000
Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py
In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>
Message-ID: <1287344219.85.0.410054920876.issue10128@psf.upfronthosting.co.za>


Michael Olson <olson at irinim.net> added the comment:

I wrapped the offending assertion in a if main_name != '__main__'. I considered not checking the module_name against built-in modules but that seemed likely to be the sort of thing being guarded against, so I left it at an exception for __main__.

Ran a few trivial testing using Pool and Process and it seems to work fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10128>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:44:44 2010
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 17 Oct 2010 19:44:44 +0000
Subject: [issue3631] Improve gdbinit of Python 2.6
In-Reply-To: <1219321743.09.0.122028214381.issue3631@psf.upfronthosting.co.za>
Message-ID: <1287344684.24.0.74953099738.issue3631@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I updated the note in gdbinit to point to Tools/gdb/libpython.py for py3k (3.2) and 2.7.

Thomas: I didn't do anything with your version of pystack because the existing versions in 3.2 and 2.7 appear to work fine for me.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3631>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:49:58 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Oct 2010 19:49:58 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1287344998.21.0.754841629493.issue8845@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is now fixed in r85660. The field associated with a T_BOOL must be of type char, so I changed the type of inTransaction.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:51:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Oct 2010 19:51:55 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1287344137.07.0.41947840388.issue9778@psf.upfronthosting.co.za>
Message-ID: <4CBB53D8.4060307@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'm the maintainer of a third-party library (gmpy) that would be
> impacted by this and I'm definitely in favor of this change.

Assume Python would make such a change, and users would build released
gmpy versions for such a Python release. What would happen (in terms
of observable errors)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:54:25 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Sun, 17 Oct 2010 19:54:25 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287345265.27.0.958642819907.issue10073@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Let me fix this function a little bit...

def isleap(year):
    """Return True for leap years, False for non-leap years."""
    if year == 0:
        raise ValueError('year 0 does not exist')
    return (year % 4 == 0) and (year % 100 != 0) or (year % 400 == 0)

This function, however, does not mind if you give it a negative number. But I think we can leave this option to mean B.C. (Before Christ), so calendar.isleap(-240) would mean 240 B.C., which was a leap year.

About the  if year == 0  check... Well, read Wikipedia's article  http://en.wikipedia.org/wiki/0_(year)  which clearly states that "Year zero does not exist in the widely used Gregorian calendar or in its predecessor, the Julian calendar."  So we raise a ValueError if this value is used in the calendar.isleap() function.

I have uploaded a patch that fixes this function. Please apply it to the trunk and also to the maintenance brances.

----------
keywords: +patch
Added file: http://bugs.python.org/file19255/calendar-isleap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:58:01 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 17 Oct 2010 19:58:01 +0000
Subject: [issue10132] mkpkg.py is lacked.
In-Reply-To: <1287343056.23.0.00370138188039.issue10132@psf.upfronthosting.co.za>
Message-ID: <1287345481.05.0.650475885313.issue10132@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The file was renamed to mkcfg.py, but we forgot to rename it in the scripts options in setup.py for py < 2.6. This was fixed since then.

Until the alpha4 release is out you can make the same change in setup.py for your build to work.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10132>
_______________________________________

From report at bugs.python.org  Sun Oct 17 21:58:06 2010
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 17 Oct 2010 19:58:06 +0000
Subject: [issue10132] mkpkg.py is lacked.
In-Reply-To: <1287343056.23.0.00370138188039.issue10132@psf.upfronthosting.co.za>
Message-ID: <1287345486.9.0.649487646995.issue10132@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

The file was renamed to mkcfg.py, but we forgot to rename it in the scripts options in setup.py for py < 2.6. This was fixed since then.

Until the alpha4 release is out you can make the same change in setup.py for your build to work.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10132>
_______________________________________

From report at bugs.python.org  Sun Oct 17 22:03:13 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Oct 2010 20:03:13 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1287345793.09.0.980593458637.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r85655 fixed test_gdb failure.

test_runpy failure looks to be linked to test_zipimport problems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Sun Oct 17 22:11:44 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Oct 2010 20:11:44 +0000
Subject: [issue9772] test_pep277 failure on AMD64 debian parallel buildbot
In-Reply-To: <1283601685.6.0.819525034936.issue9772@psf.upfronthosting.co.za>
Message-ID: <1287346304.03.0.757259605963.issue9772@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That appears to be a bug in the NFS server. When you creat("Gr\303\274-Gott"), what actually comes out of getdents(3) is Gr\303\274-Gott. This only happens with four bytes of non-ASCII - two UTF-8 bytes are correctly reported. We are investigating this locally.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9772>
_______________________________________

From report at bugs.python.org  Sun Oct 17 22:14:55 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Sun, 17 Oct 2010 20:14:55 +0000
Subject: [issue10133] conn_recv_string() broken error handling
In-Reply-To: <1287346495.15.0.809946654619.issue10133@psf.upfronthosting.co.za>
Message-ID: <1287346495.15.0.809946654619.issue10133@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

Neither conn_recv_string() nor its callers free *newbuffer on error.

The promotion rules break negative 'res' for 64-bit Py_ssize_t
in the (ulength <= buflength) branch:
res = -1 ==> (UINT32)-1 ==> Py_ssize_t 0xffffffff instead of -1.

While I'm writing: The _conn_recvall() calls can be factored out
of the if().

This patch applies to both 3.2a3 and 2.7.  However, the patched failure
cases are untested: I do not know how to test them. It passes make test.

----------
components: IO
files: conn_recv_string_failures.diff
keywords: patch
messages: 118978
nosy: hfuru
priority: normal
severity: normal
status: open
title: conn_recv_string() broken error handling
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19256/conn_recv_string_failures.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10133>
_______________________________________

From report at bugs.python.org  Sun Oct 17 22:19:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Oct 2010 20:19:14 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1287346754.94.0.734402005631.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

r85659 + r85662 + r85663 fixed test_httpservers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Sun Oct 17 22:25:38 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 17 Oct 2010 20:25:38 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287347138.7.0.947104882601.issue9778@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Here's a patch. Please review.

----------
keywords: +patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file19257/hash_t.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sun Oct 17 22:26:37 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 17 Oct 2010 20:26:37 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287347197.08.0.297209183143.issue9778@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


Added file: http://bugs.python.org/file19258/hash_t.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sun Oct 17 22:33:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Oct 2010 20:33:26 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287347606.55.0.993797798597.issue9778@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sun Oct 17 23:08:37 2010
From: report at bugs.python.org (Daniel Stutzbach)
Date: Sun, 17 Oct 2010 21:08:37 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1287349717.34.0.923775526877.issue9730@psf.upfronthosting.co.za>


Daniel Stutzbach <daniel at stutzbachenterprises.com> added the comment:

That fixes the example code, but what about the numerous text that reads  "strings" that should read "byte sequences", "bytes", or similar?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9730>
_______________________________________

From report at bugs.python.org  Sun Oct 17 22:37:10 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 17 Oct 2010 20:37:10 +0000
Subject: [issue4352] imp.find_module() fails with a UnicodeDecodeError when
	called with non-ASCII search paths
In-Reply-To: <1227071866.1.0.995372704707.issue4352@psf.upfronthosting.co.za>
Message-ID: <1287347830.64.0.240847587114.issue4352@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Good news: this issue is now fixed in py3k (Python 3.2). I cannot give a commit number, because there are too much commits related to this problem (see #8611 and #9425), but it works ;-)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4352>
_______________________________________

From report at bugs.python.org  Sun Oct 17 23:19:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Oct 2010 21:19:18 +0000
Subject: [issue8845] Expose sqlite3 connection inTransaction as read-only
	in_transaction attribute
In-Reply-To: <1275069249.63.0.318211846232.issue8845@psf.upfronthosting.co.za>
Message-ID: <1287350358.63.0.59351512779.issue8845@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Thank you, Martin.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8845>
_______________________________________

From report at bugs.python.org  Sun Oct 17 23:14:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Oct 2010 21:14:04 +0000
Subject: [issue10132] mkpkg.py is missing
In-Reply-To: <1287343056.23.0.00370138188039.issue10132@psf.upfronthosting.co.za>
Message-ID: <1287350044.72.0.416177614506.issue10132@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: mkpkg.py is lacked. -> mkpkg.py is missing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10132>
_______________________________________

From report at bugs.python.org  Sun Oct 17 22:42:03 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 17 Oct 2010 20:42:03 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287348123.96.0.873515039422.issue9778@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

A few comments:
- in complex_hash, why did you drop the cast?
- in object.rst, add versionchanged. It should also explain that Py_hash_t is a signed integer with the same width as size_t.

Otherwise, it looks fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sun Oct 17 22:55:18 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 17 Oct 2010 20:55:18 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287348918.88.0.628223990781.issue9778@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Dropping the cast was inadvertent. I've now added versionchanged and committed it in r85664.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 00:02:42 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 17 Oct 2010 22:02:42 +0000
Subject: [issue10133] multiprocessing: conn_recv_string() broken error handling
In-Reply-To: <1287346495.15.0.809946654619.issue10133@psf.upfronthosting.co.za>
Message-ID: <1287352962.83.0.218230387033.issue10133@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> jnoller
nosy: +jnoller
title: conn_recv_string() broken error handling -> multiprocessing: conn_recv_string() broken error handling

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10133>
_______________________________________

From report at bugs.python.org  Mon Oct 18 00:16:00 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Sun, 17 Oct 2010 22:16:00 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287353760.87.0.838147875956.issue10126@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hi Eric, yes, that's basically what I did.  See _fix_command(), which *should* be the only thing that needs to be backported.  I do believe it's a faulty test and hopefully the comment explains why it's necessary.

Thanks for giving the backport a shot!

----------
assignee:  -> eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Mon Oct 18 00:23:50 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 17 Oct 2010 22:23:50 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287354230.49.0.764773123723.issue9778@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I added a placeholder to the What's New document.  Since it will affect extension module authors it should be mentioned at a higher level than just Misc/NEWS.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 00:48:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Oct 2010 22:48:56 +0000
Subject: [issue1343] XMLGenerator: nice <empty/> elements
In-Reply-To: <1193492035.12.0.0580891111126.issue1343@psf.upfronthosting.co.za>
Message-ID: <1287355736.29.0.779108652315.issue1343@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed Neil's patch (after adding docs) in r85671.  Thanks.

----------
nosy: +r.david.murray
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1343>
_______________________________________

From report at bugs.python.org  Mon Oct 18 01:09:54 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Sun, 17 Oct 2010 23:09:54 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1287356994.48.0.181852291137.issue10079@psf.upfronthosting.co.za>


Bruce Sherwood <bruce.sherwood at gmail.com> added the comment:

I found a couple of mistakes in the patch I submitted (places where "vidle" should have been "idlelib", and which aren't addressed in Ned Deily's patch), so I've rebuilt the patch starting from the tag r32a3, which I assume is the version from which Ned started.

----------
Added file: http://bugs.python.org/file19259/idlelib20101012_from_r32a3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Mon Oct 18 01:13:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Oct 2010 23:13:43 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1287357223.83.0.160690543445.issue9730@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I reviewed the doc and tightened up the wording (which was already mostly correct) in r85672.  Also fixed one typo and changed it to consistently use 'byte string' (rather than 'bytestring' which was used in one or two places).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9730>
_______________________________________

From report at bugs.python.org  Mon Oct 18 01:45:47 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 17 Oct 2010 23:45:47 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1287359147.61.0.737499609144.issue8611@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Victor, can you paste or attach the error for email?  My MSDN subscription has expired so I can't set up to test it myself (I've submitted the renewal, but who knows how long it will take to process :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Mon Oct 18 02:20:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Oct 2010 00:20:59 +0000
Subject: [issue4499] redefinition of TILDE macro on AIX platform
In-Reply-To: <1228258808.76.0.068417078821.issue4499@psf.upfronthosting.co.za>
Message-ID: <1287361259.13.0.560244765453.issue4499@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in r85675, 3.1 in r85676, and 2.7 in r85677.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4499>
_______________________________________

From report at bugs.python.org  Mon Oct 18 03:15:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Oct 2010 01:15:35 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1287364535.33.0.968380921842.issue678250@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in r85678.  If I'm reading this string correctly, I believe this can (and should be) be backported.  Am I correct?

----------
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Mon Oct 18 04:43:27 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Mon, 18 Oct 2010 02:43:27 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287369807.57.0.453380548612.issue9778@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

The patch does not address that "unsigned long" is still used to calculate the hash values. This breaks numeric hashing and leads to incorrect values.

Python 3.2a3+ (py3k, Oct 17 2010, 19:03:38) [MSC v.1500 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.hash_info
sys.hash_info(width=64, modulus=-1, inf=314159, nan=0, imag=1000003)
>>>

Would "size_t" be the appropriate type to use?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 05:22:40 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Oct 2010 03:22:40 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287372160.41.0.379350551995.issue9778@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Good point. Here's another patch:

----------
Added file: http://bugs.python.org/file19260/deunsignify.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 05:49:04 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Oct 2010 03:49:04 +0000
Subject: [issue10134] test_email failures on Windows: end of line issue?
In-Reply-To: <1287373744.55.0.18095949035.issue10134@psf.upfronthosting.co.za>
Message-ID: <1287373744.55.0.18095949035.issue10134@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

See attached file for the full output. One example:

== CPython 3.2a3+ (py3k:85660, Oct 17 2010, 21:57:48) [MSC v.1500 32 bit (Intel)]
==   Windows-XP-5.1.2600-SP3 little-endian
======================================================================
FAIL: test_MIME_digest (email.test.test_email.TestBytesGeneratorIdempotent)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\victor\py3k\lib\email\test\test_email.py", line 2016, in test_MIME_digest
    self._idempotent(msg, text)
  File "C:\victor\py3k\lib\email\test\test_email.py", line 2947, in _idempotent
    self.assertEqual(data, b.getvalue())
  File "C:\victor\py3k\lib\email\test\test_email.py", line 2952, in assertEqual
    self.assertListEqual(str1.split(b'\n'), str2.split(b'\n'))
AssertionError: Lists differ: [b'MIME-version: 1.0\r', b'Fro... != [b'MIME-version: 1.0', b'From:...

First differing element 0:
b'MIME-version: 1.0\r'
b'MIME-version: 1.0'

- [b'MIME-version: 1.0\r',
?                     --

+ [b'MIME-version: 1.0',
-  b'From: ppp-request at zzz.org\r',
?                             --

+  b'From: ppp-request at zzz.org',
-  b'Sender: ppp-admin at zzz.org\r',
?                             --

+  b'Sender: ppp-admin at zzz.org',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'Subject: Ppp digest, Vol 1 #2 - 5 msgs\r',
?                                          --

+  b'Subject: Ppp digest, Vol 1 #2 - 5 msgs',
-  b'Date: Fri, 20 Apr 2001 20:18:00 -0400 (EDT)\r',
?                                               --

+  b'Date: Fri, 20 Apr 2001 20:18:00 -0400 (EDT)',
-  b'X-Mailer: Mailman v2.0.4\r',
?                            --

+  b'X-Mailer: Mailman v2.0.4',
-  b'X-Mailman-Version: 2.0.4\r',
?                            --

+  b'X-Mailman-Version: 2.0.4',
-  b'Content-Type: multipart/mixed; boundary="192.168.1.2.889.32614.987812255.500.21814"\r',
?                                                                                       --

+  b'Content-Type: multipart/mixed; boundary="192.168.1.2.889.32614.987812255.500.21814"',
-  b'\r',
?    --

+  b'',
-  b'--192.168.1.2.889.32614.987812255.500.21814\r',
?                                               --

+  b'--192.168.1.2.889.32614.987812255.500.21814',
-  b'Content-type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-type: text/plain; charset=us-ascii',
-  b'Content-description: Masthead (Ppp digest, Vol 1 #2)\r',
?                                                        --

+  b'Content-description: Masthead (Ppp digest, Vol 1 #2)',
-  b'\r',
?    --

+  b'',
   b'Send Ppp mailing list submissions to\r',
   b'\tppp at zzz.org\r',
   b'\r',
   b'To subscribe or unsubscribe via the World Wide Web, visit\r',
   b'\thttp://www.zzz.org/mailman/listinfo/ppp\r',
   b"or, via email, send a message with subject or body 'help' to\r",
   b'\tppp-request at zzz.org\r',
   b'\r',
   b'You can reach the person managing the list at\r',
   b'\tppp-admin at zzz.org\r',
   b'\r',
   b'When replying, please edit your Subject line so it is more specific\r',
   b'than "Re: Contents of Ppp digest..."\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--192.168.1.2.889.32614.987812255.500.21814\r',
?                                               --

+  b'--192.168.1.2.889.32614.987812255.500.21814',
-  b'Content-type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-type: text/plain; charset=us-ascii',
-  b"Content-description: Today's Topics (5 msgs)\r",
?                                                --

+  b"Content-description: Today's Topics (5 msgs)",
-  b'\r',
?    --

+  b'',
   b"Today's Topics:\r",
   b'\r',
   b'   1. testing #1 (Barry A. Warsaw)\r',
   b'   2. testing #2 (Barry A. Warsaw)\r',
   b'   3. testing #3 (Barry A. Warsaw)\r',
   b'   4. testing #4 (Barry A. Warsaw)\r',
   b'   5. testing #5 (Barry A. Warsaw)\r',
-  b'\r',
?    --

+  b'',
-  b'--192.168.1.2.889.32614.987812255.500.21814\r',
?                                               --

+  b'--192.168.1.2.889.32614.987812255.500.21814',
-  b'Content-Type: multipart/digest; boundary="__--__--"\r',
?                                                       --

+  b'Content-Type: multipart/digest; boundary="__--__--"',
-  b'\r',
?    --

+  b'',
-  b'--__--__--\r',
?              --

+  b'--__--__--',
-  b'\r',
?    --

+  b'',
-  b'Message: 1\r',
?              --

+  b'Message: 1',
-  b'Content-Type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-Type: text/plain; charset=us-ascii',
-  b'Content-Transfer-Encoding: 7bit\r',
?                                   --

+  b'Content-Transfer-Encoding: 7bit',
-  b'Date: Fri, 20 Apr 2001 20:16:13 -0400\r',
?                                         --

+  b'Date: Fri, 20 Apr 2001 20:16:13 -0400',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'From: barry at digicool.com (Barry A. Warsaw)\r',
?                                              --

+  b'From: barry at digicool.com (Barry A. Warsaw)',
-  b'Subject: [Ppp] testing #1\r',
?                             --

+  b'Subject: [Ppp] testing #1',
-  b'Precedence: bulk\r',
?                    --

+  b'Precedence: bulk',
-  b'\r',
?    --

+  b'',
   b'\r',
   b'hello\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--__--__--\r',
?              --

+  b'--__--__--',
-  b'\r',
?    --

+  b'',
-  b'Message: 2\r',
?              --

+  b'Message: 2',
-  b'Date: Fri, 20 Apr 2001 20:16:21 -0400\r',
?                                         --

+  b'Date: Fri, 20 Apr 2001 20:16:21 -0400',
-  b'Content-Type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-Type: text/plain; charset=us-ascii',
-  b'Content-Transfer-Encoding: 7bit\r',
?                                   --

+  b'Content-Transfer-Encoding: 7bit',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'From: barry at digicool.com (Barry A. Warsaw)\r',
?                                              --

+  b'From: barry at digicool.com (Barry A. Warsaw)',
-  b'Precedence: bulk\r',
?                    --

+  b'Precedence: bulk',
-  b'\r',
?    --

+  b'',
   b'\r',
   b'hello\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--__--__--\r',
?              --

+  b'--__--__--',
-  b'\r',
?    --

+  b'',
-  b'Message: 3\r',
?              --

+  b'Message: 3',
-  b'Date: Fri, 20 Apr 2001 20:16:25 -0400\r',
?                                         --

+  b'Date: Fri, 20 Apr 2001 20:16:25 -0400',
-  b'Content-Type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-Type: text/plain; charset=us-ascii',
-  b'Content-Transfer-Encoding: 7bit\r',
?                                   --

+  b'Content-Transfer-Encoding: 7bit',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'From: barry at digicool.com (Barry A. Warsaw)\r',
?                                              --

+  b'From: barry at digicool.com (Barry A. Warsaw)',
-  b'Subject: [Ppp] testing #3\r',
?                             --

+  b'Subject: [Ppp] testing #3',
-  b'Precedence: bulk\r',
?                    --

+  b'Precedence: bulk',
-  b'\r',
?    --

+  b'',
   b'\r',
   b'hello\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--__--__--\r',
?              --

+  b'--__--__--',
-  b'\r',
?    --

+  b'',
-  b'Message: 4\r',
?              --

+  b'Message: 4',
-  b'Date: Fri, 20 Apr 2001 20:16:28 -0400\r',
?                                         --

+  b'Date: Fri, 20 Apr 2001 20:16:28 -0400',
-  b'Content-Type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-Type: text/plain; charset=us-ascii',
-  b'Content-Transfer-Encoding: 7bit\r',
?                                   --

+  b'Content-Transfer-Encoding: 7bit',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'From: barry at digicool.com (Barry A. Warsaw)\r',
?                                              --

+  b'From: barry at digicool.com (Barry A. Warsaw)',
-  b'Subject: [Ppp] testing #4\r',
?                             --

+  b'Subject: [Ppp] testing #4',
-  b'Precedence: bulk\r',
?                    --

+  b'Precedence: bulk',
-  b'\r',
?    --

+  b'',
   b'\r',
   b'hello\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--__--__--\r',
?              --

+  b'--__--__--',
-  b'\r',
?    --

+  b'',
-  b'Message: 5\r',
?              --

+  b'Message: 5',
-  b'Date: Fri, 20 Apr 2001 20:16:32 -0400\r',
?                                         --

+  b'Date: Fri, 20 Apr 2001 20:16:32 -0400',
-  b'Content-Type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-Type: text/plain; charset=us-ascii',
-  b'Content-Transfer-Encoding: 7bit\r',
?                                   --

+  b'Content-Transfer-Encoding: 7bit',
-  b'To: ppp at zzz.org\r',
?                   --

+  b'To: ppp at zzz.org',
-  b'From: barry at digicool.com (Barry A. Warsaw)\r',
?                                              --

+  b'From: barry at digicool.com (Barry A. Warsaw)',
-  b'Subject: [Ppp] testing #5\r',
?                             --

+  b'Subject: [Ppp] testing #5',
-  b'Precedence: bulk\r',
?                    --

+  b'Precedence: bulk',
-  b'\r',
?    --

+  b'',
   b'\r',
   b'hello\r',
   b'\r',
   b'\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--__--__----\r',
?                --

+  b'--__--__----',
-  b'--192.168.1.2.889.32614.987812255.500.21814\r',
?                                               --

+  b'--192.168.1.2.889.32614.987812255.500.21814',
-  b'Content-type: text/plain; charset=us-ascii\r',
?                                              --

+  b'Content-type: text/plain; charset=us-ascii',
-  b'Content-description: Digest Footer\r',
?                                      --

+  b'Content-description: Digest Footer',
-  b'\r',
?    --

+  b'',
   b'_______________________________________________\r',
   b'Ppp mailing list\r',
   b'Ppp at zzz.org\r',
   b'http://www.zzz.org/mailman/listinfo/ppp\r',
   b'\r',
-  b'\r',
?    --

+  b'',
-  b'--192.168.1.2.889.32614.987812255.500.21814--\r',
?                                                 --

+  b'--192.168.1.2.889.32614.987812255.500.21814--',
   b'\r',
   b'End of Ppp Digest\r',
   b'\r',
   b'']

----------
components: Library (Lib)
files: out.txt
messages: 118996
nosy: haypo, r.david.murray
priority: normal
severity: normal
status: open
title: test_email failures on Windows: end of line issue?
versions: Python 3.2
Added file: http://bugs.python.org/file19261/out.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10134>
_______________________________________

From report at bugs.python.org  Mon Oct 18 05:49:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Oct 2010 03:49:58 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1287373798.96.0.284547906568.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Victor, can you paste or attach the error for email?

It doesn't look to be related to the path name (same failure with "py3k?" or "py3k" directory name), so I opened #10134.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Mon Oct 18 11:24:12 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 18 Oct 2010 09:24:12 +0000
Subject: [issue9862] PIPE_BUF is invalid on AIX
In-Reply-To: <1284568234.82.0.42184878799.issue9862@psf.upfronthosting.co.za>
Message-ID: <1287393852.0.0.920687644031.issue9862@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

Thanks R. David.

I checked in 3.1 and PIPE_BUF is not defined in the select module, so the default value of 512 is used in subprocess.
So no correction is needed for that version.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9862>
_______________________________________

From report at bugs.python.org  Mon Oct 18 11:52:46 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Oct 2010 09:52:46 +0000
Subject: [issue10048] urllib.request documentation confusing
In-Reply-To: <1286535990.46.0.129844190964.issue10048@psf.upfronthosting.co.za>
Message-ID: <1287395566.92.0.115923881872.issue10048@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee: docs at python -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10048>
_______________________________________

From report at bugs.python.org  Mon Oct 18 12:08:56 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Oct 2010 10:08:56 +0000
Subject: [issue1531775] HTTPSConnection request hangs
Message-ID: <1287396536.81.0.341988313433.issue1531775@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Not an issue anymore as socket timeout at client is supposed to happen with the connection is hung due to unresponsive host.
The original bug was raised py2.3. Closing it as out of date.

----------
nosy: +orsenthil
resolution:  -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1531775>
_______________________________________

From report at bugs.python.org  Mon Oct 18 12:11:22 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Oct 2010 10:11:22 +0000
Subject: [issue1520831] urrlib2 max_redirections=0 disables redirects
Message-ID: <1287396682.38.0.633624733595.issue1520831@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1520831>
_______________________________________

From report at bugs.python.org  Mon Oct 18 12:18:45 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 18 Oct 2010 10:18:45 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287397125.95.0.481151818282.issue9778@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Wouldn't it be better to use Py_hash_t instead of size_t for calculating the hash values in those hash functions ?

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 12:21:02 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 18 Oct 2010 10:21:02 +0000
Subject: [issue9778] Make hash values the same width as	a pointer	(or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287397262.74.0.60815440391.issue9778@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

And related to my previous comment: shouldn't Py_hash_t map to size_t instead of Py_ssize_t ?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 12:25:33 2010
From: report at bugs.python.org (=?utf-8?b?U8OpYmFzdGllbiBTYWJsw6k=?=)
Date: Mon, 18 Oct 2010 10:25:33 +0000
Subject: [issue678250] test_mmap failling on AIX
Message-ID: <1287397533.05.0.256887057229.issue678250@psf.upfronthosting.co.za>


S?bastien Sabl? <sable at users.sourceforge.net> added the comment:

I also believe this patch should be backported.

If the issue2643 is not backported, then the patch to apply should be "patch_flush_mmap.diff" instead of "patch_mmap_flush_updated.diff"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Mon Oct 18 12:26:03 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 18 Oct 2010 10:26:03 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Have your default locale set to 'Slovenian' which uses a comma for the decimal symbol, like 2.76 is written as 2,76. Observe that the format specifier 'n' does not work for the default 'Slovenian' locale setting.

Then try running this in the Python interpreter:
'{number:.3n}'.format(number=2.76)

You get this:
>>> '{number:.3n}'.format(number=2.76)
'2.76'

Excepted the is the return value '2,76'. Please fix this bug.

----------
components: Interpreter Core
messages: 119003
nosy: Retro
priority: normal
severity: normal
status: open
title: Format specifier 'n' not working
type: behavior
versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Mon Oct 18 12:36:21 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Oct 2010 10:36:21 +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: <1287398181.41.0.762940315766.issue4733@psf.upfronthosting.co.za>


Changes by Senthil Kumaran <orsenthil at gmail.com>:


----------
assignee:  -> orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4733>
_______________________________________

From report at bugs.python.org  Mon Oct 18 12:45:20 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Oct 2010 10:45:20 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283554637.01.0.167836774867.issue9730@psf.upfronthosting.co.za>
Message-ID: <20101018104510.GC10299@remy>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

On Fri, Sep 03, 2010 at 10:57:17PM +0000, Georg Brandl wrote:
> That's why I said to use "testsetup" directives -- they are not
> visible in the HTML/PDF/... output, but used when running the tests.

Do you already have such a directive in sphinx? I think, it would be a
good idea to have doctests succeed. And having examples in the docs
working 'directly out of text'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9730>
_______________________________________

From report at bugs.python.org  Mon Oct 18 12:47:27 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 18 Oct 2010 10:47:27 +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: <1287398847.3.0.213620389223.issue9807@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

Index: Misc/python.pc.in
===================================================================
--- Misc/python.pc.in	(Revision 85644)
+++ Misc/python.pc.in	(Arbeitskopie)
@@ -8,6 +8,6 @@
 Requires: 
 Version: @VERSION@
 Libs.private: @LIBS@
-Libs: -L${libdir} -lpython at VERSION@
+Libs: -L${libdir} -lpython at VERSION@@ABIFLAGS@
 Cflags: -I${includedir}/python at VERSION@

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Mon Oct 18 12:48:31 2010
From: report at bugs.python.org (Matthias Klose)
Date: Mon, 18 Oct 2010 10:48:31 +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: <1287398911.77.0.163965001142.issue9807@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

the name of the library should not differ for the static and the shared library.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Mon Oct 18 13:29:55 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 Oct 2010 11:29:55 +0000
Subject: [issue10136] kill_python doesn't work with short path
In-Reply-To: <1287401395.69.0.888132012732.issue10136@psf.upfronthosting.co.za>
Message-ID: <1287401395.69.0.888132012732.issue10136@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

When kill_python[,d].exe was called via short path,
no python processes won't be killed. This happens
because, directory path is compared via simple
wcsnicmp. If one is short path and another is long path,
wcsnicmp determines they are not same path. This patch
solves this issue with GetFileInformationByHandle's
File ID information.

Probably this won't happen so much, so priority is low.

----------
components: Build
files: py3k_fix_kill_python_for_short_path.patch
keywords: patch
messages: 119007
nosy: ocean-city
priority: normal
severity: normal
status: open
title: kill_python doesn't work with short path
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19262/py3k_fix_kill_python_for_short_path.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10136>
_______________________________________

From report at bugs.python.org  Mon Oct 18 13:38:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Oct 2010 11:38:25 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287401905.71.0.123911223905.issue10135@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eric.smith, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Mon Oct 18 13:40:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Oct 2010 11:40:37 +0000
Subject: [issue10127] ssl.SSLSocket().close() does not close the connection
In-Reply-To: <1287263674.2.0.992398068639.issue10127@psf.upfronthosting.co.za>
Message-ID: <1287402037.8.0.248982448018.issue10127@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10127>
_______________________________________

From report at bugs.python.org  Mon Oct 18 13:41:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Oct 2010 11:41:18 +0000
Subject: [issue5736] Add the iterator protocol to dbm modules
In-Reply-To: <1239457673.6.0.50765651359.issue5736@psf.upfronthosting.co.za>
Message-ID: <1287402078.14.0.432012181306.issue5736@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5736>
_______________________________________

From report at bugs.python.org  Mon Oct 18 13:44:16 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 18 Oct 2010 11:44:16 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287402256.63.0.568377111357.issue10135@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

How are you setting the Slovenian locale?

Could please let me know what this prints:

import locale
locale.localeconv()

Also, could you let me know what:
locale.format('%.3f', 2.45)

prints? Both of these would be when the Slovenian locale is selected.

Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Mon Oct 18 13:47:15 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Oct 2010 11:47:15 +0000
Subject: [issue9730] base64 docs refers to strings instead of bytes
In-Reply-To: <1283312665.97.0.832544712662.issue9730@psf.upfronthosting.co.za>
Message-ID: <1287402435.76.0.0358978973498.issue9730@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, Georg mentioned the directive because it exists :)

See the turtle docs for some examples, I think.  I seem to remember using it when I made those doctests pass on 2.7 (warning: it writes weird stuff on your screen :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9730>
_______________________________________

From report at bugs.python.org  Mon Oct 18 14:00:26 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 18 Oct 2010 12:00:26 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287403226.72.0.750130764136.issue10135@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Oops, I meant "locale.format('%.3f', 2.76)", although of course the number shouldn't matter.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Mon Oct 18 14:19:55 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 18 Oct 2010 12:19:55 +0000
Subject: [issue678250] test_mmap failing on AIX
Message-ID: <1287404395.97.0.642921589287.issue678250@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
title: test_mmap failling on AIX -> test_mmap failing on AIX

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue678250>
_______________________________________

From report at bugs.python.org  Mon Oct 18 14:45:42 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Oct 2010 12:45:42 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1287397262.74.0.60815440391.issue9778@psf.upfronthosting.co.za>
Message-ID: <AANLkTik+GHNiEUc4SmnuZmzQtdZSh8K3X1C3s=pM0-Pm@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/10/18 Marc-Andre Lemburg <report at bugs.python.org>:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> And related to my previous comment: shouldn't Py_hash_t map to size_t instead of Py_ssize_t ?

No, negative values have to be allowed.

----------
title: Make hash values the same width as	a pointer	(or Py_ssize_t) -> Make hash values the same width as a pointer (or Py_ssize_t)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 15:09:53 2010
From: report at bugs.python.org (jan matejek)
Date: Mon, 18 Oct 2010 13:09:53 +0000
Subject: [issue9539] python-2.6.4: test failure in test_distutils due to
	linking to system libpython2.6
In-Reply-To: <1281222795.64.0.211558756173.issue9539@psf.upfronthosting.co.za>
Message-ID: <1287407393.9.0.686757058826.issue9539@psf.upfronthosting.co.za>


jan matejek <jmatejek at suse.cz> added the comment:

i was able to reproduce this in clean 2.7
Sandro, this is only reproducible on systems without python - so by definition, you can hit this only during installation

as for issue8335, yes, i think that it's a duplicate

distutils2 is irrelevant here, because you can only install it on top of existing python. The problem here is that stdlib's distutils must use the newly built libpython, *not* the systemwide one - a problem that distutils2 don't need to solve until they become part of stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9539>
_______________________________________

From report at bugs.python.org  Mon Oct 18 15:28:07 2010
From: report at bugs.python.org (Floris Bruynooghe)
Date: Mon, 18 Oct 2010 13:28:07 +0000
Subject: [issue3526] Customized malloc implementation on SunOS and AIX
In-Reply-To: <1218190381.02.0.174331191244.issue3526@psf.upfronthosting.co.za>
Message-ID: <1287408487.86.0.0874969452737.issue3526@psf.upfronthosting.co.za>


Changes by Floris Bruynooghe <floris.bruynooghe at gmail.com>:


----------
nosy: +flub

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3526>
_______________________________________

From report at bugs.python.org  Mon Oct 18 15:29:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 13:29:06 +0000
Subject: [issue9539] python-2.6.4: test failure in test_distutils due to
	linking to system libpython2.6
In-Reply-To: <1281222795.64.0.211558756173.issue9539@psf.upfronthosting.co.za>
Message-ID: <1287408546.89.0.360927074661.issue9539@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> i was able to reproduce this in clean 2.7
> as for issue8335, yes, i think that it's a duplicate

Ok, then please add your failure messages on the other bug.

> Sandro, this is only reproducible on systems without python
>- so by definition, you can hit this only during installation

Hm, Sandro didn?t say whether he had a system Python or not.

> distutils2 is irrelevant here

This is internal bookkeeping, you can ignore it.  When we fix something in distutils, it?s forward-ported to distutils2.  I don?t want to wait until the end to synchronize bug fixes.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> distutils test_build_ext's test_get_outputs fails in bootstrap environment

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9539>
_______________________________________

From report at bugs.python.org  Mon Oct 18 15:32:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 13:32:18 +0000
Subject: [issue8335] distutils test_build_ext's test_get_outputs fails in
	bootstrap environment
In-Reply-To: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>
Message-ID: <1287408738.61.0.389524601198.issue8335@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

This may be solved by backporting the fix in #10126.  I?ll do it when my network gives me access to svn again :/

----------
components: +Distutils2
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/issue8335>
_______________________________________

From report at bugs.python.org  Mon Oct 18 15:39:05 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Mon, 18 Oct 2010 13:39:05 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287409145.8.0.808802653028.issue9778@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

Some quick comments on the latest patch.

1) I don't think you can remove the type cast used when comparing the hash value against -1 and -2. IIRC, GCC considers that undefined behavior.

2) In sysmodule.c, we need to use PyLong_FromSsize_t when storing _PyHASH_MODULUS.

3) In pyport.h, we need a better way to define _PyHASH_MODULUS. The existing "((1UL << _PyHASH_BITS) - 1)" fails when unsigned long is smaller than Py_ssize_t. "((1ULL << _PyHASH_BITS) - 1)" works on 64-bit Windows but is not a good solution for systems that don't have an unsigned long long type. I haven't thought of a better solution for one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 15:44:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 13:44:01 +0000
Subject: [issue8335] distutils test_build_ext's test_get_outputs fails in
	bootstrap environment
In-Reply-To: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>
Message-ID: <1287409441.01.0.471323411427.issue8335@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +sandro.tosi, valeo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8335>
_______________________________________

From report at bugs.python.org  Mon Oct 18 15:49:42 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Mon, 18 Oct 2010 13:49:42 +0000
Subject: [issue9539] python-2.6.4: test failure in test_distutils due to
	linking to system libpython2.6
In-Reply-To: <1287408546.89.0.360927074661.issue9539@psf.upfronthosting.co.za>
Message-ID: <AANLkTinLrWJQYK5OqrXv-mZRfA3BihWF=-KSDBWxsCsj@mail.gmail.com>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

On Mon, Oct 18, 2010 at 15:29, ?ric Araujo <report at bugs.python.org> wrote:
> ?ric Araujo <merwok at netwok.org> added the comment:
>> Sandro, this is only reproducible on systems without python
>>- so by definition, you can hit this only during installation
>
> Hm, Sandro didn?t say whether he had a system Python or not.

yes I have :) I can try on an isolated chroot to replicate the
problem, but it will probably take me some day to have the time to do
that,

Cheers,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9539>
_______________________________________

From report at bugs.python.org  Mon Oct 18 15:56:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 13:56:03 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <AANLkTik+GHNiEUc4SmnuZmzQtdZSh8K3X1C3s=pM0-Pm@mail.gmail.com>
Message-ID: <AANLkTi=ZRg9N=uRuUS0wTpZUzFSC8h5J=jLBdK+bjpAf@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Oct 18, 2010 at 8:45 AM, Benjamin Peterson
<report at bugs.python.org> wrote:
..
> No, negative values have to be allowed.
>

Why?  As far as I can tell, negative values are only used as sentinels
and we can use say (size_t)-1 instead of -1L.  Are there cases where
hash values' ordering is important?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 15:57:57 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 Oct 2010 13:57:57 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1287410277.48.0.140220482334.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Committed fixes in r85689(py3k), r85693(release31-maint),
r85694(release27-maint). (This should work because I 
simply ported already working fix in ntpath.relpath)

----------
resolution:  -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Mon Oct 18 15:59:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Oct 2010 13:59:46 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <AANLkTi=ZRg9N=uRuUS0wTpZUzFSC8h5J=jLBdK+bjpAf@mail.gmail.com>
Message-ID: <1287410381.3492.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

Le lundi 18 octobre 2010 ? 13:56 +0000, Alexander Belopolsky a ?crit :
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Mon, Oct 18, 2010 at 8:45 AM, Benjamin Peterson
> <report at bugs.python.org> wrote:
> ..
> > No, negative values have to be allowed.
> >
> 
> Why?  As far as I can tell, negative values are only used as sentinels
> and we can use say (size_t)-1 instead of -1L.

You can, except that changing the sentinel value will probably break a
lot of code out there (and there's no benefit AFAICT).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 16:09:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 14:09:12 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1287410381.3492.2.camel@localhost.localdomain>
Message-ID: <AANLkTim1BmVeY9fFCVmMFnaq1Okc4eyCjt5n86Rf9UoC@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Oct 18, 2010 at 9:59 AM, Antoine Pitrou <report at bugs.python.org> wrote:
..
>> Why? ?As far as I can tell, negative values are only used as sentinels
>> and we can use say (size_t)-1 instead of -1L.
>
> You can, except that changing the sentinel value will probably break a
> lot of code out there (and there's no benefit AFAICT).

AFAICT, a change from (Py_ssize_t)-1 to (size_t)-1 is less likely to
break code than a change from -1L to  (Py_ssize_t)-1.  (Assuming a
sizeof(long) != sizeof(void*) platform.)  The benefit, though is that
hash computations can be performed natively on the hash values without
casting to an unrelated type.  If Py_hash_t needs to be signed, I
would like to see a typedef Py_uhash_t size_t next to that for
Py_hash_t and  Py_uhash_t used in hash computations rather than
explicit size_t.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 16:11:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 14:11:55 +0000
Subject: [issue1646068] Dict lookups fail if sizeof(Py_ssize_t) < sizeof(long)
Message-ID: <1287411115.6.0.781459389782.issue1646068@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Issue #9778 makes this out of date.

----------
assignee: tim_one -> belopolsky
nosy:  -BreamoreBoy
resolution:  -> out of date
status: open -> pending
superseder:  -> Make hash values the same width as a pointer (or Py_ssize_t)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1646068>
_______________________________________

From report at bugs.python.org  Mon Oct 18 16:40:37 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 18 Oct 2010 14:40:37 +0000
Subject: [issue9539] python-2.6.4: test failure in test_distutils due to
	linking to system libpython2.6
In-Reply-To: <1281222795.64.0.211558756173.issue9539@psf.upfronthosting.co.za>
Message-ID: <1287412837.51.0.831553908845.issue9539@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Even though this one's older, I'm going to mark it as a duplicate of issue 10126, which is tracking the backport of the fix I made in Python 3.2 to 3.1 and 2.7.

The key issues here are that Python was built with --enabled-shared and the test *only* fails when running 'make test'.  Running ./python as Sandro did does not trigger the bug - at least it didn't in 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9539>
_______________________________________

From report at bugs.python.org  Mon Oct 18 16:41:49 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 18 Oct 2010 14:41:49 +0000
Subject: [issue9539] python-2.6.4: test failure in test_distutils due to
	linking to system libpython2.6
In-Reply-To: <1281222795.64.0.211558756173.issue9539@psf.upfronthosting.co.za>
Message-ID: <1287412909.94.0.42113596439.issue9539@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Seems like roundup hates me.  Just go to issue 10126.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9539>
_______________________________________

From report at bugs.python.org  Mon Oct 18 16:41:51 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Mon, 18 Oct 2010 14:41:51 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1287412911.75.0.586827223965.issue5117@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

FYI, this fix broke some buildbots: http://www.python.org/dev/buildbot/all/builders/x86%20Snow%20Leopard%202.7/builds/50 for instance. Gentoo too.

----------
nosy: +ixokai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Mon Oct 18 16:46:14 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 14:46:14 +0000
Subject: [issue9539] python-2.6.4: test failure in test_distutils due to
	linking to system libpython2.6
In-Reply-To: <1281222795.64.0.211558756173.issue9539@psf.upfronthosting.co.za>
Message-ID: <1287413174.43.0.936798825537.issue9539@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
superseder: distutils test_build_ext's test_get_outputs fails in bootstrap environment -> test_distutils failure with --enable-shared

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9539>
_______________________________________

From report at bugs.python.org  Mon Oct 18 16:47:36 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 18 Oct 2010 14:47:36 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <AANLkTik+GHNiEUc4SmnuZmzQtdZSh8K3X1C3s=pM0-Pm@mail.gmail.com>
Message-ID: <4CBC5E05.8030608@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Benjamin Peterson wrote:
> 
> Benjamin Peterson <benjamin at python.org> added the comment:
>> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>>
>> And related to my previous comment: shouldn't Py_hash_t map to size_t instead of Py_ssize_t ?
> 
> No, negative values have to be allowed.

Ah, right... we use -1 as error indicator.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 16:48:12 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 14:48:12 +0000
Subject: [issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1287413292.17.0.398798879522.issue10117@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in r85695.  Leaving open to discuss whether anything can/should be done for the case when reindent acts as an stdin to stdout filter.  Also, what is the policy on backporting Tools' bug fixes?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10117>
_______________________________________

From report at bugs.python.org  Mon Oct 18 17:17:17 2010
From: report at bugs.python.org (Sebastian Ramacher)
Date: Mon, 18 Oct 2010 15:17:17 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
Message-ID: <1287415037.39.0.0645391423939.issue1699259@psf.upfronthosting.co.za>


Sebastian Ramacher <sebastinas at users.sourceforge.net> added the comment:

Any news on that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699259>
_______________________________________

From report at bugs.python.org  Mon Oct 18 17:17:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 15:17:25 +0000
Subject: [issue8335] distutils test_build_ext's test_get_outputs fails in
	bootstrap environment
In-Reply-To: <1270662842.61.0.49246293202.issue8335@psf.upfronthosting.co.za>
Message-ID: <1287415045.62.0.798290941116.issue8335@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Marking as duplicate, following Barry in msg119022

----------
nosy: +barry
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> test_distutils failure with --enable-shared

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8335>
_______________________________________

From report at bugs.python.org  Mon Oct 18 17:19:21 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Mon, 18 Oct 2010 15:19:21 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287415161.37.0.445409166737.issue9778@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

Also, note that hash(-12) is -12.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 17:27:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Oct 2010 15:27:28 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <AANLkTim1BmVeY9fFCVmMFnaq1Okc4eyCjt5n86Rf9UoC@mail.gmail.com>
Message-ID: <1287415644.3492.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> AFAICT, a change from (Py_ssize_t)-1 to (size_t)-1 is less likely to
> break code than a change from -1L to  (Py_ssize_t)-1.  (Assuming a
> sizeof(long) != sizeof(void*) platform.)

That's true.

> The benefit, though is that
> hash computations can be performed natively on the hash values without
> casting to an unrelated type.

I don't understand what you mean by "native" and "unrelated". Signed
integers are not less native than unsigned ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 17:34:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 15:34:15 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
In-Reply-To: <1287415037.39.0.0645391423939.issue1699259@psf.upfronthosting.co.za>
Message-ID: <AANLkTimob7QJxrHJbyEdXnZK2SncWiO--4Tr_bu-H=gG@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Oct 18, 2010 at 11:17 AM, Sebastian Ramacher
<report at bugs.python.org> wrote:
..
> Any news on that?

Is this patch still relevant for 3.2?  It looks like const has been
added when char* was changed to wchar_t* in the affected functions.
See r62178.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699259>
_______________________________________

From report at bugs.python.org  Mon Oct 18 17:44:43 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 15:44:43 +0000
Subject: [issue1699259] replacing char* with const char* in sysmodule.c/.h
Message-ID: <1287416683.87.0.623631900052.issue1699259@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

In fact, it looks like const has been added in py3k as early as r57439.

I am resetting "versions" to 2.7, but I am -0 on backporting.  I am also unselecting "type" because with "feature request" type this should be closed while some may argue that this is a bug.

----------
nosy:  -BreamoreBoy
type: feature request -> 
versions: +Python 2.7 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1699259>
_______________________________________

From report at bugs.python.org  Mon Oct 18 17:54:05 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Mon, 18 Oct 2010 15:54:05 +0000
Subject: [issue10137] Patch to IDLE for Python 2.7, at Guido's request
In-Reply-To: <1287417245.71.0.949450394447.issue10137@psf.upfronthosting.co.za>
Message-ID: <1287417245.71.0.949450394447.issue10137@psf.upfronthosting.co.za>


New submission from Bruce Sherwood <bruce.sherwood at gmail.com>:

At Guido's request, I've carried out the same update to the IDLE
distributed with Python 2.7 that I submitted for Python 3, to incorporate the work of Guilherme Polo in the Google Summer of Code 2009. Guido was concerned that with significant problems reported for IDLE 2.7, there should be an update despite Python 2.7 itself being essentially frozen. The basic structure for IDLE 3.2 was carried over. The main changes that had to be made were the change in module names between Python 2.7 and Python 3.2 (e.g. Tkinter in 2.7 is tkinter in 3.2).

----------
components: IDLE
files: idlelib2.7.patch
keywords: patch
messages: 119033
nosy: Bruce.Sherwood
priority: normal
severity: normal
status: open
title: Patch to IDLE for Python 2.7, at Guido's request
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19263/idlelib2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10137>
_______________________________________

From report at bugs.python.org  Mon Oct 18 17:55:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 15:55:17 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287417317.93.0.787026136345.issue10135@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions:  -3rd party, Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Mon Oct 18 18:09:19 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 16:09:19 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1287415644.3492.5.camel@localhost.localdomain>
Message-ID: <AANLkTik8nTEVWaR_o+V8i9JjWzWXKhDWgVUysF9H8qDi@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Oct 18, 2010 at 11:27 AM, Antoine Pitrou <report at bugs.python.org> wrote:
..
>> The benefit, though is that
>> hash computations can be performed natively on the hash values without
>> casting to an unrelated type.
>
> I don't understand what you mean by "native" and "unrelated". Signed
> integers are not less native than unsigned ones.

Sorry, I could have been clearer indeed.   Consider the following code:

static Py_hash_t
long_hash(PyLongObject *v)
{
    unsigned long x;
...
    x = x * sign;
    if (x == (unsigned long)-1)
        x = (unsigned long)-2;
    return (Py_hash_t)x;
}

Wouldn't it be cleaner if x was the same type as hash?  Note that
unsigned long is now wrong.  What is needed is "unsigned integer type
of the same size as Py_hash_t."  If Py_hash_t has to stay signed, I
think we should at least not rely of sizeof(Py_hash_t) to always
remain the same as sizeof(size_t).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 18:14:53 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 16:14:53 +0000
Subject: [issue10118] Tkinter does not find font
In-Reply-To: <1287192630.89.0.924571330725.issue10118@psf.upfronthosting.co.za>
Message-ID: <1287418493.35.0.114790640208.issue10118@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10118>
_______________________________________

From report at bugs.python.org  Mon Oct 18 18:22:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 16:22:48 +0000
Subject: [issue10087] HTML calendar is broken
In-Reply-To: <1286984608.4.0.168516535909.issue10087@psf.upfronthosting.co.za>
Message-ID: <1287418968.12.0.0402040569755.issue10087@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/issue10087>
_______________________________________

From report at bugs.python.org  Mon Oct 18 18:35:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 16:35:10 +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: <1287419710.75.0.512324456993.issue2571@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You could say my question was half-academic.  I read your closing message and thought ?this feature request has been closed because of the version, not really rejected?, so I asked about reopening.  On a second level, it appears from your detailed message (thanks for writing it) that the situation is still unclear, so I do think that a review of docs and tests is needed, and maybe an API cleanup.  I?m assigning this to myself as an opportunity to learn the insides of cmd in some months.

----------
assignee:  -> eric.araujo
resolution: out of date -> remind
stage: unit test needed -> 
type: feature request -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2571>
_______________________________________

From report at bugs.python.org  Mon Oct 18 18:38:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 16:38:54 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1287345265.27.0.958642819907.issue10073@psf.upfronthosting.co.za>
Message-ID: <AANLkTimU80_Bg-CJ5JqObKgLvOUM=qb+bH4kE1RrVkUn@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Oct 17, 2010 at 3:54 PM, Bo?tjan Mejak <report at bugs.python.org> wrote:
..
> About the ?if year == 0 ?check... Well, read Wikipedia's article ?http://en.wikipedia.org/wiki/0_(year) ?which clearly
> states that "Year zero does not exist in the widely used Gregorian calendar or in its predecessor, the Julian
> calendar." ?So we raise a ValueError if this value is used in the calendar.isleap() function.
>

Well, Wikipedia is not the most authoritative source, but if you go
the right article there, you will find that

"""
Mathematically, it is more convenient to include a year zero and
represent earlier years as negative, for the specific purpose of
facilitating the calculation of the number of years between a negative
(BC) year and a positive (AD) year. This is the convention used in
astronomical year numbering and in the international standard date
system, ISO 8601. In these systems, the year 0 is a leap year.[2]
"""

Python documentation states that calendar module implements 'the
?proleptic Gregorian? calendar in Dershowitz and Reingold?s book
?Calendrical Calculations?'.  See
http://docs.python.org/dev/py3k/library/calendar.html

I don't have Dershowitz and Reingold?s book to check, but ISO/FDIS
8601:2000(E) standard contains a note that states: "In the prolaptic
[sic] Gregorian calendar the calendar year [0000] is a leap year."

In any case, I think there are more important issues with the calendar
module than perceived bugs in isleap() function.  See for example
issue 10087.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Mon Oct 18 18:39:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 16:39:47 +0000
Subject: [issue10086] test_sysconfig failure with site-packages
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1287419987.47.0.402880999558.issue10086@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the fix, good catch!  Do you want to write a patch to test_sysconfig to add a test?  Otherwise I?ll do it.

----------
components: +Distutils2, Library (Lib)
versions: +3rd party, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Mon Oct 18 18:43:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 16:43:03 +0000
Subject: [issue10086] test_sysconfig failure with site-packages
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1287420183.61.0.819965767056.issue10086@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I wrote too fast, I thought your diff was for sysconfig itself, not test_sysconfig.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Mon Oct 18 18:58:49 2010
From: report at bugs.python.org (STINNER Victor)
Date: Mon, 18 Oct 2010 16:58:49 +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: <1287421129.83.0.743055259245.issue5111@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/issue5111>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:03:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 17:03:44 +0000
Subject: =?utf-8?q?=5Bissue10039=5D_python_=C3=A9=2Epy_fails_with_UnicodeEncodeErr?=
	=?utf-8?q?or_if_PYTHONFSENCODING_is_used?=
In-Reply-To: <1286414733.34.0.0267403088134.issue10039@psf.upfronthosting.co.za>
Message-ID: <1287421424.28.0.928415450224.issue10039@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Do you know something better than the locale encoding? I don't.
Neither do I, sorry.

>> Can?t each filesystem have its own encoding?
> Yes, but how do you get the encoding of each filesystem?
If I really had to, on linux I could parse the output of the mount command, but this could get messy quickly, and of course is not okay for official Python.

> Backup programs can use the "raw" (bytes) API of Python 3 to avoid
> all encoding issues.
Neat!

> As wrote R. David Murray, read issue #9992 if you would like to know
> more about this problem and the different proposed solutions.
I did so, thanks for the pointer and all the explanations.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10039>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:03:54 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 18 Oct 2010 17:03:54 +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: <1287421434.16.0.0123832567845.issue5111@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/issue5111>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:12:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 17:12:51 +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: <1287421971.76.0.112616833113.issue5111@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/issue5111>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:15:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 17:15:16 +0000
Subject: [issue10086] test_sysconfig failure with site-packages
In-Reply-To: <1286980763.58.0.308351769071.issue10086@psf.upfronthosting.co.za>
Message-ID: <1287422116.51.0.705691169894.issue10086@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Attaching a patch with your two suggestions.

Two things worry me and prevent me from committing right now:
1) sysconfig was originally distutils.sysconfig, and some duplication remains.  Can?t this bug happen with distutils.sysconfig too?  Should we duplicate tests from test_sysconfig to distutils.test_sysconfig?

2) How to prevent a regression?  That is, how to run tests with custom ./configure options?

----------
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19264/fix10086.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10086>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:23:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 17:23:40 +0000
Subject: [issue10138] calendar module does not support years outside [1,
	9999] range
In-Reply-To: <1287422620.12.0.790695371078.issue10138@psf.upfronthosting.co.za>
Message-ID: <1287422620.12.0.790695371078.issue10138@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Documentation for the calendar module says:

"""
Most of these functions and classes rely on the datetime module which uses an idealized calendar, the current Gregorian calendar indefinitely extended in both directions.
"""

However, neither the datetime nor as a consequence the calendar module support years  outside [1, 9999] range.

----------
assignee: belopolsky
components: Documentation
messages: 119041
nosy: belopolsky
priority: normal
severity: normal
status: open
title: calendar module does not support years outside [1, 9999] range
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10138>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:23:54 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 18 Oct 2010 17:23:54 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287403226.72.0.750130764136.issue10135@psf.upfronthosting.co.za>
Message-ID: <AANLkTinPP-JnzY32Bxy2jVG9Ne=mQgYeo_RUVB4G+KCC@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

{'mon_decimal_point': '', 'int_frac_digits': 127, 'p_sep_by_space': 127,
'frac_digits': 127, 'thousands_sep': '', 'n_sign_posn': 127,
'decimal_point': '.', 'int_curr_symbol': '', 'n_cs_precedes': 127,
'p_sign_posn': 127, 'mon_thousands_sep': '', 'negative_sign': '',
'currency_symbol': '', 'n_sep_by_space': 127, 'mon_grouping': [],
'p_cs_precedes': 127, 'positive_sign': '', 'grouping': []}

'2.760'

And the output of locale.format() in this case should be
'2,760'

On Mon, Oct 18, 2010 at 2:00 PM, Eric Smith <report at bugs.python.org> wrote:

>
> Eric Smith <eric at trueblade.com> added the comment:
>
> Oops, I meant "locale.format('%.3f', 2.76)", although of course the number
> shouldn't matter.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10135>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19265/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________
-------------- next part --------------
<div>&gt;&gt;&gt; import locale<br>&gt;&gt;&gt; locale.localeconv()</div>
<div><div>{&#39;mon_decimal_point&#39;: &#39;&#39;, &#39;int_frac_digits&#39;: 127, &#39;p_sep_by_space&#39;: 127, &#39;frac_digits&#39;: 127, &#39;thousands_sep&#39;: &#39;&#39;, &#39;n_sign_posn&#39;: 127, &#39;decimal_point&#39;: &#39;.&#39;, &#39;int_curr_symbol&#39;: &#39;&#39;, &#39;n_cs_precedes&#39;: 127, &#39;p_sign_posn&#39;: 127, &#39;mon_thousands_sep&#39;: &#39;&#39;, &#39;negative_sign&#39;: &#39;&#39;, &#39;currency_symbol&#39;: &#39;&#39;, &#39;n_sep_by_space&#39;: 127, &#39;mon_grouping&#39;: [], &#39;p_cs_precedes&#39;: 127, &#39;positive_sign&#39;: &#39;&#39;, &#39;grouping&#39;: []}</div>
</div>

<div>??</div>
<div>It prints this:</div>
<div>&gt;&gt;&gt; import locale<br>&gt;&gt;&gt; locale.format(&#39;%.3f&#39;, 2.76)<br>&#39;2.760&#39;</div>
<div>??</div>
<div>And the output of locale.format() in this case should be</div>
<div>&#39;2,760&#39;<br><br></div>
<div class="gmail_quote">On Mon, Oct 18, 2010 at 2:00 PM, Eric Smith <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org" target="_blank">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote style="border-left:#ccc 1px solid;margin:0px 0px 0px 0.8ex;padding-left:1ex" class="gmail_quote">
<div><br>Eric Smith &lt;<a href="mailto:eric at trueblade.com" target="_blank">eric at trueblade.com</a>&gt; added the comment:<br><br></div>Oops, I meant &quot;locale.format(&#39;%.3f&#39;, 2.76)&quot;, although of course the number shouldn&#39;t matter.<br>

<br>----------<br>
<div>
<div></div>
<div><br>_______________________________________<br>Python tracker &lt;<a href="mailto:report at bugs.python.org" target="_blank">report at bugs.python.org</a>&gt;<br>&lt;<a href="http://bugs.python.org/issue10135" target="_blank">http://bugs.python.org/issue10135</a>&gt;<br>

_______________________________________<br></div></div></blockquote></div><br>

From report at bugs.python.org  Mon Oct 18 19:25:30 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Mon, 18 Oct 2010 17:25:30 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287422730.95.0.665646066397.issue9778@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

>Sorry, I could have been clearer indeed.   Consider the following code:
>
>static Py_hash_t
>long_hash(PyLongObject *v)
>{
>    unsigned long x;
>...
>    x = x * sign;
>    if (x == (unsigned long)-1)
>        x = (unsigned long)-2;
>    return (Py_hash_t)x;
>}

>Wouldn't it be cleaner if x was the same type as hash?  Note that
>unsigned long is now wrong.  What is needed is "unsigned integer type
>of the same size as Py_hash_t."  If Py_hash_t has to stay signed, I
>think we should at least not rely of sizeof(Py_hash_t) to always
>remain the same as sizeof(size_t).

The calculation of long_hash assumes an unsigned temporary type to get correct results for the bit shifting and masking. The calculation is done on the absolute value of the long and then the sign is applied. We either needed to (1) add an unsigned Py_hash_t type or (2) just use size_t and Py_ssize_t.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:29:14 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Oct 2010 17:29:14 +0000
Subject: [issue10137] Patch to IDLE for Python 2.7, at Guido's request
In-Reply-To: <1287417245.71.0.949450394447.issue10137@psf.upfronthosting.co.za>
Message-ID: <1287422954.71.0.306390920642.issue10137@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +kbk, taleinat

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10137>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:29:35 2010
From: report at bugs.python.org (Brian Curtin)
Date: Mon, 18 Oct 2010 17:29:35 +0000
Subject: [issue10137] Patch to IDLE for Python 2.7, at Guido's request
In-Reply-To: <1287417245.71.0.949450394447.issue10137@psf.upfronthosting.co.za>
Message-ID: <1287422975.76.0.788085211799.issue10137@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10137>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:31:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 17:31:51 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1287422730.95.0.665646066397.issue9778@psf.upfronthosting.co.za>
Message-ID: <AANLkTikkyE93+SDcTFyGUuwZy5GwafSYGdVELcsO0qRZ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Oct 18, 2010 at 1:25 PM, Case Van Horsen <report at bugs.python.org> wrote:
..
> We either needed to (1) add an unsigned Py_hash_t type or (2) just use size_t and Py_ssize_t.
>

Option (2) may actually be preferable because dict and set
implementations rely on Py_hash_t being compatible with Py_ssize_t.
See issue 1646068.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:32:09 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 18 Oct 2010 17:32:09 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287423129.51.0.814484223528.issue10135@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

It looks like the float.__format__ code is correctly using the value of decimal_point = '.'. It also agrees with locale.format().

How are you setting the locale? The problem appears to be either how you are setting the locale or the contents of the locale, not in the formatting code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:37:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Oct 2010 17:37:40 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1287423460.87.0.711546909675.issue9437@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:44:43 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Oct 2010 17:44:43 +0000
Subject: [issue10137] Patch to IDLE for Python 2.7, at Guido's request
In-Reply-To: <1287417245.71.0.949450394447.issue10137@psf.upfronthosting.co.za>
Message-ID: <1287423883.85.0.614480872844.issue10137@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

But this patch is a diff between a 2.7 and a 3.2 version of IDLE, isn't it?  The tkinter->Tkinter renaming is not supposed to happen in the 2.7 branch.
Could you instead show a diff between the present version of IDLE in 2.7 and the result of your work, so we can better see the impact of the change?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10137>
_______________________________________

From report at bugs.python.org  Mon Oct 18 19:56:45 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 18 Oct 2010 17:56:45 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287423129.51.0.814484223528.issue10135@psf.upfronthosting.co.za>
Message-ID: <AANLkTim2JbLJ27FdagfH5M96VsosadYp-pebZS8Y99HO@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

So do I need additional things to set in my code if I use the 'n' format
specifier in order for it to be locale-aware? So using just the 'n' format
specifier is not enough? Please explain in depth.

On Mon, Oct 18, 2010 at 7:32 PM, Eric Smith <report at bugs.python.org> wrote:

>
> Eric Smith <eric at trueblade.com> added the comment:
>
> It looks like the float.__format__ code is correctly using the value of
> decimal_point = '.'. It also agrees with locale.format().
>
> How are you setting the locale? The problem appears to be either how you
> are setting the locale or the contents of the locale, not in the formatting
> code.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10135>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19266/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________
-------------- next part --------------
So do I need additional things to set in my code if I use the &#39;n&#39; format specifier in order for it to be locale-aware? So using just the &#39;n&#39; format specifier is not enough? Please explain in depth.<br><br><div class="gmail_quote">
On Mon, Oct 18, 2010 at 7:32 PM, Eric Smith <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
Eric Smith &lt;<a href="mailto:eric at trueblade.com">eric at trueblade.com</a>&gt; added the comment:<br>
<br>
</div>It looks like the float.__format__ code is correctly using the value of decimal_point = &#39;.&#39;. It also agrees with locale.format().<br>
<br>
How are you setting the locale? The problem appears to be either how you are setting the locale or the contents of the locale, not in the formatting code.<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/issue10135" target="_blank">http://bugs.python.org/issue10135</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Mon Oct 18 19:59:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 17:59:27 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287424767.34.0.282370740611.issue10073@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The most pedantic implementation of calendar.isleap() would be

from datetime import date, timedelta
def isleap(year):
    return date(year, 3, 1) - date(year, 2, 1) == timedelta(29)

Since python calendar only supports years in the range [1, 9999], the above will properly raise ValueError: year is out of range on negative or zero year.  This also guarantees that calendar module's notion of leap year is the same as that of datetime module.

If this is found to be a worthwhile change, I would also rewrite monthrange as

def monthrange(year, month):
    first = date(year, month, 1)
    if month == 12:
        ndays = 31
    else:
        ndays = (date(year, month + 1, 1) - first).days
    return first.weekday(), ndays

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:08:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 18:08:44 +0000
Subject: [issue10051] distutils fail to install unicode-encoded files with
	POSIX locale
In-Reply-To: <1286538579.43.0.363477643478.issue10051@psf.upfronthosting.co.za>
Message-ID: <1287425324.37.0.874053808809.issue10051@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  This is a duplicate, you can add yourself to the nosy list on the superseder bug to track status.

----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> distutils: set encoding to utf-8 for input and output files

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10051>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:09:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Oct 2010 18:09:23 +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: <1287425363.48.0.807071751189.issue10134@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The interesting question is, why aren't the buildbots seeing this failure?  I can reproduce it in my Windows VM using 3.2a3, and will work on a fix (to the tests, the code under test is doing the "correct" thing, though that thing is somewhat broken by design).

----------
components: +Tests
priority: normal -> high
stage:  -> needs patch
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10134>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:09:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Oct 2010 18:09:35 +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: <1287425375.58.0.198574731326.issue10134@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/issue10134>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:10:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 18 Oct 2010 18:10:34 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287425434.12.0.178608132272.issue10073@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/issue10073>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:11:47 2010
From: report at bugs.python.org (David Watson)
Date: Mon, 18 Oct 2010 18:11:47 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <4CBB34A8.4020600@v.loewis.de>
Message-ID: <20101018181136.GA3631@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

> The result from gethostname likely comes out of machine-local
> configuration. It may have non-ASCII in it, which is then likely
> encoded in the local encoding. When looking it up in DNS, IDNA
> should be applied.

I would have thought that someone who intended a Unicode hostname
to be looked up in its IDNA form would have encoded it using
IDNA, rather than an 8-bit encoding - how many C programs would
transcode the name that way, rather than just passing the char *
from one interface to another?

In fact, I would think that non-ASCII bytes in a hostname most
probably indicated that a name resolution mechanism other than
the DNS was in use, and that the byte string should be passed
unaltered just as a typical C program would.

> OTOH, output from gethostbyaddr likely comes out of the DNS itself.
> Guessing what encoding it may have is futile - other than guessing
> that it really ought to be ASCII.

Sure, but that doesn't mean the result can't be made to
round-trip if it turns out not to be ASCII.  The guess that it
will be ASCII is, after all, still a guess (as is the guess that
it comes from the DNS).

> Python's socket module is clearly focused on the internet, and
> intends to support that well. So if you pass a non-ASCII
> string, it will have to encode that using IDNA. If that's
> not what you want to get, tough luck.

I don't object to that, but it does force a choice between
decoding an 8-bit name for display (e.g. by using the locale
encoding), and decoding it to round-trip automatically (e.g. by
using ASCII/surrogateescape, with support on the encoding side).

Using PyUnicode_DecodeFSDefault() for the hostname or other
returned names (thus decoding them for display) would make this
issue solvable with programmer intervention - for instance,
"socket.gethostbyaddr(socket.gethostname())" could be replaced by
"socket.gethostbyaddr(os.fsencode(socket.gethostname()))", but
programmers might well neglect to do this, given that no encoding
was needed in Python 2.

Also, even displaying a non-ASCII name decoded according to the
locale creates potential for confusion, as when the user types
the same characters into a Python program for lookup (again,
barring programmer intervention), they will not represent the
same byte sequence as the characters the user sees on the screen
(as they will instead represent their IDNA ASCII-compatible
equivalent).

So overall, I do think it is better to decode names for automatic
round-tripping rather than for display, but my main concern is
simply that it should be possible to recover the original bytes
so that round-tripping is at least possible.
PyUnicode_DecodeFSDefault() would accomplish that much at least.

----------
title: socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:12:48 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 18 Oct 2010 18:12:48 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <AANLkTin0_p77XDSvgv34bxoX7rxAwLyZWA9iw0ty9-my@mail.gmail.com>
Message-ID: <AANLkTik_X4zx+qmOjhzorSky=seTXaYFkj+Zb7Ou=R4r@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Also, your "pedantic" version of isleap() is not pedantic at all.

return date(year, 3, 1) - date(year, 2, 1) == timedelta(29)
does not seem readable at all. Readability counts!

return date(year, 3, 1) is not understandable. What are the arguments 3 and
1 in the date() function for?

On Mon, Oct 18, 2010 at 8:06 PM, Bo??tjan Mejak <bostjan.mejak at gmail.com>wrote:

>     else:
> -->    ndays = (date(year, month + 1, 1) - first).days
>     return first.weekday(), ndays
>
> Oh my God! The line with a pointer is so ugly!
>
> On Mon, Oct 18, 2010 at 7:59 PM, Alexander Belopolsky <
> report at bugs.python.org> wrote:
>
>>
>> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the
>> comment:
>>
>> The most pedantic implementation of calendar.isleap() would be
>>
>> from datetime import date, timedelta
>> def isleap(year):
>>    return date(year, 3, 1) - date(year, 2, 1) == timedelta(29)
>>
>> Since python calendar only supports years in the range [1, 9999], the
>> above will properly raise ValueError: year is out of range on negative or
>> zero year.  This also guarantees that calendar module's notion of leap year
>> is the same as that of datetime module.
>>
>> If this is found to be a worthwhile change, I would also rewrite
>> monthrange as
>>
>> def monthrange(year, month):
>>    first = date(year, month, 1)
>>    if month == 12:
>>        ndays = 31
>>    else:
>>        ndays = (date(year, month + 1, 1) - first).days
>>    return first.weekday(), ndays
>>
>> ----------
>>
>> _______________________________________
>> Python tracker <report at bugs.python.org>
>> <http://bugs.python.org/issue10073>
>> _______________________________________
>>
>
>

----------
Added file: http://bugs.python.org/file19267/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________
-------------- next part --------------
Also, your &quot;pedantic&quot; version of isleap() is not pedantic at all.<div><br></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">return date(year, 3, 1) - date(year, 2, 1) == timedelta(29)</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">does not seem readable at all. Readability counts!</span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><span class="Apple-style-span" style="font-size: 13px; ">return date(year, 3, 1) is not understandable. What are the arguments 3 and 1 in the date() function for?</span><br>
</span></font><br></div><div><br><div class="gmail_quote">On Mon, Oct 18, 2010 at 8:06 PM, Bo??tjan Mejak <span dir="ltr">&lt;<a href="mailto:bostjan.mejak at gmail.com">bostjan.mejak at gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">???? ??else:<br>--&gt; ?? ??ndays = (date(year, month + 1, 1) - first).days<br>???? ??return first.weekday(), ndays</span><div>
<font face="arial, sans-serif"><span style="border-collapse:collapse"><br></span></font></div></div><div><font face="arial, sans-serif"><span style="border-collapse:collapse">Oh my God! The line with a pointer is so ugly!<br>

</span></font><div><div></div><div class="h5"><br><div class="gmail_quote">On Mon, Oct 18, 2010 at 7:59 PM, Alexander Belopolsky <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org" target="_blank">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
Alexander Belopolsky &lt;<a href="mailto:belopolsky at users.sourceforge.net" target="_blank">belopolsky at users.sourceforge.net</a>&gt; added the comment:<br>
<br>
</div>The most pedantic implementation of calendar.isleap() would be<br>
<br>
from datetime import date, timedelta<br>
def isleap(year):<br>
 ?? ??return date(year, 3, 1) - date(year, 2, 1) == timedelta(29)<br>
<br>
Since python calendar only supports years in the range [1, 9999], the above will properly raise ValueError: year is out of range on negative or zero year. ??This also guarantees that calendar module&#39;s notion of leap year is the same as that of datetime module.<br>


<br>
If this is found to be a worthwhile change, I would also rewrite monthrange as<br>
<br>
def monthrange(year, month):<br>
 ?? ??first = date(year, month, 1)<br>
 ?? ??if month == 12:<br>
 ?? ?? ?? ??ndays = 31<br>
 ?? ??else:<br>
 ?? ?? ?? ??ndays = (date(year, month + 1, 1) - first).days<br>
 ?? ??return first.weekday(), ndays<br>
<div><div></div><div><br>
----------<br>
<br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org" target="_blank">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue10073" target="_blank">http://bugs.python.org/issue10073</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>

From report at bugs.python.org  Mon Oct 18 20:14:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 18 Oct 2010 18:14:16 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287425656.65.0.34488521389.issue10135@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You need to call setlocale() in your program.  For more in-depth explanations, please refer to the docs at <http://docs.python.org/library/locale>.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:14:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 18:14:44 +0000
Subject: [issue10091] ast.literal_eval does not handled new set literals
In-Reply-To: <1286998602.58.0.486068120725.issue10091@psf.upfronthosting.co.za>
Message-ID: <1287425684.45.0.722781284941.issue10091@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Set literals, a new feature indeed, have been backported to 2.7 and 3.1.  The lack of support in ast.literal_eval is arguably a bug.  Benjamin, can you make a statement as release manager?  Thanks.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10091>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:17:08 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 18 Oct 2010 18:17:08 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287425828.15.0.749427316177.issue10073@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

> return date(year, 3, 1) is not understandable. What are the arguments 3 and
> 1 in the date() function for?

Bo?tjan, we appreciate your concern for the programming style of the
Python standard library.  However, your question shows that you should
probably spend a bit more time reading documentation than "fixing" code.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:17:11 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 18 Oct 2010 18:17:11 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1287424767.34.0.282370740611.issue10073@psf.upfronthosting.co.za>
Message-ID: <AANLkTin0_p77XDSvgv34bxoX7rxAwLyZWA9iw0ty9-my@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

else:
-->    ndays = (date(year, month + 1, 1) - first).days
    return first.weekday(), ndays

Oh my God! The line with a pointer is so ugly!

On Mon, Oct 18, 2010 at 7:59 PM, Alexander Belopolsky <
report at bugs.python.org> wrote:

>
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>
> The most pedantic implementation of calendar.isleap() would be
>
> from datetime import date, timedelta
> def isleap(year):
>    return date(year, 3, 1) - date(year, 2, 1) == timedelta(29)
>
> Since python calendar only supports years in the range [1, 9999], the above
> will properly raise ValueError: year is out of range on negative or zero
> year.  This also guarantees that calendar module's notion of leap year is
> the same as that of datetime module.
>
> If this is found to be a worthwhile change, I would also rewrite monthrange
> as
>
> def monthrange(year, month):
>    first = date(year, month, 1)
>    if month == 12:
>        ndays = 31
>    else:
>        ndays = (date(year, month + 1, 1) - first).days
>    return first.weekday(), ndays
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10073>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19268/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________
-------------- next part --------------
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">???? ??else:<br>--&gt; ?? ??ndays = (date(year, month + 1, 1) - first).days<br>???? ??return first.weekday(), ndays</span><div>
<font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">Oh my God! The line with a pointer is so ugly!<br>
</span></font><br><div class="gmail_quote">On Mon, Oct 18, 2010 at 7:59 PM, Alexander Belopolsky <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im"><br>
Alexander Belopolsky &lt;<a href="mailto:belopolsky at users.sourceforge.net">belopolsky at users.sourceforge.net</a>&gt; added the comment:<br>
<br>
</div>The most pedantic implementation of calendar.isleap() would be<br>
<br>
from datetime import date, timedelta<br>
def isleap(year):<br>
 ?? ??return date(year, 3, 1) - date(year, 2, 1) == timedelta(29)<br>
<br>
Since python calendar only supports years in the range [1, 9999], the above will properly raise ValueError: year is out of range on negative or zero year. ??This also guarantees that calendar module&#39;s notion of leap year is the same as that of datetime module.<br>

<br>
If this is found to be a worthwhile change, I would also rewrite monthrange as<br>
<br>
def monthrange(year, month):<br>
 ?? ??first = date(year, month, 1)<br>
 ?? ??if month == 12:<br>
 ?? ?? ?? ??ndays = 31<br>
 ?? ??else:<br>
 ?? ?? ?? ??ndays = (date(year, month + 1, 1) - first).days<br>
 ?? ??return first.weekday(), ndays<br>
<div><div></div><div class="h5"><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/issue10073" target="_blank">http://bugs.python.org/issue10073</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Mon Oct 18 20:18:48 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 18 Oct 2010 18:18:48 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287425656.65.0.34488521389.issue10135@psf.upfronthosting.co.za>
Message-ID: <AANLkTinjrMDFPmj-B-uncHo1jrye4uLhuq+xc3Hn9uQw@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I thought having "Slovenian" locale set in Windows OS is the way the 'n'
format specifier works. So I must set the locale in the app. Now we're
cookin'! ;) Thanks Georg.

On Mon, Oct 18, 2010 at 8:14 PM, Georg Brandl <report at bugs.python.org>wrote:

>
> Georg Brandl <georg at python.org> added the comment:
>
> You need to call setlocale() in your program.  For more in-depth
> explanations, please refer to the docs at <
> http://docs.python.org/library/locale>.
>
> ----------
> nosy: +georg.brandl
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10135>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19269/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________
-------------- next part --------------
I thought having &quot;Slovenian&quot; locale set in Windows OS is the way the &#39;n&#39; format specifier works. So I must set the locale in the app. Now we&#39;re cookin&#39;! ;) Thanks Georg.<br><br><div class="gmail_quote">
On Mon, Oct 18, 2010 at 8:14 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:0 0 0 .8ex;border-left:1px #ccc solid;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>
You need to call setlocale() in your program. ??For more in-depth explanations, please refer to the docs at &lt;<a href="http://docs.python.org/library/locale" target="_blank">http://docs.python.org/library/locale</a>&gt;.<br>

<br>
----------<br>
nosy: +georg.brandl<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/issue10135" target="_blank">http://bugs.python.org/issue10135</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Mon Oct 18 20:19:03 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Oct 2010 18:19:03 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287425943.28.0.85143821031.issue9778@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

My expectation is that Py_hash_t is the same as Py_ssize_t.  The goal is to make hashes match the range of possible table sizes.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:24:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 18:24:55 +0000
Subject: [issue10031] Withdraw anti-recommendation of relative imports from
	documentation
In-Reply-To: <1286309891.2.0.339569302596.issue10031@psf.upfronthosting.co.za>
Message-ID: <1287426295.7.0.813504805286.issue10031@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report and suggestions.  I agree to the gist of your changes, but I wouldn?t remove the explanation of implicit relative imports (the part starting with ?If you?re writing code?).

----------
keywords: +patch
nosy: +eric.araujo
stage:  -> patch review
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10031>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:25:03 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 18:25:03 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287426303.63.0.462309203163.issue10073@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I don't think anything good will come out of this.  Closing as "rejected."

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:25:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 18:25:20 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287426320.98.0.761128274717.issue10073@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file19267/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:25:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 18:25:27 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287426327.57.0.0696103081473.issue10073@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file19268/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:25:28 2010
From: report at bugs.python.org (=?utf-8?b?TWljaGHFgiBHw7Nybnk=?=)
Date: Mon, 18 Oct 2010 18:25:28 +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: <1287426328.82.0.415778265032.issue9561@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/issue9561>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:28:34 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 18 Oct 2010 18:28:34 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287426514.34.0.506746327928.issue10135@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:28:46 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 18 Oct 2010 18:28:46 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287426526.1.0.572446958318.issue10135@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file19265/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:28:55 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 18 Oct 2010 18:28:55 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287426535.09.0.218727180377.issue10135@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file19266/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:29:05 2010
From: report at bugs.python.org (Eric Smith)
Date: Mon, 18 Oct 2010 18:29:05 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287426545.72.0.648720540247.issue10135@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file19269/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:34:41 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 18 Oct 2010 18:34:41 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1287426881.68.0.548161088842.issue5117@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:46:24 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Mon, 18 Oct 2010 18:46:24 +0000
Subject: [issue1467929] %-formatting and dicts
Message-ID: <1287427584.24.0.500267747873.issue1467929@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Updated patch against py3k. Fixing last reported issue with
'%(a)s %%' % {'a':'xyz'}

----------
nosy: +nvetoshkin
Added file: http://bugs.python.org/file19270/issue1467929_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1467929>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:50:45 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 18 Oct 2010 18:50:45 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1287427845.79.0.904367720213.issue9344@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I don't see how this difference is relevant for exposing the functionality in python:

Linux:

int getgrouplist(const char *user, gid_t group,
                        gid_t *groups, int *ngroups);

MacOS:

int
     getgrouplist(const char *name, int basegid, int *groups, int *ngroups);

The only difference is that Linux uses gid_t and MacOS uses int.  The requested posix.getgrouplist() will take a python string and a python integer and return a list of integers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9344>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:55:26 2010
From: report at bugs.python.org (Ned Deily)
Date: Mon, 18 Oct 2010 18:55:26 +0000
Subject: [issue10137] Patch to IDLE for Python 2.7, at Guido's request
In-Reply-To: <1287417245.71.0.949450394447.issue10137@psf.upfronthosting.co.za>
Message-ID: <1287428126.64.0.891877489748.issue10137@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I believe the enhancements here are the same as submitted for py3k in Issue10079.  Since it is likely the same comments will apply to both variants, I think it would be better to have just one issue, so I would recommend regenerating the patch against the current 2.7 svn top of trunk (or the 2.7 release), attaching the patch to #10079, and closing this as a duplicate.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10137>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:55:47 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 18 Oct 2010 18:55:47 +0000
Subject: [issue10091] ast.literal_eval does not handled new set literals
In-Reply-To: <1287425684.45.0.722781284941.issue10091@psf.upfronthosting.co.za>
Message-ID: <AANLkTikssMWhWPuLfRzdCnmoSWFiTjGg9c+-fBQGuhqb@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/10/18 ?ric Araujo <report at bugs.python.org>:
>
> ?ric Araujo <merwok at netwok.org> added the comment:
>
> Set literals, a new feature indeed, have been backported to 2.7 and 3.1. ?The lack of support in ast.literal_eval is arguably a bug. ?Benjamin, can you make a statement as release manager? ?Thanks.

No change please.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10091>
_______________________________________

From report at bugs.python.org  Mon Oct 18 20:57:47 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Mon, 18 Oct 2010 18:57:47 +0000
Subject: [issue9344] please add posix.getgrouplist()
In-Reply-To: <1279890657.77.0.804697326433.issue9344@psf.upfronthosting.co.za>
Message-ID: <1287428267.16.0.600159775431.issue9344@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

@Alexander, it was just a note, that implementation in posixmodule.c won't be the same across all flavours of Unix :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9344>
_______________________________________

From report at bugs.python.org  Mon Oct 18 21:00:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Oct 2010 19:00:17 +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: <1287428417.31.0.677875166041.issue10134@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Drat, there's a real bug here, too.  The bytes parsing machinery doesn't correctly translate crlf on input.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10134>
_______________________________________

From report at bugs.python.org  Mon Oct 18 21:13:38 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Mon, 18 Oct 2010 19:13:38 +0000
Subject: [issue1467929] %-formatting and dicts
Message-ID: <1287429218.4.0.825136796386.issue1467929@psf.upfronthosting.co.za>


Changes by Vetoshkin Nikita <nikita.vetoshkin at gmail.com>:


Removed file: http://bugs.python.org/file19270/issue1467929_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1467929>
_______________________________________

From report at bugs.python.org  Mon Oct 18 21:14:38 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Mon, 18 Oct 2010 19:14:38 +0000
Subject: [issue1467929] %-formatting and dicts
Message-ID: <1287429278.44.0.179120361701.issue1467929@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Updated patch to capture another patological case:
'%(a)s %' % {'a':'xyz'} - incomplete formatter at the end of the line

----------
Added file: http://bugs.python.org/file19271/issue1467929_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1467929>
_______________________________________

From report at bugs.python.org  Mon Oct 18 21:22:11 2010
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 18 Oct 2010 19:22:11 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1287429731.12.0.236015357699.issue5117@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Broke bunches of 2.7 buildbots.  But why are we running test_ntpath on OS X, anyway?  Shouldn't this be skipped everywhere except win32 platforms?

----------
nosy: +janssen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Mon Oct 18 21:24:00 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 18 Oct 2010 19:24:00 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1287429840.67.0.0185406822063.issue5117@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

No - the posixpath/ntpath routines are meant to be usable for path manipulation for posix/NT paths on any platform.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Mon Oct 18 21:25:03 2010
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 18 Oct 2010 19:25:03 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1287429903.39.0.989517543949.issue5117@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Then we need to revert this patch and find one that works.

----------
resolution: fixed -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Mon Oct 18 21:33:45 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Oct 2010 19:33:45 +0000
Subject: [issue10091] ast.literal_eval does not handled new set literals
In-Reply-To: <1286998602.58.0.486068120725.issue10091@psf.upfronthosting.co.za>
Message-ID: <1287430425.15.0.701959464515.issue10091@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

ast.literal_eval's docs: 

'The string or node provided may only consist of the following Python literal structures: strings, numbers, tuples, lists, dicts, booleans, and None.'

----------
resolution: out of date -> invalid

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10091>
_______________________________________

From report at bugs.python.org  Mon Oct 18 22:00:45 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 18 Oct 2010 20:00:45 +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: <1287432045.16.0.0932858282548.issue9807@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Here now is the second half of the patch, which installs the binary, library, and includes into names with abiflags.  I understand this is more controversial, but it will help continue the discussion.

----------
Added file: http://bugs.python.org/file19272/install.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Mon Oct 18 22:12:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Oct 2010 20:12:58 +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: <1287432778.96.0.347493673704.issue10134@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Here is a patch that adds a test of the underlying problem and fixes it.  I don't like this patch because it tries to detect the line ending style of the input stream and changes behavior based on that, but because email wants to use '\n' as the separator internally I don't see another way to fix it at the moment.  The ugliest part is that I changed the expected result of one existing test...but that test uses an artificial way of opening an input file in order to test the parser's universal newline handling, and I think the behavior tested is arguably incorrect.

I'm not sure this will fix all the windows failures, but it should fix most of them.

----------
keywords: +patch
Added file: http://bugs.python.org/file19273/windows_email_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10134>
_______________________________________

From report at bugs.python.org  Mon Oct 18 22:19:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 20:19:08 +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: <1287433148.24.0.817787464971.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1 for distutils_makefile_encoding.patch.  The doc is not updated, because it does not exist, so that?s okay; tests for the new behavior are missing.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Mon Oct 18 22:36:21 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 18 Oct 2010 20:36:21 +0000
Subject: [issue10137] Patch to IDLE for Python 2.7, at Guido's request
In-Reply-To: <1287417245.71.0.949450394447.issue10137@psf.upfronthosting.co.za>
Message-ID: <1287434181.73.0.203780604633.issue10137@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Bruce, what Ned suggests is what I intended with my IDLE-list message, and in accord with usual tracker practice. Issues often apply to multiple versions and thereby require multiple patches and commits. I know you are relatively new at this and very much appreciate you pushing this IDLE update.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10137>
_______________________________________

From report at bugs.python.org  Mon Oct 18 22:37:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 18 Oct 2010 20:37:08 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <20101018181136.GA3631@dbwatson.ukfsn.org>
Message-ID: <4CBCAFF1.9050105@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I would have thought that someone who intended a Unicode hostname
> to be looked up in its IDNA form would have encoded it using
> IDNA, rather than an 8-bit encoding - how many C programs would
> transcode the name that way, rather than just passing the char *
> from one interface to another?

Well, Python is not C. In Python, you would pass a str, and
expect it to work, which means it will get automatically encoded
with IDNA.

> In fact, I would think that non-ASCII bytes in a hostname most
> probably indicated that a name resolution mechanism other than
> the DNS was in use, and that the byte string should be passed
> unaltered just as a typical C program would.

I'm not talking about byte strings, but character strings.

> I don't object to that, but it does force a choice between
> decoding an 8-bit name for display (e.g. by using the locale
> encoding), and decoding it to round-trip automatically (e.g. by
> using ASCII/surrogateescape, with support on the encoding side).

In the face of ambiguity, refuse the temptation to guess.

> So overall, I do think it is better to decode names for automatic
> round-tripping rather than for display, but my main concern is
> simply that it should be possible to recover the original bytes
> so that round-tripping is at least possible.

Marc-Andre wants gethostname to use the Wide API on Windows, which,
in theory, allows for cases where round-tripping to bytes is
impossible.

----------
title: socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Mon Oct 18 22:44:27 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 18 Oct 2010 20:44:27 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1287415644.3492.5.camel@localhost.localdomain>
Message-ID: <4CBCB1A8.3070100@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 18.10.2010 17:27, schrieb Antoine Pitrou:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> AFAICT, a change from (Py_ssize_t)-1 to (size_t)-1 is less likely to
>> break code than a change from -1L to  (Py_ssize_t)-1.  (Assuming a
>> sizeof(long) != sizeof(void*) platform.)
> 
> That's true.

I don't think it is. Code that is changed to use the new return type
will not break in a change from long to Py_ssize_t, since all values
will sign-expand correctly, in all cases; the same is true if the new
return type was size_t. So for code that gets adjusted in its return
value, no breakage in either case.

For code that *doesn't* get adjusted, I'm still uncertain what will
happen. However, ISTM that if there is a cast to the "correct" function
pointer type, you get an incorrect detection of the guard value in
either case: e.g. on AMD64, the return value is in RAX, yet the hash
function may only fill out EAX. I'm not sure what values the upper
32 bits will have, but I doubt it gets sign-expanded - which it should
regardless of whether the expected value is (size_t)-1 or
(Py_ssize_t)-1. So you get breakage in either case.

Please correct me if I'm wrong.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 22:44:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 20:44:52 +0000
Subject: [issue5731] bdist_wininst no longer works on non-Windows platforms
In-Reply-To: <1239310284.73.0.299420830333.issue5731@psf.upfronthosting.co.za>
Message-ID: <1287434692.74.0.0367777827729.issue5731@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Follow-up in #8954

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5731>
_______________________________________

From report at bugs.python.org  Mon Oct 18 22:46:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 18 Oct 2010 20:46:26 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <AANLkTik8nTEVWaR_o+V8i9JjWzWXKhDWgVUysF9H8qDi@mail.gmail.com>
Message-ID: <4CBCB220.10904@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Wouldn't it be cleaner if x was the same type as hash?  Note that
> unsigned long is now wrong.  What is needed is "unsigned integer type
> of the same size as Py_hash_t."  If Py_hash_t has to stay signed, I
> think we should at least not rely of sizeof(Py_hash_t) to always
> remain the same as sizeof(size_t).

But this is an absolute requirement, a guarantee that we provide
forever, and the whole point of this patch. Py_hash_t *will* be
a signed version of size_t, just as Py_ssize_t. Not by chance, but
by careful, inherent design.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 22:48:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 18 Oct 2010 20:48:43 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1287425943.28.0.85143821031.issue9778@psf.upfronthosting.co.za>
Message-ID: <4CBCB2A8.4040100@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> My expectation is that Py_hash_t is the same as Py_ssize_t.  The goal
> is to make hashes match the range of possible table sizes.

Please read the patch:

typedef Py_ssize_t Py_hash_t;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Mon Oct 18 22:58:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Oct 2010 20:58:21 +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: <1287435501.83.0.343116467537.issue10134@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Revised patch that seems to fix all the windows failures.

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.

----------
Added file: http://bugs.python.org/file19274/windows_email_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10134>
_______________________________________

From report at bugs.python.org  Mon Oct 18 22:58:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Oct 2010 20:58:32 +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: <1287435512.53.0.927175709033.issue10134@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file19273/windows_email_fix.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10134>
_______________________________________

From report at bugs.python.org  Mon Oct 18 23:03:45 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 18 Oct 2010 21:03:45 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287435825.89.0.343699683722.issue10073@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file19255/calendar-isleap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Mon Oct 18 23:16:28 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Mon, 18 Oct 2010 21:16:28 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287436588.95.0.0884313024675.issue10073@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I have uploaded a new patch. It removes the  if year == 0  nonsense. Check it out. I hope you like it now.

When you were organizing the Standard Library, you didn't fix flaws in the calendar module. What I have in mind is, for example, the isleap() function which should be defined as is_leap(). But now it's all too late for that fixes.

Please apply my patch for calendar.isleap() to the trunk. Thanks.

----------
Added file: http://bugs.python.org/file19275/calendar-isleap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Mon Oct 18 23:17:57 2010
From: report at bugs.python.org (Philip Jenvey)
Date: Mon, 18 Oct 2010 21:17:57 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287436677.14.0.707775853746.issue10073@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/issue10073>
_______________________________________

From report at bugs.python.org  Mon Oct 18 23:22:32 2010
From: report at bugs.python.org (nick caruso)
Date: Mon, 18 Oct 2010 21:22:32 +0000
Subject: [issue9974] tokenizer.untokenize not invariant with line continuations
In-Reply-To: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>
Message-ID: <1287436952.76.0.198027751522.issue9974@psf.upfronthosting.co.za>


nick caruso <ngvrnd at gmail.com> added the comment:

--------------------------
import StringIO
import tokenize

tokens = []
def fnord(*a):
    tokens.append(a)

tokenize.tokenize(StringIO.StringIO("a = 1").readline, fnord)

tokenize.untokenize(tokens)
----------------------------------

Generates the same assertion failure, for what it's worth.  No line continuation needed.

This does not happen in 2.5 on my machine.

----------
nosy: +nick.caruso

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9974>
_______________________________________

From report at bugs.python.org  Mon Oct 18 23:28:19 2010
From: report at bugs.python.org (nick caruso)
Date: Mon, 18 Oct 2010 21:28:19 +0000
Subject: [issue9974] tokenizer.untokenize not invariant with line continuations
In-Reply-To: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>
Message-ID: <1287437299.55.0.548864803061.issue9974@psf.upfronthosting.co.za>


nick caruso <ngvrnd at gmail.com> added the comment:

Additionally, substituting "a=1\n" for "a=1" results in no assertion and successful "untokenizing" to "a = 1\n"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9974>
_______________________________________

From report at bugs.python.org  Mon Oct 18 23:31:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 18 Oct 2010 21:31:05 +0000
Subject: [issue8954] wininst regression: errors when building on linux
In-Reply-To: <1276093244.44.0.895217979727.issue8954@psf.upfronthosting.co.za>
Message-ID: <1287437465.15.0.0661498552387.issue8954@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I get an error trying to run the command because of the use of the mbcs codec.

Ezio made some comments on Rietveld, I addressed them in a local clone.

Question for Windows users/experts: Do the terms ?binary extension? and ?binary code? make sense?  If not, I can change them to the clearer ?extension modules? and ?C code?.

----------
assignee: tarek -> eric.araujo
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8954>
_______________________________________

From report at bugs.python.org  Mon Oct 18 23:36:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 18 Oct 2010 21:36:53 +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: <1287437813.26.0.913509380441.issue10134@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Clarification of my earlier comment on the patch: I think the behavior *originally* tested for by the changed test is arguably incorrect, given email's internal use of '\n' line endings.  So I think the patch improves things, but it is a potential behavior change.  Potential only, I hope, because it is unlikely anyone parsing emails in text mode would use anything other than universal newline handling in Python3.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10134>
_______________________________________

From report at bugs.python.org  Mon Oct 18 23:46:31 2010
From: report at bugs.python.org (Roumen Petrov)
Date: Mon, 18 Oct 2010 21:46:31 +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: <1287438391.75.0.790926420928.issue9807@psf.upfronthosting.co.za>


Roumen Petrov <bugtrack at roumenpetrov.info> added the comment:

- As configure script add new "substitute variable" LDVERSION" why do not use LDVERSION in Makefile instead $(VERSION)$(ABIFLAGS). Note first to replace in configure script LDVERSION="$(VERSION)" to LDVERSION="$VERSION" !

- May be $(LN) -s is not portable. What about to add macro AC_PROG_LN_S in configure script and to use $(LN_S) in makefile ?

----------
nosy: +rpetrov

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Tue Oct 19 00:26:02 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Mon, 18 Oct 2010 22:26:02 +0000
Subject: [issue10139] regex A|B : both A and B match,
	but B is wrongly preferred
In-Reply-To: <1287440762.5.0.953129438054.issue10139@psf.upfronthosting.co.za>
Message-ID: <1287440762.5.0.953129438054.issue10139@psf.upfronthosting.co.za>


New submission from ??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net>:

This is based on that StackOverflow answer: http://stackoverflow.com/questions/3957164/3963443#3963443. It also applies to Python 2.6 .

Searching for a regular expression that satisfies the mentioned SO question (a regular expression that matches strings with an initial A and/or final Z and returns everything except said initial A and final Z), I discovered something that I consider a bug. I've tried to thoroughly verify that this is not a PEBCAK before reporting the issue here.

Given:

>>> import re
>>> text= 'A***Z'

then:

>>> re.compile('(?<=^A).*(?=Z$)').search(text).group(0) # regex_1
'***'
>>> re.compile('(?<=^A).*').search(text).group(0) # regex_2
'***Z'
>>> re.compile('.*(?=Z$)').search(text).group(0) # regex_3
'A***'
>>> re.compile('(?<=^A).*(?=Z$)|(?<=^A).*').search(text).group(0) # regex_1|regex_2
'***'
>>> re.compile('(?<=^A).*(?=Z$)|.*(?=Z$)').search(text).group(0) # regex_1|regex_3
'A***'
>>> re.compile('(?<=^A).*|.*(?=Z$)').search(text).group(0) # regex_2|regex_3
'A***'
>>> re.compile('(?<=^A).*(?=Z$)|(?<=^A).*|.*(?=Z$)').search(text).group(0) # regex_1|regex_2|regex_3
'A***'

regex_1 returns '***'. Based on the documentation (http://docs.python.org/py3k/library/re.html#regular-expression-syntax), I assert that, likewise, '***' should be returned by:

regex_1|regex_2
regex_1|regex_3
regex_1|regex_2|regex_3

And yet, regex_3 ( ".*(?=Z$)" ) seems to take precedence over both regex_1 and regex_2, even though it's the last alternative.

This works even if I substitute "(?:regex_n)" for every "regex_n", so it's not a matter of precedence.

I really hope that this is a PEBCAK; if that is true, I apologize for any time lost on the issue by anyone; but really don't think it is.

----------
components: Regular Expressions
messages: 119088
nosy: tzot
priority: normal
severity: normal
status: open
title: regex A|B : both A and B match, but B is wrongly preferred
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10139>
_______________________________________

From report at bugs.python.org  Tue Oct 19 00:32:23 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 18 Oct 2010 22:32:23 +0000
Subject: [issue9011] ast_for_factor unary minus optimization changes AST
In-Reply-To: <1276702740.62.0.249201197468.issue9011@psf.upfronthosting.co.za>
Message-ID: <1287441143.65.0.561252119115.issue9011@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

I'm late to the party but looks like Mark has a good handle on the issues.  I would recommend not changing behavior in a bugfix release.  I'm pretty sure code "in the wild" would be broken.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9011>
_______________________________________

From report at bugs.python.org  Tue Oct 19 00:38:18 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Mon, 18 Oct 2010 22:38:18 +0000
Subject: [issue10139] regex A|B : both A and B match,
	but B is wrongly preferred
In-Reply-To: <1287440762.5.0.953129438054.issue10139@psf.upfronthosting.co.za>
Message-ID: <1287441498.46.0.0723094843025.issue10139@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

For completeness' sake, I also provide the "(?:regex_n)" results:

>>> text= 'A***Z'
>>> re.compile('(?:(?<=^A).*(?=Z$))').search(text).group(0) # regex_1
'***'
>>> re.compile('(?:(?<=^A).*)').search(text).group(0) # regex_2
'***Z'
>>> re.compile('(?:.*(?=Z$))').search(text).group(0) # regex_3
'A***'
>>> re.compile('(?:(?<=^A).*(?=Z$))|(?:(?<=^A).*)').search(text).group(0) # regex_1|regex_2
'***'
>>> re.compile('(?:(?<=^A).*(?=Z$))|(?:.*(?=Z$))').search(text).group(0) # regex_1|regex_3
'A***'
>>> re.compile('(?:(?<=^A).*)|(?:.*(?=Z$))').search(text).group(0) # regex_2|regex_3
'A***'
>>> re.compile('(?:(?<=^A).*(?=Z$))|(?:(?<=^A).*)|(?:.*(?=Z$))').search(text).group(0) # regex_1|regex_2|regex_3
'A***'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10139>
_______________________________________

From report at bugs.python.org  Tue Oct 19 00:54:21 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Mon, 18 Oct 2010 22:54:21 +0000
Subject: [issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)
In-Reply-To: <1264198934.84.0.705718671648.issue7759@psf.upfronthosting.co.za>
Message-ID: <1287442461.96.0.678585301651.issue7759@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Closing this bug.  I don't think it makes sense to change the mhlib module in bugfix release.  My patch is fairly simple but not simple enough to make me feel comfortable.

----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7759>
_______________________________________

From report at bugs.python.org  Tue Oct 19 01:17:00 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 18 Oct 2010 23:17:00 +0000
Subject: [issue10140] Tools/scripts/pathfix.py: add option to preserve
	timestamps
In-Reply-To: <1287443820.79.0.521760966173.issue10140@psf.upfronthosting.co.za>
Message-ID: <1287443820.79.0.521760966173.issue10140@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

I'm attempting to fix up the build in my Fedora/RHEL packages of Python to preserve timestamps of .py files as far as possible during the build, so that .pyc/.pyo files end up with predictable embedded mtime values and thus predictable hashes.

Am attaching a patch to the py3k branch which adds a "-p" option to the Tools/script/pathfix.py script, which makes it preserve the mtime of the input files.

----------
components: Build
files: pathfix-preserve-timestamps.patch
keywords: needs review, patch
messages: 119092
nosy: dmalcolm
priority: normal
severity: normal
stage: patch review
status: open
title: Tools/scripts/pathfix.py: add option to preserve timestamps
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19276/pathfix-preserve-timestamps.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10140>
_______________________________________

From report at bugs.python.org  Tue Oct 19 01:33:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 18 Oct 2010 23:33:32 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287444812.4.0.612564031623.issue10073@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Not only is this issue already closed, the patch is also wrong -- your change to the parentheses changes the semantics.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 19 01:39:31 2010
From: report at bugs.python.org (nestor)
Date: Mon, 18 Oct 2010 23:39:31 +0000
Subject: [issue10091] ast.literal_eval does not handled new set literals
In-Reply-To: <1286998602.58.0.486068120725.issue10091@psf.upfronthosting.co.za>
Message-ID: <1287445171.14.0.486095059577.issue10091@psf.upfronthosting.co.za>


nestor <nestornissen at gmail.com> added the comment:

FYI although it breaks symmetry with eval, I am fine with this going in for 3.2. It just surprised me and I wanted to make sure it was documented here for future reference.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10091>
_______________________________________

From report at bugs.python.org  Tue Oct 19 01:52:42 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Mon, 18 Oct 2010 23:52:42 +0000
Subject: [issue10137] Patch to IDLE for Python 2.7, at Guido's request
In-Reply-To: <1287423883.85.0.614480872844.issue10137@psf.upfronthosting.co.za>
Message-ID: <AANLkTim1CkA67xJXqeq_OSCXZdWYx9sf=kheLL7oJ=_F@mail.gmail.com>


Bruce Sherwood <bruce.sherwood at gmail.com> added the comment:

Perhaps I've used misleadingt terminology. What I meant is that I did
do a diff between IDLE 2.7 and the result of Guilherme Polo's work,
but the latter code started from Python 3 code and was modified as
needed for 2.7 (e.g. renaming tkinter as Tkinter, etc.) before
generating the patch.

Bruce Sherwood

On Mon, Oct 18, 2010 at 11:44 AM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> But this patch is a diff between a 2.7 and a 3.2 version of IDLE, isn't it? ?The tkinter->Tkinter renaming is not supposed to happen in the 2.7 branch.
> Could you instead show a diff between the present version of IDLE in 2.7 and the result of your work, so we can better see the impact of the change?
>
> ----------
> nosy: +amaury.forgeotdarc
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10137>
> _______________________________________
>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10137>
_______________________________________

From report at bugs.python.org  Tue Oct 19 02:49:27 2010
From: report at bugs.python.org (instigatorirc)
Date: Tue, 19 Oct 2010 00:49:27 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>


New submission from instigatorirc <instigatorirc at gmail.com>:

Python lacks support for the AF_CAN family of sockets ( http://en.wikipedia.org/wiki/Controller_area_network http://lwn.net/Articles/253425/)

https://lists.berlios.de/pipermail/socketcan-users/2010-July/001456.html

----------
components: IO
files: socketcan.dpatch
messages: 119096
nosy: instigatorirc
priority: normal
severity: normal
status: open
title: SocketCan support
type: feature request
versions: Python 2.6, Python 3.3
Added file: http://bugs.python.org/file19277/socketcan.dpatch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Tue Oct 19 03:02:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 01:02:37 +0000
Subject: [issue9425] Rewrite import machinery to work with unicode paths
In-Reply-To: <1280448814.73.0.312881779361.issue9425@psf.upfronthosting.co.za>
Message-ID: <1287450157.62.0.519486864302.issue9425@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Starting at r85691, the full test suite of Python 3.2 pass with ASCII, ISO-8859-1 and UTF-8 locale encodings in a non-ascii directory. The work on this issue is done.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9425>
_______________________________________

From report at bugs.python.org  Tue Oct 19 03:02:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 01:02:51 +0000
Subject: [issue8611] Python3 doesn't support locale different than utf8 and an
	non-ASCII path (POSIX)
In-Reply-To: <1272979850.31.0.0455265952928.issue8611@psf.upfronthosting.co.za>
Message-ID: <1287450171.84.0.26430911138.issue8611@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Starting at r85691, the full test suite of Python 3.2 pass with ASCII, ISO-8859-1 and UTF-8 locale encodings in a non-ascii directory. The work on this issue is done.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8611>
_______________________________________

From report at bugs.python.org  Tue Oct 19 03:22:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 01:22:21 +0000
Subject: [issue10114] compile() doesn't support the PEP 383 (surrogates)
In-Reply-To: <1287146091.4.0.492257332187.issue10114@psf.upfronthosting.co.za>
Message-ID: <1287451341.08.0.506942883986.issue10114@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Buildbots are green again (#10123 is closed). I ported the fix to Python 3.1 (r85716). Close this issue.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10114>
_______________________________________

From report at bugs.python.org  Tue Oct 19 03:25:56 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 19 Oct 2010 01:25:56 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1287451556.23.0.958001213342.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Sorry, I've commit the fix in r85717(release27-maint).
I'll sit and watch buildbot.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Tue Oct 19 03:59:38 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 19 Oct 2010 01:59:38 +0000
Subject: [issue5117] os.path.relpath problem with root directory
In-Reply-To: <1233386752.72.0.952122419494.issue5117@psf.upfronthosting.co.za>
Message-ID: <1287453578.65.0.695207484208.issue5117@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I confirmed test runs fine on x86 Snow Leopard 2.7.
So I'm closing this issue....

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5117>
_______________________________________

From report at bugs.python.org  Tue Oct 19 04:03:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 02:03: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: <1287453792.66.0.14354890061.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I'm not sure that the patch is still needed on Python 3.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Tue Oct 19 04:04:38 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 02:04:38 +0000
Subject: [issue9713] Py_CompileString fails on non decode-able paths.
In-Reply-To: <1283154413.35.0.877915229941.issue9713@psf.upfronthosting.co.za>
Message-ID: <1287453878.93.0.951594998706.issue9713@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See issue #10114: fixed in Python 3.1 (r85716) and in Python 3.2 (r85569+r85570).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9713>
_______________________________________

From report at bugs.python.org  Tue Oct 19 04:13:21 2010
From: report at bugs.python.org (David Stanek)
Date: Tue, 19 Oct 2010 02:13:21 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1287454401.67.0.00302370033798.issue2193@psf.upfronthosting.co.za>


David Stanek <dstanek at dstanek.com> added the comment:

My Java may be a bit rusty, but it seems that it would filter out the colon. tspecials contains a colon and thus having a colon in the cookie name would make in invalid.

I glanced at the Perl code and couldn't find where it filtered out any characters.

Would it be better to file bugs against buggy implementations instead of changing Python's implementation to be more lenient?

----------
nosy: +dstanek

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Tue Oct 19 04:14:19 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 02:14:19 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1287454459.75.0.523007631076.issue8988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I tested the example with Python 3.2 (r85691) and the issue looks to be fixed. Can someone else confirm that?

I decompressed the ZIP archive, moved into the directory containing a.py and b.py, and called \path\to\python.exe a.py: it works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8988>
_______________________________________

From report at bugs.python.org  Tue Oct 19 04:15:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 02:15:01 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1287454501.53.0.931642766824.issue8988@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

See also #3080 for the full unicode support in the import machinery.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8988>
_______________________________________

From report at bugs.python.org  Tue Oct 19 04:19:14 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 02:19:14 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1287454754.76.0.684124229236.issue3080@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

With #8611 and #9425, I patched a lot of functions and modules, including the NullImporter and zipimport, but not the core of the import machinery.

In my import_unicode SVN branch, I patched the import machinery to manipulate unicode strings, instead of bytes strings. But the patch is huge and the import machinery is fragile. Since Python 3.2 now works in a non-ASCII directory with an ASCII locale (fileystem) encoding, I don't plan to merge the patch into py3k.

The patch is still useful on Windows, because Python uses the mbcs encoding to encode/decode filenames, and this encoding is usually a very small subset of Unicode (eg. cp1252 is 256 codes wheres unicode 6.0 has 109,449 characters).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3080>
_______________________________________

From report at bugs.python.org  Tue Oct 19 04:21:22 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 19 Oct 2010 02:21:22 +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: <1287454882.03.0.53948284598.issue10027@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

How about this patch?

* st_nlink support for stat()/lstat().
* lstat() for junction read attributes of junction not target.
* stat() for symlink of system locked file (ie: c:/pagefile.sys)
  should read attributes from target locked file not of symlink
  even via FindFirstFile. (I cannot test this, sorry)

I hope other behavior was not changed by this patch.

----------
Added file: http://bugs.python.org/file19278/py3k_posixpath_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Tue Oct 19 04:22:01 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 02:22:01 +0000
Subject: [issue1552880] [Python2] Use utf-8 in the import machinery on Windows
	to support unicode paths
Message-ID: <1287454921.55.0.87164901366.issue1552880@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

FYI, I finished my work on non-ascii filenames in Python 3.2 (#8611, #9425): Python 3.2 now suports any filename with any locale (filesystem) encoding.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1552880>
_______________________________________

From report at bugs.python.org  Tue Oct 19 04:24:02 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 19 Oct 2010 02:24:02 +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: <1287455042.9.0.1769803787.issue10027@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

... I noticed I can test this via buildbot...
Probably I'll try this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Tue Oct 19 04:39:32 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 19 Oct 2010 02:39:32 +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: <1287455972.35.0.542077182829.issue10027@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'll also give it a run on my Windows machines but won't be able to until tomorrow morning (~1300 UTC).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Tue Oct 19 05:15:19 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 19 Oct 2010 03:15:19 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

ZFS supports SEEK_HOLE/SEEK_DATA in "lseek()" syscall.

Oracle Solaris man page por "lseek":

"""
[...]
       o  If whence is SEEK_HOLE, the offset of the start of  the
          next  hole greater than or equal to the supplied offset
          is returned. The definition of a hole is provided  near
          the end of the DESCRIPTION.

       o  If whence is SEEK_DATA, the file pointer is set to  the
          start  of the next non-hole file region greater than or
          equal to the supplied offset.


     The  symbolic  constants   SEEK_SET,   SEEK_CUR,   SEEK_END,
     SEEK_HOLE,   and   SEEK_DATA   are  defined  in  the  header
     <unistd.h>.
[...]
     A "hole" is defined as a contiguous  range  of  bytes  in  a
     file,  all  having the value of zero, but not all zeros in a
     file are guaranteed to be represented as holes returned with
     SEEK_HOLE. Filesystems are allowed to expose ranges of zeros
     with SEEK_HOLE, but not required to.  Applications  can  use
     SEEK_HOLE  to  optimise  their behavior for ranges of zeros,
     but must not depend on it to find all such ranges in a file.
     The  existence  of  a  hole  at the end of every data region
     allows for easy programming and implies that a virtual  hole
     exists  at  the  end  of  the  file. Applications should use
     fpathconf(_PC_MIN_HOLE_SIZE) or  pathconf(_PC_MIN_HOLE_SIZE)
     to  determine if a filesystem supports SEEK_HOLE. See fpath-
     conf(2).

     For filesystems that do not supply information about  holes,
     the file will be represented as one entire data region.
"""

Implementation would be trivial. Simply conditionally compile the constant export in the C module. Or adopt the approach in the last phrase.

Any novice?.

----------
keywords: easy
messages: 119112
nosy: jcea
priority: normal
severity: normal
status: open
title: Support for SEEK_HOLE/SEEK_DATA
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Tue Oct 19 05:16:36 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 19 Oct 2010 03:16:36 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1287458196.94.0.714277682574.issue10142@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
components: +IO, Library (Lib)

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Tue Oct 19 05:30:32 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 19 Oct 2010 03:30:32 +0000
Subject: [issue10143] Update "os.pathconf" values
In-Reply-To: <1287459031.95.0.424598520823.issue10143@psf.upfronthosting.co.za>
Message-ID: <1287459031.95.0.424598520823.issue10143@psf.upfronthosting.co.za>


New submission from Jes?s Cea Avi?n <jcea at jcea.es>:

os.pathconf and related functions are a bit outdated and some platforms, like Solaris are pretty badly represented.

We need to support more values.

Trivial to implement.

----------
components: Library (Lib)
keywords: easy
messages: 119113
nosy: jcea
priority: normal
severity: normal
status: open
title: Update "os.pathconf" values
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10143>
_______________________________________

From report at bugs.python.org  Tue Oct 19 05:31:29 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 19 Oct 2010 03:31:29 +0000
Subject: [issue10143] Update "os.pathconf" values
In-Reply-To: <1287459031.95.0.424598520823.issue10143@psf.upfronthosting.co.za>
Message-ID: <1287459089.13.0.808921542142.issue10143@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
stage:  -> needs patch
type:  -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10143>
_______________________________________

From report at bugs.python.org  Tue Oct 19 05:31:41 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 19 Oct 2010 03:31:41 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1287459101.97.0.224263921202.issue10142@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
stage:  -> needs patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Tue Oct 19 05:53:57 2010
From: report at bugs.python.org (Ron Adam)
Date: Tue, 19 Oct 2010 03:53:57 +0000
Subject: [issue9319] segfault when searching modules with help()
In-Reply-To: <1279693765.46.0.777254335316.issue9319@psf.upfronthosting.co.za>
Message-ID: <1287460437.25.0.0170002609664.issue9319@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

The test in the patch isn't quite right. The following still fails.

Python 3.2a3+ (py3k:85719, Oct 18 2010, 22:32:47) 
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import imp
>>> imp.find_module('test/badsyntax_pep3120')
Segmentation fault

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9319>
_______________________________________

From report at bugs.python.org  Tue Oct 19 06:05:48 2010
From: report at bugs.python.org (Wes McKinney)
Date: Tue, 19 Oct 2010 04:05:48 +0000
Subject: [issue10144] Buffering bug after calling curses function
In-Reply-To: <1287461148.01.0.951326412516.issue10144@psf.upfronthosting.co.za>
Message-ID: <1287461148.01.0.951326412516.issue10144@psf.upfronthosting.co.za>


New submission from Wes McKinney <wesmckinn at gmail.com>:

We tracked a bug originating in IPython to the Python interpreter itself, seems to be present in 2.6.x and 2.7.x but not 3.1.x. This is on Ubuntu Linux 10.04, does not seem to occur in OS X 10.6.

Reference: http://article.gmane.org/gmane.comp.python.ipython.user/5336

> cat bufferbug.py
"""Strange bug in buffering of sys.stdout after calling curses functions.
"""
import time
import curses

def bug():
   curses.initscr()
   curses.endwin()

def f(n=2):
   s = 0.75
   for i in range(n):
       print i
       time.sleep(s)
   print i+1

if __name__ == '__main__':
   f()
   print 'Calling bug() now!'
   bug()
   f()

####

----------
components: Interpreter Core
messages: 119115
nosy: Wes.McKinney
priority: normal
severity: normal
status: open
title: Buffering bug after calling curses function
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10144>
_______________________________________

From report at bugs.python.org  Tue Oct 19 06:20:24 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Tue, 19 Oct 2010 04:20:24 +0000
Subject: [issue10079] idlelib for Python 3 with Guilherme Polo GSoC
	enhancements
In-Reply-To: <1286939996.87.0.346411752414.issue10079@psf.upfronthosting.co.za>
Message-ID: <1287462024.28.0.29523604422.issue10079@psf.upfronthosting.co.za>


Bruce Sherwood <bruce.sherwood at gmail.com> added the comment:

At Guido's request, I've carried out the same update to the IDLE distributed with Python 2.7 that I submitted for Python 3, to incorporate the work of Guilherme Polo in the Google Summer of Code 2009. Guido was concerned that with significant problems reported for IDLE 2.7, there should be an update despite Python 2.7 itself being essentially frozen. The basic structure for IDLE 3.2 was carried over. The main changes that had to be made to the Polo code were the change in module names between Python 2.7 and Python 3.2 (e.g. Tkinter in 2.7 is tkinter in 3.2). The patch was built from the release27-maint branch. Bug report 10137 should now be listed as a duplicate.

----------
Added file: http://bugs.python.org/file19279/idlelib2.7_from_release27-maint.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10079>
_______________________________________

From report at bugs.python.org  Tue Oct 19 06:22:15 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Tue, 19 Oct 2010 04:22:15 +0000
Subject: [issue10137] Patch to IDLE for Python 2.7, at Guido's request
In-Reply-To: <1287417245.71.0.949450394447.issue10137@psf.upfronthosting.co.za>
Message-ID: <1287462135.76.0.71669616083.issue10137@psf.upfronthosting.co.za>


Bruce Sherwood <bruce.sherwood at gmail.com> added the comment:

I've rebuilt and resubmitted this patch to Issue10079 as requested by Ned Deily. This issue (10137) can now be labeled a duplicate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10137>
_______________________________________

From report at bugs.python.org  Tue Oct 19 06:29:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 19 Oct 2010 04:29:26 +0000
Subject: [issue10137] Patch to IDLE for Python 2.7, at Guido's request
In-Reply-To: <1287417245.71.0.949450394447.issue10137@psf.upfronthosting.co.za>
Message-ID: <1287462566.97.0.398284479455.issue10137@psf.upfronthosting.co.za>


Changes by Terry J. Reedy <tjreedy at udel.edu>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> idlelib for Python 3 with Guilherme Polo GSoC enhancements

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10137>
_______________________________________

From report at bugs.python.org  Tue Oct 19 06:40:55 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 19 Oct 2010 04:40:55 +0000
Subject: [issue10140] Tools/scripts/pathfix.py: add option to preserve
	timestamps
In-Reply-To: <1287443820.79.0.521760966173.issue10140@psf.upfronthosting.co.za>
Message-ID: <1287463255.97.0.909797126279.issue10140@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

The patch was fine and yes agree that preserving timestamp as an option is useful in many situations.
Committed in r85720. Thanks.

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> accepted
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10140>
_______________________________________

From report at bugs.python.org  Tue Oct 19 06:46:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 04:46:01 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287463561.5.0.317917708972.issue10073@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> for example, the isleap() function which should be defined as is_leap()
Who says that?  Not PEP?8: ?Function names should be lowercase, with words separated by underscores *as necessary to improve readability*? (emphasis mine).  isleap is perfectly readable.

> But now it's all too late for that fixes.
You?ll find that Python has a balance between readability/ease of use and pragmatism.  In some cases, changes can?t be made, but it?s best to accept it and move on to the next issue.  Working on feature requests instead of style issues is great.

On a closing note, I?ll let you enjoy the Zen of Python:
$ python -m this

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 19 06:47:20 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Tue, 19 Oct 2010 04:47:20 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1287463640.07.0.93157426476.issue10141@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Looks like an interesting feature request. What are the packages or external libraries which may rely on this and how do they deal with SocketCan support at moment for their requirements? (That thread mentions several, but some details may help further).

BTW, this can go in Python 3.2 if it gets in before Nov 2nd week. It wont be going into Python 2.x series.

----------
nosy: +orsenthil
stage:  -> patch review
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Tue Oct 19 06:49:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 04:49:58 +0000
Subject: [issue8988] import + coding = failure (3.1.2/win32)
In-Reply-To: <1276426235.15.0.873898512927.issue8988@psf.upfronthosting.co.za>
Message-ID: <1287463798.44.0.893443992949.issue8988@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/issue8988>
_______________________________________

From report at bugs.python.org  Tue Oct 19 06:50:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 04:50:07 +0000
Subject: [issue3080] Full unicode import system
In-Reply-To: <1213208697.49.0.984990811807.issue3080@psf.upfronthosting.co.za>
Message-ID: <1287463807.53.0.662136189118.issue3080@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/issue3080>
_______________________________________

From report at bugs.python.org  Tue Oct 19 06:58:10 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Oct 2010 04:58:10 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1287464290.58.0.227705215514.issue10142@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Martin, any thoughts on adding a ZFS dependent feature?  ISTM this Solaris feature hasn't taken hold elsewhere and it may be a mistake to immortalize it in Python.

----------
assignee:  -> loewis
nosy: +loewis, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Tue Oct 19 07:39:21 2010
From: report at bugs.python.org (instigatorirc)
Date: Tue, 19 Oct 2010 05:39:21 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1287466761.48.0.882133380185.issue10141@psf.upfronthosting.co.za>


instigatorirc <instigatorirc at gmail.com> added the comment:

forgot to include this: http://en.wikipedia.org/wiki/Socketcan

SocketCan is the (currently) Linux-specific Berkley-socket CAN implementation created by Volkswagen. Alot of previous CAN implementations use a rather inferior (explained in can.txt in the Linux sources) character device approach.

So the use case for programs that use SocketCan is raw sockets in C, as it is a rather specialty form of interface. But considering that it fits fairly well into an existing interface, it seems appropriate to add to python.

I clicked 2.7 because that was what the patch was written for.

Our personal use case is for an IVI dash, to access vehicle devices that output familiar metrics like speed, tach, fuel levels, seat belts, etc over CAN.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Tue Oct 19 07:42:18 2010
From: report at bugs.python.org (instigatorirc)
Date: Tue, 19 Oct 2010 05:42:18 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1287466938.64.0.801721838111.issue10141@psf.upfronthosting.co.za>


instigatorirc <instigatorirc at gmail.com> added the comment:

* PF_CAN family of sockets

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10141>
_______________________________________

From report at bugs.python.org  Tue Oct 19 09:15:07 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 19 Oct 2010 07:15:07 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287472507.12.0.377304464383.issue9778@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> The calculation of long_hash assumes an unsigned temporary type to get
> correct results for the bit shifting and masking.

Yes, exactly.

> The calculation is
> done on the absolute value of the long and then the sign is applied. We
> either needed to (1) add an unsigned Py_hash_t type or (2) just use
> size_t and Py_ssize_t.

I like (2);  the use of Py_hash_t suggests to me that the type used for the hash is configurable independently of Py_ssize_t, which isn't true.

Also, with Py_hash_t it's no longer clear that printing a hash value (e.g., using PyErr_Format and friends) should use the '%zd' modifier.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Tue Oct 19 09:33:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 19 Oct 2010 07:33:26 +0000
Subject: [issue10139] regex A|B : both A and B match,
	but B is wrongly preferred
In-Reply-To: <1287440762.5.0.953129438054.issue10139@psf.upfronthosting.co.za>
Message-ID: <1287473606.82.0.778728172353.issue10139@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'm not sure this is valid.  First, I think I have a much easier example:

>>> import re
>>> re.search('bc|abc', 'abc').group()
'abc'

I assume you'd expect this to give 'bc' as well.  However, for a string s, "search" looks for matches looking at s, then looking at s[1:], then s[2:], and so on.  For s, it looks at both branches, and the second branch matches.

This can be inferred from the docs of "search": """Scan through string looking for a location where the regular expression pattern produces a match;""", for the first location a match is produced for the second branch.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10139>
_______________________________________

From report at bugs.python.org  Tue Oct 19 09:50:14 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Tue, 19 Oct 2010 07:50:14 +0000
Subject: [issue10139] regex A|B : both A and B match,
	but B is wrongly preferred
In-Reply-To: <1287440762.5.0.953129438054.issue10139@psf.upfronthosting.co.za>
Message-ID: <1287474614.93.0.792419717728.issue10139@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

As I see it, it's more like:

>>> re.search('a.*c|a.*|.*c', 'abc').group()

producing 'bc' instead of 'abc'. Substitute "(?<=^A)" for "a" and "(?=Z$)" for "c" in the pattern above.

In your example, the first part ('bc') does not match the whole string ('abc'). In my example, the first part ('(?<=^A).*(?=Z$)') matches the whole string ('A***Z').

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10139>
_______________________________________

From report at bugs.python.org  Tue Oct 19 09:54:27 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Tue, 19 Oct 2010 07:54:27 +0000
Subject: [issue10139] regex A|B : both A and B match,
	but B is wrongly preferred
In-Reply-To: <1287440762.5.0.953129438054.issue10139@psf.upfronthosting.co.za>
Message-ID: <1287474867.02.0.280638013956.issue10139@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

Georg, please re-open it. Focus on the difference between example regex_1|regex_2 (both matching; regex_1 is used as it should be), and regex_1|regex_3 (both matching; regex_3 is used incorrectly).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10139>
_______________________________________

From report at bugs.python.org  Tue Oct 19 10:11:34 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Tue, 19 Oct 2010 08:11:34 +0000
Subject: [issue10139] regex A|B : both A and B match,
	but B is wrongly preferred
In-Reply-To: <1287440762.5.0.953129438054.issue10139@psf.upfronthosting.co.za>
Message-ID: <1287475894.19.0.358044067831.issue10139@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

No, my mistake, you did well for closing it.

The more explicit version of the explanation: both regex_1 and regex_2 start actually matching at index 1, while regex_3 starts matching at index 0.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10139>
_______________________________________

From report at bugs.python.org  Tue Oct 19 11:34:44 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 19 Oct 2010 09:34:44 +0000
Subject: [issue10141] SocketCan support
In-Reply-To: <1287449366.98.0.655876257649.issue10141@psf.upfronthosting.co.za>
Message-ID: <1287480884.55.0.880484977456.issue10141@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/issue10141>
_______________________________________

From report at bugs.python.org  Tue Oct 19 12:11:04 2010
From: report at bugs.python.org (=?utf-8?q?Brian_Boss=C3=A9?=)
Date: Tue, 19 Oct 2010 10:11:04 +0000
Subject: [issue9974] tokenizer.untokenize not invariant with line continuations
In-Reply-To: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>
Message-ID: <1287483064.15.0.991140409885.issue9974@psf.upfronthosting.co.za>


Brian Boss? <penrif at gmail.com> added the comment:

Yup, that's related to ENDMARKER being tokenized to its own line, even if EOF happens at the end of the last line of actual code.  I don't know if anything relies on that behavior so I can't really suggest changing it.

My patch handles the described situation, albeit a bit poorly as I mentioned in comment 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9974>
_______________________________________

From report at bugs.python.org  Tue Oct 19 12:29:19 2010
From: report at bugs.python.org (Eric Smith)
Date: Tue, 19 Oct 2010 10:29:19 +0000
Subject: [issue10135] Format specifier 'n' not working
In-Reply-To: <1287397563.59.0.0941833598936.issue10135@psf.upfronthosting.co.za>
Message-ID: <1287484159.57.0.379568813715.issue10135@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10135>
_______________________________________

From report at bugs.python.org  Tue Oct 19 12:33:12 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 19 Oct 2010 10:33:12 +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: <1287484392.54.0.362981315396.issue10027@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I noticed stat() won't set S_IEXEC in stat()
with my patch (py3k_posixpath_v1.patch). :-(

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Tue Oct 19 12:37:44 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 19 Oct 2010 10:37:44 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1287484664.45.0.178541380294.issue10142@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Seems to be adopted too in *bsd: http://manpages.ubuntu.com/manpages/lucid/man2/lseek.2freebsd.html .

The feature has patches available too for Linux, but never integrated in mainline kernel, AFAIK. Googling "SEEK_HOLE" is interesting.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Tue Oct 19 12:44:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 19 Oct 2010 10:44:06 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1287485046.66.0.517497854719.issue10142@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

If it's just additional constants then I don't see the problem. We already have a lot of platform-specific constants.

However, it would be a lot better if the io module were made to work properly with these constants, too. There are a lot of places where we hardcode tests such as `whence == SEEK_SET` or even `whence == 0`, and whence values above 2 aren't generally considered.

So the patch is probably a bit less trivial than what you imagine :)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Tue Oct 19 13:40:40 2010
From: report at bugs.python.org (Ralph Corderoy)
Date: Tue, 19 Oct 2010 11:40:40 +0000
Subject: [issue10145] (4.2).is_integer() is undocumented.
In-Reply-To: <1287488440.57.0.0400472595143.issue10145@psf.upfronthosting.co.za>
Message-ID: <1287488440.57.0.0400472595143.issue10145@psf.upfronthosting.co.za>


New submission from Ralph Corderoy <ralph-pythonbugs at inputplus.co.uk>:

floats now have an is_integer() method.  I think it was added in 2.6 around the same time as as_integer_ratio().  It has a docstring but it isn't mentioned in the documentation.  I only idled across it when reading the C source.  I'd expect to find it, for example, at

    http://docs.python.org/library/stdtypes.html?highlight=as_integer_ratio#additional-methods-on-float
    http://docs.python.org/py3k/library/stdtypes.html?highlight=as_integer_ratio#additional-methods-on-float

Can it please be added, and for Py2, mention what version it appeared in.

----------
assignee: docs at python
components: Documentation
messages: 119133
nosy: docs at python, ralph.corderoy
priority: normal
severity: normal
status: open
title: (4.2).is_integer() is undocumented.
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10145>
_______________________________________

From report at bugs.python.org  Tue Oct 19 14:36:53 2010
From: report at bugs.python.org (Ask Solem)
Date: Tue, 19 Oct 2010 12:36:53 +0000
Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py
In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>
Message-ID: <1287491813.16.0.743901582249.issue10128@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Is this on Windows?  Does it work for you now?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10128>
_______________________________________

From report at bugs.python.org  Tue Oct 19 14:37:19 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Oct 2010 12:37:19 +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: <1287491839.11.0.23376335025.issue10134@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Having looked more carefully at the email4 (python2) code, I think I'm wrong.  The test I changed appears to codify the behavior expected when parsing a crlf file in binary mode.  This means that email4 code being ported to email5 may depend on that behavior.  So my initial statement was in fact correct: the email5 code as it stands is correct, it is the tests that are broken.

Fixing the tests so that they run on Windows may be hard enough that I end up just skipping that particular test class on Windows.  The difficulty arises from the fact that email uses '\n' when serializing headers, but the message bodies in binary mode will have the \r\n line endings if and only if the source used \r\n.  Since the source files for those tests are text, they have different line endings depending on the platform, and so the output of re-serializing the messages is different.  

Which means, in essence, that on Windows those test failures are correct failures:  binary parse/binary serialize are *not* inverses.  This is also, then, true for a binary parse of an RFC valid input stream, since the RFCs require \r\n line separators.  In Python2 this wasn't a problem because the file or data stream could be read as text using universal newline mode, thus obscuring the difference in the input line end discipline.  In Python3 this is not possible.

So, an alternative and perhaps better fix is to add a new feature to email5's BytesGenerator that allows the output line end character sequence to be specified.  This would have the additional advantage of closing issue 1349106, and would make it easier to interface with an as-yet-nonexistent binary input interface in smtplib.

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10134>
_______________________________________

From report at bugs.python.org  Tue Oct 19 14:53:27 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Oct 2010 12:53:27 +0000
Subject: [issue10145] (4.2).is_integer() is undocumented.
In-Reply-To: <1287488440.57.0.0400472595143.issue10145@psf.upfronthosting.co.za>
Message-ID: <1287492807.38.0.386570530344.issue10145@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee: docs at python -> 
nosy: +mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10145>
_______________________________________

From report at bugs.python.org  Tue Oct 19 15:03:47 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 19 Oct 2010 13:03:47 +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: <1287493427.76.0.776687802959.issue9807@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

the python.pc installation name should be changed too, and a symlink added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Tue Oct 19 15:13:49 2010
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 19 Oct 2010 13:13:49 +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: <1287494029.02.0.638838089789.issue9807@psf.upfronthosting.co.za>


Matthias Klose <doko at debian.org> added the comment:

Lib/distutils/command/install.py () needs updates in INSTALL_SCHEMES/headers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Tue Oct 19 16:28:36 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 19 Oct 2010 14:28:36 +0000
Subject: [issue9929] subprocess.Popen unbuffered not work
In-Reply-To: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>
Message-ID: <1287498516.77.0.624520064167.issue9929@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I implemented msg117279 with v2 patch. Can I commit it?

# If your are already working on this issue, please ignore
# my patch.

----------
Added file: http://bugs.python.org/file19280/py3k_fix_unbuffered_in_subprocess_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9929>
_______________________________________

From report at bugs.python.org  Tue Oct 19 16:34:33 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 19 Oct 2010 14:34:33 +0000
Subject: [issue9929] subprocess.Popen unbuffered not work
In-Reply-To: <1285265742.42.0.656694330002.issue9929@psf.upfronthosting.co.za>
Message-ID: <1287498873.37.0.408229321588.issue9929@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Umm, v2 patch broke test_subprocess. I'll repost v3 patch
after removing "bufsize=0 && universal_newlines" check.

======================================================================
ERROR: test_universal_newlines (__main__.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_subprocess.py", line 422, in test_unive
rsal_newlines
    universal_newlines=1)
  File "e:\python-dev\py3k\lib\subprocess.py", line 621, in __init__
    raise ValueError("cannot use bufsize=0 with universal newlines")
ValueError: cannot use bufsize=0 with universal newlines

======================================================================
ERROR: test_universal_newlines_communicate (__main__.ProcessTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\test\test_subprocess.py", line 442, in test_unive
rsal_newlines_communicate
    universal_newlines=1)
  File "e:\python-dev\py3k\lib\subprocess.py", line 621, in __init__
    raise ValueError("cannot use bufsize=0 with universal newlines")
ValueError: cannot use bufsize=0 with universal newlines

----------
Added file: http://bugs.python.org/file19281/py3k_fix_unbuffered_in_subprocess_v3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9929>
_______________________________________

From report at bugs.python.org  Tue Oct 19 17:41:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 19 Oct 2010 15:41:42 +0000
Subject: [issue3062] Turtle speed() function has no effect under Mac OS X
In-Reply-To: <1212923215.43.0.432854849061.issue3062@psf.upfronthosting.co.za>
Message-ID: <1287502902.81.0.256726234716.issue3062@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a simpler and hopefully more revealing test, speed_test.py.  This test repeatedly draws a full circle at various speeds and prints the time spent.  Here is the result:

# python3.1 speed_test.py
         0: 0.03
         1: 6.61
         2: 4.32
         3: 3.78
         4: 3.23
         5: 3.21
         6: 2.65
         7: 2.72
         8: 2.66
         9: 2.86
        10: 2.67

Note that time decreases as speed changes from 1 to 4 as expected, but then changes unpredictably as speed changes from 5 to 10.

----------
nosy: +belopolsky
Added file: http://bugs.python.org/file19282/speed_test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3062>
_______________________________________

From report at bugs.python.org  Tue Oct 19 17:43:23 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 19 Oct 2010 15:43:23 +0000
Subject: [issue3062] Turtle speed() function has no effect under Mac OS X
In-Reply-To: <1212923215.43.0.432854849061.issue3062@psf.upfronthosting.co.za>
Message-ID: <1287503003.41.0.713210513824.issue3062@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/issue3062>
_______________________________________

From report at bugs.python.org  Tue Oct 19 18:10:03 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 19 Oct 2010 16:10:03 +0000
Subject: [issue10036] compiler warnings for various modules on Linux
	buildslaves
In-Reply-To: <1286344285.28.0.174737248843.issue10036@psf.upfronthosting.co.za>
Message-ID: <1287504603.96.0.177473259954.issue10036@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

At least one of these also happens on Gentoo:


Modules/_ctypes/libffi/src/dlmalloc.c:3193: warning: implicit declaration of function 'mremap'
Modules/_ctypes/libffi/src/dlmalloc.c:3193: warning: cast to pointer from integer of different size
Modules/_ctypes/libffi/src/dlmalloc.c:3612: warning: comparison between pointer and integer

----------
nosy: +djc
title: compiler warnings for various modules on Ubuntu x86 -> compiler warnings for various modules on Linux buildslaves

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10036>
_______________________________________

From report at bugs.python.org  Tue Oct 19 18:19:00 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 16:19:00 +0000
Subject: [issue10145] float.is_integer is undocumented
In-Reply-To: <1287488440.57.0.0400472595143.issue10145@psf.upfronthosting.co.za>
Message-ID: <1287505140.77.0.592911715496.issue10145@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
stage:  -> needs patch
title: (4.2).is_integer() is undocumented. -> float.is_integer is undocumented
versions:  -Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10145>
_______________________________________

From report at bugs.python.org  Tue Oct 19 18:25:24 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Tue, 19 Oct 2010 16:25:24 +0000
Subject: [issue10036] compiler warnings for various modules on Linux
	buildslaves
In-Reply-To: <1286344285.28.0.174737248843.issue10036@psf.upfronthosting.co.za>
Message-ID: <1287505524.5.0.859185793242.issue10036@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Current Ubuntu builds from the buildbot also only show the libffi warning:

http://www.python.org/dev/buildbot/builders/x86%20Ubuntu%20Shared%203.x/builds/2326/steps/compile/logs/warnings

I suspect we don't really fix libffi compile warnings because (a) libffi is just bundled from upstream in python, for ctypes, AFAICT, and (b) libffi maintenance seems to be intermittent at best. For example, it seems like we're not bundling any released version of libffi, but just some snapshot from the upstream repo.

----------
nosy: +theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10036>
_______________________________________

From report at bugs.python.org  Tue Oct 19 18:32:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Oct 2010 16:32:02 +0000
Subject: [issue10145] float.is_integer is undocumented
In-Reply-To: <1287488440.57.0.0400472595143.issue10145@psf.upfronthosting.co.za>
Message-ID: <1287505922.18.0.0727207780139.issue10145@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Woops, I didn't meant to unassign docs.

----------
assignee:  -> docs at python
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10145>
_______________________________________

From report at bugs.python.org  Tue Oct 19 18:34:40 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 19 Oct 2010 16:34:40 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1287463561.5.0.317917708972.issue10073@psf.upfronthosting.co.za>
Message-ID: <AANLkTimwkMh5q_0ZPZCPQ6yhNUjPh0SbxHstCd+=Bgoz@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I have read the Zen of PYthon before. I have also written a typo report. But
got rejected. No one listens to my ideas. So why do you have a bug tracker
anyway?

On Tue, Oct 19, 2010 at 6:46 AM, ??ric Araujo <report at bugs.python.org> wrote:

>
> ??ric Araujo <merwok at netwok.org> added the comment:
>
> > for example, the isleap() function which should be defined as is_leap()
> Who says that?  Not PEP 8: ???Function names should be lowercase, with words
> separated by underscores *as necessary to improve readability*??? (emphasis
> mine).  isleap is perfectly readable.
>
> > But now it's all too late for that fixes.
> You???ll find that Python has a balance between readability/ease of use and
> pragmatism.  In some cases, changes can???t be made, but it???s best to accept
> it and move on to the next issue.  Working on feature requests instead of
> style issues is great.
>
> On a closing note, I???ll let you enjoy the Zen of Python:
> $ python -m this
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10073>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19283/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________
-------------- next part --------------
I have read the Zen of PYthon before. I have also written a typo report. But got rejected. No one listens to my ideas. So why do you have a bug tracker anyway?<br><br><div class="gmail_quote">On Tue, Oct 19, 2010 at 6:46 AM, ??ric Araujo <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<div class="im"><br>
&gt; for example, the isleap() function which should be defined as is_leap()<br>
</div>Who says that? ??Not PEP??8: ???Function names should be lowercase, with words separated by underscores *as necessary to improve readability*??? (emphasis mine). ??isleap is perfectly readable.<br>
<div class="im"><br>
&gt; But now it&#39;s all too late for that fixes.<br>
</div>You???ll find that Python has a balance between readability/ease of use and pragmatism. ??In some cases, changes can???t be made, but it???s best to accept it and move on to the next issue. ??Working on feature requests instead of style issues is great.<br>

<br>
On a closing note, I???ll let you enjoy the Zen of Python:<br>
$ python -m this<br>
<div><div></div><div class="h5"><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/issue10073" target="_blank">http://bugs.python.org/issue10073</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Tue Oct 19 18:40:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 19 Oct 2010 16:40:51 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287506451.41.0.153247292313.issue10073@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Removed file: http://bugs.python.org/file19283/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 19 18:58:03 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 16:58:03 +0000
Subject: [issue10090] python -m locale fails on OSX
In-Reply-To: <1286998392.83.0.0924618610068.issue10090@psf.upfronthosting.co.za>
Message-ID: <1287507483.02.0.856214444377.issue10090@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, loewis
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10090>
_______________________________________

From report at bugs.python.org  Tue Oct 19 18:58:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 16:58:52 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287507532.64.0.198476402653.issue10092@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/issue10092>
_______________________________________

From report at bugs.python.org  Tue Oct 19 19:02:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 19 Oct 2010 17:02:29 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <AANLkTimwkMh5q_0ZPZCPQ6yhNUjPh0SbxHstCd+=Bgoz@mail.gmail.com>
Message-ID: <AANLkTikAKy2jVLcjV50VYb3oavQnL6Ne=trZYek+OETT@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Oct 19, 2010 at 12:34 PM, Bo?tjan Mejak <report at bugs.python.org> wrote:
> I have also written a typo report. But
> got rejected. No one listens to my ideas. So why do you have a bug tracker
> anyway?

Bug tracker is not the place to discuss ideas.  We have python-ideas
mailing list for that.

I searched the tracker and found four documentation issues that you
submitted in the past: #4389, #4648, #4649, and #6475.  In each case,
your issue received attention from the most senior python developers.
In each case the issue was closed with a detailed comment explaining
the reasons for rejection.

I think if you search the tracker for issues with "accepted" or
"fixed" resolution, you will understand why we have the bug tracker.
Reading successful reports may also help you to submit better reports
in the future.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 19 19:27:38 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 19 Oct 2010 17:27:38 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <AANLkTikAKy2jVLcjV50VYb3oavQnL6Ne=trZYek+OETT@mail.gmail.com>
Message-ID: <AANLkTimmMP76XT-gtgfFU_hUiVBP+1ExKM6QBj4VDW+Z@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

>
> your change to the parentheses changes the semantics. (Georg Brandl)

How does adding those parens change semantics? The behaviour of the function
isleap() is the same. I have throughtly tested this function and found no
semantic errors in it. So the parens don't matter for behaviour, only for
clarity they matter. But since you decided not to fix this, I won't push the
envelope. At least fix the docstrings to match the return value. Please fix
the docstrings to """Return True for leap years, False for non-leap
years."""

On Tue, Oct 19, 2010 at 7:02 PM, Alexander Belopolsky <
report at bugs.python.org> wrote:

>
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>
> On Tue, Oct 19, 2010 at 12:34 PM, Bo??tjan Mejak <report at bugs.python.org>
> wrote:
> > I have also written a typo report. But
> > got rejected. No one listens to my ideas. So why do you have a bug
> tracker
> > anyway?
>
> Bug tracker is not the place to discuss ideas.  We have python-ideas
> mailing list for that.
>
> I searched the tracker and found four documentation issues that you
> submitted in the past: #4389, #4648, #4649, and #6475.  In each case,
> your issue received attention from the most senior python developers.
> In each case the issue was closed with a detailed comment explaining
> the reasons for rejection.
>
> I think if you search the tracker for issues with "accepted" or
> "fixed" resolution, you will understand why we have the bug tracker.
> Reading successful reports may also help you to submit better reports
> in the future.
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10073>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19284/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________
-------------- next part --------------
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
your change to the parentheses changes the semantics. (Georg Brandl)</blockquote><div><br></div>How does adding those parens change semantics? The behaviour of the function isleap() is the same. I have throughtly tested this function and found no semantic errors in it. So the parens don&#39;t matter for behaviour, only for clarity they matter. But since you decided not to fix this, I won&#39;t push the envelope. At least fix the docstrings to match the return value. Please fix the docstrings to &quot;&quot;&quot;Return True for leap years, False for non-leap years.&quot;&quot;&quot;<div>
<br></div><div><br><div class="gmail_quote">On Tue, Oct 19, 2010 at 7:02 PM, Alexander Belopolsky <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Alexander Belopolsky &lt;<a href="mailto:belopolsky at users.sourceforge.net">belopolsky at users.sourceforge.net</a>&gt; added the comment:<br>
<div class="im"><br>
On Tue, Oct 19, 2010 at 12:34 PM, Bo??tjan Mejak &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br>
&gt; I have also written a typo report. But<br>
&gt; got rejected. No one listens to my ideas. So why do you have a bug tracker<br>
&gt; anyway?<br>
<br>
</div>Bug tracker is not the place to discuss ideas. ??We have python-ideas<br>
mailing list for that.<br>
<br>
I searched the tracker and found four documentation issues that you<br>
submitted in the past: #4389, #4648, #4649, and #6475. ??In each case,<br>
your issue received attention from the most senior python developers.<br>
In each case the issue was closed with a detailed comment explaining<br>
the reasons for rejection.<br>
<br>
I think if you search the tracker for issues with &quot;accepted&quot; or<br>
&quot;fixed&quot; resolution, you will understand why we have the bug tracker.<br>
Reading successful reports may also help you to submit better reports<br>
in the future.<br>
<div><div></div><div class="h5"><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/issue10073" target="_blank">http://bugs.python.org/issue10073</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Tue Oct 19 19:30:41 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 17:30:41 +0000
Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller
	icon
In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za>
Message-ID: <1287509441.64.0.179024272528.issue4480@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/issue4480>
_______________________________________

From report at bugs.python.org  Tue Oct 19 19:30:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 17:30:57 +0000
Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller
	icon
In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za>
Message-ID: <1287509457.05.0.138214480629.issue4480@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils2 -Distutils, Windows
versions: +3rd party -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4480>
_______________________________________

From report at bugs.python.org  Tue Oct 19 19:31:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 17:31:11 +0000
Subject: [issue4480] bdist_msi and bdist_wininst are missing an uninstaller
	icon
In-Reply-To: <1228122344.22.0.401809698411.issue4480@psf.upfronthosting.co.za>
Message-ID: <1287509471.12.0.668883035652.issue4480@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4480>
_______________________________________

From report at bugs.python.org  Tue Oct 19 19:32:59 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 19 Oct 2010 17:32:59 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287509579.15.0.364263162962.issue10073@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file19284/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 19 19:33:05 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 19 Oct 2010 17:33:05 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287509585.18.0.352619982986.issue10073@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file19275/calendar-isleap.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 19 19:36:58 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 19 Oct 2010 17:36:58 +0000
Subject: [issue1528363] forward in turtle module may cause incorrect display
Message-ID: <1287509818.61.0.351327662329.issue1528363@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I cannot reproduce this on OSX.  I have verified that the turtle position is correct (-70.00,30.00) after the steps reported by OP.

This must be out of date.

----------
nosy: +belopolsky
resolution:  -> out of date
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1528363>
_______________________________________

From report at bugs.python.org  Tue Oct 19 19:37:43 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 19 Oct 2010 17:37:43 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287509863.78.0.11513286295.issue10073@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I am applying a patch that only fixes the docstrings to match the return value of calendar.isleap(). The return value of isleap() is not 1 or 0 -- it is True or False. Please apply the patch. Thank you.

----------
Added file: http://bugs.python.org/file19285/isleap-docstrings.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 19 19:44:33 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 19 Oct 2010 17:44:33 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287510273.55.0.0717451938754.issue10073@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed the docstring patch in r85725.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 19 19:59:34 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 19 Oct 2010 17:59:34 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>
Message-ID: <1287511174.23.0.53429696521.issue4117@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like this has been fixed in turtle 1.1.  See r72318 and issue 5923.

----------
nosy: +belopolsky, georg.brandl
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Tue Oct 19 20:16:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 18:16:25 +0000
Subject: [issue5135] Expose simplegeneric function in functools module
In-Reply-To: <1233604660.52.0.0984436233806.issue5135@psf.upfronthosting.co.za>
Message-ID: <1287512185.53.0.6577468219.issue5135@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file18131/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5135>
_______________________________________

From report at bugs.python.org  Tue Oct 19 20:16:29 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 19 Oct 2010 18:16:29 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287512189.51.0.468788410123.issue10073@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Thank you for applying my patch. Glad to help. Please apply it to the trunk and other branches as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 19 20:19:12 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 19 Oct 2010 18:19:12 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287512352.59.0.141208935598.issue10073@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It will be merged in due time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 19 20:29:05 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 19 Oct 2010 18:29:05 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287512945.04.0.87797425999.issue10092@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

It seems that calendar.LocaleTextCalendar() changes the locale for the current interpreter session to the one you pass to argument 'locale'. This is a bug to be fixed.

----------
nosy: +Retro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Tue Oct 19 20:33:26 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 19 Oct 2010 18:33:26 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1287513206.08.0.782977371409.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> It seems that 'add=False' would be same as 'add=None' and more
> consistent with below.

The add argument is passed unchanged to canvas' bind method which is documented as taking either '' or '+' string:

http://docs.python.org/library/tkinter.html?highlight=canvas#bindings-and-events

I think anything that can be used in boolean context can be used there.  None and '' are equivalent to False and '+' is equivalent to True.  I agree that True/False are better options and suggest to change tkinter doc accordingly.

As far as changing the default value from None to False, if this is done in doc, the same should be done in the code.  I am -0 on that.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Oct 19 20:36:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 18:36:33 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287513393.17.0.688760173833.issue10092@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Indeed.  Would you like to try to make a patch for Python?3.2?  Help is here: http://www.python.org/dev/ (especially http://www.python.org/dev/patches/ ) and here: http://docs.pythonsprints.com/core_development/beginners.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Tue Oct 19 20:39:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 18:39:19 +0000
Subject: [issue10073] calendar.isleap() not checking parameter type
In-Reply-To: <1286891276.3.0.0479149618072.issue10073@psf.upfronthosting.co.za>
Message-ID: <1287513559.49.0.701125900285.issue10073@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> How does adding those parens change semantics?
It changes boolean evaluation paths.  See for example http://docs.python.org/py3k/reference/expressions#boolean-operations .  If you have more questions, python-list is an open and friendly mailing list dedicated to answering them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10073>
_______________________________________

From report at bugs.python.org  Tue Oct 19 20:50:22 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 19 Oct 2010 18:50:22 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1287513393.17.0.688760173833.issue10092@psf.upfronthosting.co.za>
Message-ID: <AANLkTin64FhoURQO4k1QSf4wGewFK3Gy5TYBxZ0BZ5Sh@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

>
> Would you like to try to make a patch for Python 3.2?

I'm not that geeky. :)

On Tue, Oct 19, 2010 at 8:36 PM, ??ric Araujo <report at bugs.python.org> wrote:

>
> ??ric Araujo <merwok at netwok.org> added the comment:
>
> Indeed.  Would you like to try to make a patch for Python 3.2?  Help is
> here: http://www.python.org/dev/ (especially
> http://www.python.org/dev/patches/ ) and here:
> http://docs.pythonsprints.com/core_development/beginners.html
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10092>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19286/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________
-------------- next part --------------
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Would you like to try to make a patch for Python??3.2?</span></blockquote><div>I&#39;m not that geeky. :)??</div>
<br><div class="gmail_quote">On Tue, Oct 19, 2010 at 8:36 PM, ??ric Araujo <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<br>
Indeed. ??Would you like to try to make a patch for Python??3.2? ??Help is here: <a href="http://www.python.org/dev/" target="_blank">http://www.python.org/dev/</a> (especially <a href="http://www.python.org/dev/patches/" target="_blank">http://www.python.org/dev/patches/</a> ) and here: <a href="http://docs.pythonsprints.com/core_development/beginners.html" target="_blank">http://docs.pythonsprints.com/core_development/beginners.html</a><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/issue10092" target="_blank">http://bugs.python.org/issue10092</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Tue Oct 19 20:55:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 19 Oct 2010 18:55:26 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287514526.66.0.354243349579.issue10092@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r85728.  The problem was that unlike other system calls, setlocale() doesn't return the old setting but the new setting.  The context manager that resets the locale therefore didn't work as intended.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Tue Oct 19 21:10:45 2010
From: report at bugs.python.org (Noah Kantrowitz)
Date: Tue, 19 Oct 2010 19:10:45 +0000
Subject: [issue10146] Incorrect regex generation in translate_pattern
In-Reply-To: <1287515445.03.0.219266745901.issue10146@psf.upfronthosting.co.za>
Message-ID: <1287515445.03.0.219266745901.issue10146@psf.upfronthosting.co.za>


New submission from Noah Kantrowitz <noah+bugs.python.org at coderanger.net>:

If a prefix is passed to translate_pattern it will generate a pattern using the unescaped output of os.path.join(). This is fine on *nix, but on Windows it results in a pattern like r'build\.*', which matches any string starting with "build" (in my case, "buildout.cfg"). Escaping the separator fixes this (patch attached).

----------
assignee: tarek
components: Distutils
files: filelist.diff
keywords: patch
messages: 119159
nosy: coderanger, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Incorrect regex generation in translate_pattern
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19287/filelist.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10146>
_______________________________________

From report at bugs.python.org  Tue Oct 19 21:19:53 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 19 Oct 2010 19:19:53 +0000
Subject: [issue10147] Python Documentation bugs
In-Reply-To: <1287515992.96.0.884562024831.issue10147@psf.upfronthosting.co.za>
Message-ID: <1287515992.96.0.884562024831.issue10147@psf.upfronthosting.co.za>


New submission from Bo?tjan Mejak <bostjan.mejak at gmail.com>:

Please read the docs here: http://docs.python.org/py3k/reference/expressions#boolean-operations

This is the last sentence in the '5.10. Boolean operations' text):
([...] Because not has to >>>invent<<< a value anyway, it does not bother to return a value of the same type as its argument, so e.g., not 'foo' yields False, not ''.)

Fix to:
([...] Because not has to >>>invert<<< a value anyway, it does not bother to return a value of the same type as its argument, so e.g., not 'foo' yields False, not ''.)

----------
assignee: docs at python
components: Documentation
messages: 119160
nosy: Retro, docs at python
priority: normal
severity: normal
status: open
title: Python Documentation bugs
versions: 3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10147>
_______________________________________

From report at bugs.python.org  Tue Oct 19 22:07:52 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Oct 2010 20:07:52 +0000
Subject: [issue10144] Buffering bug after calling curses function
In-Reply-To: <1287461148.01.0.951326412516.issue10144@psf.upfronthosting.co.za>
Message-ID: <1287518872.78.0.450527447458.issue10144@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The problem is reproducible with the python2 versions I have access to, that is, on Mac OS X and Debian Linux, and likewise not with any of the python3 3.1 and 3.2 versions.  It is most likely due to the underlying ncurses library interacting with the libc stdio, maybe changing the buffer size of the stdout file. The output is flushed as expected if the program is changed to use the python2.7 io module to write to stdout, like python3 does, rather than print which uses the 'file' object.  As a workaround on python2, it looks like the expected behavior can be restored by closing and reopening sys.stdout with something like this:

   f()
   stdout=sys.stdout
   print('Calling bug() now!')
   bug()
   fn = sys.stdout.fileno()
   sys.stdout.close()
   sys.stdout = os.fdopen(fn,'a')
   f()

----------
nosy: +akuchling, ned.deily, pitrou
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10144>
_______________________________________

From report at bugs.python.org  Tue Oct 19 22:09:20 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 19 Oct 2010 20:09:20 +0000
Subject: [issue10147] Python Documentation bugs
In-Reply-To: <1287515992.96.0.884562024831.issue10147@psf.upfronthosting.co.za>
Message-ID: <1287518960.68.0.830878305928.issue10147@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

There is one more typo bug I noted in the documentation. Please go here: http://docs.python.org/library/locale#locale.setlocale

Fix this text...
setlocale() is not >>>thread safe<<< on most systems.

...like this:
setlocale() is not >>>thread-safe<<< on most systems.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10147>
_______________________________________

From report at bugs.python.org  Tue Oct 19 22:12:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 19 Oct 2010 20:12:47 +0000
Subject: [issue10146] Incorrect regex generation in translate_pattern
In-Reply-To: <1287515445.03.0.219266745901.issue10146@psf.upfronthosting.co.za>
Message-ID: <1287519167.72.0.434328263154.issue10146@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> Impossible to include file in sdist that starts with 'build' on Win32

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10146>
_______________________________________

From report at bugs.python.org  Tue Oct 19 22:26:43 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Tue, 19 Oct 2010 20:26:43 +0000
Subject: [issue10144] Buffering bug after calling curses function
In-Reply-To: <1287461148.01.0.951326412516.issue10144@psf.upfronthosting.co.za>
Message-ID: <1287520003.04.0.926020563883.issue10144@psf.upfronthosting.co.za>


Andreas St?hrk <andy-python at hammerhartes.de> added the comment:

That behaviour is indeed caused by ncurses as it changes the buffer size of stdio. The rationale behind that is explained in a comment in ncurses/tinfo/setbuf.c (http://codesearch.google.com/codesearch/p?hl=en#5KTrgOW2hXs/pub/nslu2/sources/ncurses-5.4.tar.gz%7CqZkYBenqdbw/ncurses-5.4/ncurses/tinfo/setbuf.c&l=46)

That behaviour is also mentioned in the man-page of ncurses and one can disable it using the NCURSES_NO_SETBUF environment variable. If I set that environment variable, the example behaves as expected on my machine.

----------
nosy: +Trundle

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10144>
_______________________________________

From report at bugs.python.org  Tue Oct 19 22:44:12 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Oct 2010 20:44:12 +0000
Subject: [issue10144] Buffering bug after calling curses function
In-Reply-To: <1287461148.01.0.951326412516.issue10144@psf.upfronthosting.co.za>
Message-ID: <1287521052.86.0.740834312529.issue10144@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Thanks for NCURSES_NO_SETBUF ("when it doubt read the man page"!).  Since the problem does not seem to exist in python3 and this is likely been an issue for a long time and apparently not previously reported and there are various workarounds, I think this could be closed as "wont fix".  Any objections?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10144>
_______________________________________

From report at bugs.python.org  Tue Oct 19 23:08:30 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 19 Oct 2010 21:08:30 +0000
Subject: [issue10147] Python Documentation bugs
In-Reply-To: <1287515992.96.0.884562024831.issue10147@psf.upfronthosting.co.za>
Message-ID: <1287522510.64.0.333949582933.issue10147@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The first one is not a typo.  Fixed the second one (and similar occurrences of "thread safe") in r85731.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10147>
_______________________________________

From report at bugs.python.org  Tue Oct 19 23:10:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 19 Oct 2010 21:10:59 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1287522659.85.0.914237275218.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed some of the simpler fixes in r85732.


> ?? Unclear how [delay()] interacts with turtle.speed

Unclear indeed.  See issue 3062.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Oct 19 23:12:26 2010
From: report at bugs.python.org (John J Lee)
Date: Tue, 19 Oct 2010 21:12:26 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1287522746.7.0.285586493633.issue2193@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

dstanek> Would it be better to file bugs against buggy implementations instead of changing Python's implementation to be more lenient?

No.  Another app running on the same domain that knows nothing about RFC 2109 (and why should it?) shouldn't break your Cookie.py-using app -- did you look at the trac bug?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Tue Oct 19 23:17:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 19 Oct 2010 21:17:09 +0000
Subject: [issue3062] Turtle speed() function has no effect under Mac OS X
In-Reply-To: <1212923215.43.0.432854849061.issue3062@psf.upfronthosting.co.za>
Message-ID: <1287523029.9.0.553900263548.issue3062@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching another test that demonstrates that the speed of the turtle is different when it draws a straight line and a circle.

The output shows the time it takes to draw a line and a circle of the same length at various speed settings.

$ python3 speed_test2.py
         0: 0.01 0.02
         1: 0.96 2.25
         2: 0.67 2.24
         3: 0.32 1.81
         4: 0.25 1.39
         5: 0.27 1.89
         6: 0.15 1.44
         7: 0.12 1.53
         8: 0.10 1.69
         9: 0.10 1.73
        10: 0.08 1.64

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3062>
_______________________________________

From report at bugs.python.org  Tue Oct 19 23:44:29 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 19 Oct 2010 21:44:29 +0000
Subject: [issue6460] test failure in test_xmlrpc on Gentoo in trunk
In-Reply-To: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
Message-ID: <1287524669.98.0.53014363186.issue6460@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
can we consider this bug as fixed? test has been fixed, buildbots don't show this problem anymore and a run on my system with 300 instances of the test_xmlrpc running in parallel generated only OK as result.

Regards,
Sandro

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6460>
_______________________________________

From report at bugs.python.org  Tue Oct 19 23:47:09 2010
From: report at bugs.python.org (Fernando Perez)
Date: Tue, 19 Oct 2010 21:47:09 +0000
Subject: [issue10144] Buffering bug after calling curses function
In-Reply-To: <1287461148.01.0.951326412516.issue10144@psf.upfronthosting.co.za>
Message-ID: <1287524829.84.0.000181626273684.issue10144@psf.upfronthosting.co.za>


Fernando Perez <fdo.perez at gmail.com> added the comment:

No problem for us (IPython) if you mark it as won't fix. I've just applied the environment workaround you guys suggested:

http://github.com/ipython/ipython/commit/147b245d2ead0e15d2c17b7bb760a03126660fb7

Thanks a lot for that tip!  That leaves us in good shape.

----------
nosy: +fperez

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10144>
_______________________________________

From report at bugs.python.org  Tue Oct 19 23:51:37 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 19 Oct 2010 21:51:37 +0000
Subject: [issue7096] test_curses fails on 3.1 when run under regrtest
In-Reply-To: <1255143233.91.0.954013064992.issue7096@psf.upfronthosting.co.za>
Message-ID: <1287525097.49.0.320165723629.issue7096@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

mh, 3 months and no taker, let's close it? :)

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7096>
_______________________________________

From report at bugs.python.org  Wed Oct 20 00:02:17 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Oct 2010 22:02:17 +0000
Subject: [issue10144] Buffering bug after calling curses function
In-Reply-To: <1287461148.01.0.951326412516.issue10144@psf.upfronthosting.co.za>
Message-ID: <1287525737.55.0.194792229379.issue10144@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10144>
_______________________________________

From report at bugs.python.org  Wed Oct 20 00:06:49 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 19 Oct 2010 22:06:49 +0000
Subject: [issue6460] test failure in test_xmlrpc on Gentoo in trunk
In-Reply-To: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
Message-ID: <1287526009.18.0.712976857706.issue6460@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

I have not seen any recent failures either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6460>
_______________________________________

From report at bugs.python.org  Wed Oct 20 00:20:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 19 Oct 2010 22:20:50 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287464290.58.0.227705215514.issue10142@psf.upfronthosting.co.za>
Message-ID: <4CBE19BF.1070309@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Am 19.10.2010 06:58, schrieb Raymond Hettinger:
> 
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the
> comment:
> 
> Martin, any thoughts on adding a ZFS dependent feature?  ISTM this
> Solaris feature hasn't taken hold elsewhere and it may be a mistake
> to immortalize it in Python.

There isn't any specific patch to review yet. However, Python has
a long tradition of exposing all symbolic constants that users have
asked for, and these are no different (e.g. how many systems support
EX_SOFTWARE, or ENOTACTIVE). As long as it's just new constants, and
as long as they are guarded with an ifdef, no approval is necessary
for adding them.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Wed Oct 20 00:22:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Oct 2010 22:22:35 +0000
Subject: [issue6460] test failure in test_xmlrpc on Gentoo in trunk
In-Reply-To: <1247281782.39.0.752563688041.issue6460@psf.upfronthosting.co.za>
Message-ID: <1287526955.32.0.229320655719.issue6460@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6460>
_______________________________________

From report at bugs.python.org  Wed Oct 20 00:25:18 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 19 Oct 2010 22:25:18 +0000
Subject: [issue7096] test_curses fails on 3.1 when run under regrtest
In-Reply-To: <1255143233.91.0.954013064992.issue7096@psf.upfronthosting.co.za>
Message-ID: <1287527118.39.0.0393331982113.issue7096@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7096>
_______________________________________

From report at bugs.python.org  Wed Oct 20 01:04:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 23:04:25 +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: <1287529465.72.0.497686853891.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 7:
 - don't use snprintf() because it is not signal safe
 - catch also SIGBUS and SIGILL if available
 - Py_FatalError() uses fileno(stderr) instead of directly 2
 - Factorize code in segfault.c and test_segfault.py

----------
Added file: http://bugs.python.org/file19288/segfault_handler-7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 20 01:06:22 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Tue, 19 Oct 2010 23:06:22 +0000
Subject: [issue9791] nntplib.py lacks a test suite
In-Reply-To: <1283885249.67.0.188742256424.issue9791@psf.upfronthosting.co.za>
Message-ID: <1287529582.96.0.790119866517.issue9791@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello, in r85111 Antoine revamped nntplib modules, making it compatible with Python 3, improving its documentation and also adding a test suite. I'm marking this bug as closed/accepted; Giampaolo, if you feel you still want to work on the test suite (I admit I didn't check the coverage), please reopen it (or log a new one).

Regards,
Sandro

----------
nosy: +sandro.tosi
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9791>
_______________________________________

From report at bugs.python.org  Wed Oct 20 01:14:31 2010
From: report at bugs.python.org (Luke McCarthy)
Date: Tue, 19 Oct 2010 23:14:31 +0000
Subject: [issue10148] st_mtime differs after shutil.copy2
In-Reply-To: <1287530071.19.0.608159353416.issue10148@psf.upfronthosting.co.za>
Message-ID: <1287530071.19.0.608159353416.issue10148@psf.upfronthosting.co.za>


New submission from Luke McCarthy <luke at iogopro.co.uk>:

When copying a file with shutil.copy2() between two ext4 filesystems on 64-bit Linux, the mtime of the destination file is different after the copy. It appears as if the resolution is slightly different, so the mtime is truncated slightly. For example:

source file mtime:      1287367331.8433506
destination file mtime: 1287367331.84335

----------
components: Library (Lib)
messages: 119176
nosy: shaurz
priority: normal
severity: normal
status: open
title: st_mtime differs after shutil.copy2
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10148>
_______________________________________

From report at bugs.python.org  Wed Oct 20 01:15:11 2010
From: report at bugs.python.org (David Watson)
Date: Tue, 19 Oct 2010 23:15:11 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <4CBCAFF1.9050105@v.loewis.de>
Message-ID: <20101019231500.GA4627@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

> > In fact, I would think that non-ASCII bytes in a hostname most
> > probably indicated that a name resolution mechanism other than
> > the DNS was in use, and that the byte string should be passed
> > unaltered just as a typical C program would.
> 
> I'm not talking about byte strings, but character strings.

I mean that passing the str object from socket.gethostname() to
the Python lookup function ought to result in the same byte
string being passed to the C lookup function as was returned by
the C gethostname() function (or else that the programmer must
re-encode the str to ensure that that result is obtained).

> > I don't object to that, but it does force a choice between
> > decoding an 8-bit name for display (e.g. by using the locale
> > encoding), and decoding it to round-trip automatically (e.g. by
> > using ASCII/surrogateescape, with support on the encoding side).
> 
> In the face of ambiguity, refuse the temptation to guess.

Yes, I would interpret that to mean not using the locale encoding
for data obtained from the network.  That's another reason why
the ASCII/surrogateescape scheme appeals to me more.

> Well, Python is not C. In Python, you would pass a str, and
> expect it to work, which means it will get automatically encoded
> with IDNA.

I think there might be a misunderstanding here - I've never
proposed changing the interpretation of Unicode characters in
hostname arguments.  The ASCII/surrogateescape scheme I suggested
only changes the interpretation of unpaired surrogate codes, as
they do not occur in IDNs or any other genuine Unicode data; all
IDNs, including those solely consisting of ASCII characters,
would be encoded to the same byte sequence as before.

ASCII/surrogateescape decoding could also be used without support
on the encoding side - that would satisfy the requirement to
"refuse the temptation to guess", would allow the original bytes
to be recovered, and would mean that attempting to look up a
non-ASCII result in str form would raise an exception rather than
looking up the wrong name.

> Marc-Andre wants gethostname to use the Wide API on Windows, which,
> in theory, allows for cases where round-tripping to bytes is
> impossible.

Well, the name resolution APIs wrapped by Python are all
byte-oriented, so if the computer name were to have no bytes
equivalent then it wouldn't be possible to resolve it anyway, and
an exception rightly ought be raised at some point in the process
of trying to do so.

----------
title: socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Wed Oct 20 01:28:12 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 23:28:12 +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: <1287530892.51.0.500230669348.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch version 8:
 - fix compiler warning on Windows
 - skip test_sigfpe() on Windows: it looks like the signal handler is not executed, the program exits directly
 - fix tests for Windows end of line (\r\n vs \n)

----------
Added file: http://bugs.python.org/file19289/segfault_handler-8.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 20 01:48:30 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 23:48:30 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1275332485.24.0.0853481149333.issue8863@psf.upfronthosting.co.za>
Message-ID: <1287532110.95.0.937885492526.issue8863@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> One other concern: many OSes (e.g. Linux distributions) implement
> some kind of system-wide crash-catching utility; ...

Even if it would be possible to call the original signal handler, I think that it would be better to just disable this feature if a (better?) program also watchs for segfaults.

We should provide different ways to enable and/or disable this feature:
 - command line option? (eg. see issue #10089)
 - environment variable?
 - add a function to the sys module (or another module) to enable or disable this feature? (eg. sys.getsegfaultenabled(), sys.setsegfaultenabled(False))

I don't think that a command line option and an environment variable is pratical for an OS distributor.

With a sys function, the OS distributor can call it in the site module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 20 01:55:27 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 19 Oct 2010 23:55:27 +0000
Subject: [issue8725] Python3: use ASCII for the file system encoding on
	initfsencoding() failure
In-Reply-To: <1273927146.76.0.292282765786.issue8725@psf.upfronthosting.co.za>
Message-ID: <1287532527.55.0.688664402727.issue8725@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

initfsencoding() now raises a fatal error on get_codeset() error. Use a encoding different than the locale encoding on get_codeset() only leads to mojibake and encoding issues, it's not a good idea. Close this issue as invalid.

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8725>
_______________________________________

From report at bugs.python.org  Wed Oct 20 02:32:35 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 20 Oct 2010 00:32:35 +0000
Subject: [issue10148] st_mtime differs after shutil.copy2
In-Reply-To: <1287530071.19.0.608159353416.issue10148@psf.upfronthosting.co.za>
Message-ID: <1287534755.18.0.46298322689.issue10148@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is a system limitation. The underlying file system supports nanosecond resolution for the file stamps, and stat(2) also supports reporting them. However, utimes(2) only supports microsecond resolution when setting them.

Linux supports utimensat(2) since 2.6.22 (July 2007), however, Python doesn't use it. It would be possible to come up with a patch to transparently use it where available. Are you interested in writing such a patch?

As a consequential issue: For Python, a long time ago, it was decided that time stamps in system interfaces are floating point numbers. As a consequence, nanoseconds cannot be accurately represented for today's dates (IIUC). I doubt there is anything we could do about this; this is likely "won't fix".

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10148>
_______________________________________

From report at bugs.python.org  Wed Oct 20 02:59:31 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 20 Oct 2010 00:59:31 +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: <1287536371.89.0.719927252712.issue10027@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Added file: http://bugs.python.org/file19290/py3k_posixpath_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Wed Oct 20 02:59:47 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 20 Oct 2010 00:59:47 +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: <1287536387.77.0.699478002703.issue10027@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:


Removed file: http://bugs.python.org/file19278/py3k_posixpath_v1.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Wed Oct 20 03:03:12 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 20 Oct 2010 01:03:12 +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: <1287536592.16.0.929759477163.issue10027@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I replaced my patch (almost reverted stat() part)
I think st_nlink will be set via stat()/lstat(), at least.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Wed Oct 20 03:27:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Oct 2010 01:27:31 +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: <1287538051.02.0.614623841454.issue10134@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
dependencies: +email.Generators does not separates headers with "\r\n"

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10134>
_______________________________________

From report at bugs.python.org  Wed Oct 20 03:33:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Oct 2010 01:33:17 +0000
Subject: [issue1349106] email.Generator does not separate headers with "\r\n"
Message-ID: <1287538397.31.0.395779869308.issue1349106@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Malcolm: a Content-Transfer-Encoding of 8bit may only contain \r and \n characters as part of the line ending sequence.  8bit is *not* binary; to use a CTE of binary the SMTP server must support BINARYMIME, which I don't think is all that common yet.  At any rate, my up-to-date postfix server doesn't support it.

And in any case, the email package doesn't support the binary CTE, so it's kind of irrelevant anyway :)

All that said, however, it certainly seems useful to be able to generate crlf terminated messages as an option.  And it turns out that that capability is needed in order to be able to generate binary messages in Python3 while still remaining backward compatible with the behavior of Python2 when parsing binary messages (see issue 10134).  (Actually I think the scenario I'm finding problematic in Python3 is also problematic in Python2, it's just that there are tricks you can use to work around it in Python2 that aren't allowed in Python3 because of the byte/string separation.)

So, attached find a patch implementing a linesep option in Generator.flatten and Header.encode.

Note that this patch also fleshes out the currently abbreviated documentation for BytesGenerator.

----------
keywords: +patch
stage: unit test needed -> patch review
title: email.Generators does not separates headers with "\r\n" -> email.Generator does not separate headers with "\r\n"
versions:  -Python 2.7
Added file: http://bugs.python.org/file19291/email_linesep.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1349106>
_______________________________________

From report at bugs.python.org  Wed Oct 20 03:43:21 2010
From: report at bugs.python.org (Maciek J)
Date: Wed, 20 Oct 2010 01:43:21 +0000
Subject: [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>


New submission from Maciek J <egil at wp.pl>:

Not sure if this is a Python problem or an expat problem, but I get truncated data while parsing XML documents.

This particular project is for parsing an XML file of Wikipedia dump.

The attached files are:
* xml-parse-revisions.py - parser script
* revision-test.xml - input XML
* revision-test.xml.sql - output XML
* revision_create.sql - not really needed for this test case, but attached for completeness

You can notice that the output file sometimes contains too short values for the "timestamp". Also note that if you add whitespace to the input XML, then different timestamps will be truncated.

My Python is 2.6.6.

----------
components: XML
files: pyxml_error.zip
messages: 119184
nosy: Maciek.J
priority: normal
severity: normal
status: open
title: Data truncation in expat parser
versions: Python 2.6
Added file: http://bugs.python.org/file19292/pyxml_error.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10149>
_______________________________________

From report at bugs.python.org  Wed Oct 20 04:33:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Oct 2010 02:33:26 +0000
Subject: [issue8465] re: Backreferences vs. escapes: a silent failure solved
In-Reply-To: <1271711477.02.0.868706319352.issue8465@psf.upfronthosting.co.za>
Message-ID: <1287542006.06.0.115338751998.issue8465@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I agree with Terry.

----------
nosy: +r.david.murray
resolution:  -> out of date
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8465>
_______________________________________

From report at bugs.python.org  Wed Oct 20 05:35:18 2010
From: report at bugs.python.org (Michael Olson)
Date: Wed, 20 Oct 2010 03:35:18 +0000
Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py
In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>
Message-ID: <1287545718.23.0.103715673674.issue10128@psf.upfronthosting.co.za>


Michael Olson <olson at irinim.net> added the comment:

Sorry about that, yes, this is on Windows XP and 7, 32 bit.

And with the if statement it seems to work fine.

v/r
-- Michael Olson

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10128>
_______________________________________

From report at bugs.python.org  Wed Oct 20 06:01:48 2010
From: report at bugs.python.org (James Bowman)
Date: Wed, 20 Oct 2010 04:01:48 +0000
Subject: [issue10150] Local references not released after exception
In-Reply-To: <1287547307.96.0.164615718741.issue10150@psf.upfronthosting.co.za>
Message-ID: <1287547307.96.0.164615718741.issue10150@psf.upfronthosting.co.za>


New submission from James Bowman <bowmanator at gmail.com>:

import sys

def foo():
    x = [o] * 100
    raise ArithmeticError

o = "something"
print sys.getrefcount(o)
try:
    foo()
except ArithmeticError:
    pass
print sys.getrefcount(o)

-------------------------------------------

Gives:

4
104


Looking at the CPython source, FrameObject's deallocator does actually decrement refcounts of its locals and arguments.  Guessing that the FrameObject is not being deallocated.

----------
components: Interpreter Core
messages: 119187
nosy: James.Bowman
priority: normal
severity: normal
status: open
title: Local references not released after exception
type: resource usage
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10150>
_______________________________________

From report at bugs.python.org  Wed Oct 20 06:58:52 2010
From: report at bugs.python.org (Alex)
Date: Wed, 20 Oct 2010 04:58:52 +0000
Subject: [issue10150] Local references not released after exception
In-Reply-To: <1287547307.96.0.164615718741.issue10150@psf.upfronthosting.co.za>
Message-ID: <1287550732.68.0.203115406534.issue10150@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

That's because in Python 2.5 at that point in the code sys.exc_info() still points at the traceback (and by extension, the frame) thus x is not deallocated yet.  I don't think this is a bug.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10150>
_______________________________________

From report at bugs.python.org  Wed Oct 20 08:15:50 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Wed, 20 Oct 2010 06:15:50 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287555350.67.0.319826822923.issue10092@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

I can't be entirely sure, because a) I have never even glanced at the calendar module, and b) my locale-fu is very weak, but my buildbot has consistently failed on this test since this commit:


======================================================================
ERROR: test_localecalendars (test.test_calendar.CalendarTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/test_calendar.py", line 264, in test_localecalendars
    locale=def_locale).formatmonthname(2010, 10, 10)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/calendar.py", line 520, in formatmonthname
    with different_locale(self.locale):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/calendar.py", line 490, in __enter__
    _locale.setlocale(_locale.LC_TIME, self.locale)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/locale.py", line 538, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

I will look into it in more detail tomorrow to try to provide more meaningful feedback, but I think this "fix" has introduced a problem. If someone sees what before I have time to dig into this unfamiliar territory, yay. :)

----------
nosy: +ixokai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Wed Oct 20 08:22:08 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 Oct 2010 06:22:08 +0000
Subject: [issue10150] Local references not released after exception
In-Reply-To: <1287547307.96.0.164615718741.issue10150@psf.upfronthosting.co.za>
Message-ID: <1287555728.66.0.870029195636.issue10150@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Alex is correct.  (You can prove that by raising and catching another exception before the second getrefcount().)

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10150>
_______________________________________

From report at bugs.python.org  Wed Oct 20 08:53:12 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 Oct 2010 06:53:12 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287557592.64.0.963215383274.issue10092@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Let's see if r85735 fixed this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Wed Oct 20 08:53:15 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 Oct 2010 06:53:15 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287557595.31.0.985989040782.issue10092@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file19286/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Wed Oct 20 09:19:47 2010
From: report at bugs.python.org (Thomas Guettler)
Date: Wed, 20 Oct 2010 07:19:47 +0000
Subject: [issue10151] Docs: can globals() be updated?
In-Reply-To: <1287559187.64.0.23978641371.issue10151@psf.upfronthosting.co.za>
Message-ID: <1287559187.64.0.23978641371.issue10151@psf.upfronthosting.co.za>


New submission from Thomas Guettler <guettli at thomas-guettler.de>:

Hi,

the documentation of "globals()" is missing a note if you can update
the dictionary:

http://docs.python.org/library/functions.html?highlight=globals#globals

For "locals()" it is documented:
http://docs.python.org/library/functions.html?highlight=locals#locals

----------
assignee: docs at python
components: Documentation
messages: 119192
nosy: docs at python, guettli
priority: normal
severity: normal
status: open
title: Docs: can globals() be updated?
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10151>
_______________________________________

From report at bugs.python.org  Wed Oct 20 09:20:48 2010
From: report at bugs.python.org (Ask Solem)
Date: Wed, 20 Oct 2010 07:20:48 +0000
Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py
In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>
Message-ID: <1287559248.41.0.0939488941787.issue10128@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/issue10128>
_______________________________________

From report at bugs.python.org  Wed Oct 20 10:08:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Oct 2010 08:08:47 +0000
Subject: [issue8863] Display Python backtrace on SIGSEGV,
	SIGFPE and fatal error
In-Reply-To: <1287532110.95.0.937885492526.issue8863@psf.upfronthosting.co.za>
Message-ID: <1287562122.3429.2.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't think that a command line option and an environment variable
> is pratical for an OS distributor.

Environment variables are probably the most practical for OS vendors,
since they can simply set them in /etc/profile.d (Mandriva does that
with PYTHONDONTWRITEBYTECODE :-/).

If it's an env variable, though, it should be clear that it's
CPython-specific, so I'm not sure how to call it.
CPYTHONNOSEGFAULTHANDLER?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8863>
_______________________________________

From report at bugs.python.org  Wed Oct 20 10:52:52 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 20 Oct 2010 08:52:52 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287564772.67.0.552174528839.issue10092@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

>>> import calendar
>>> calendar.LocaleTextCalendar(locale='fr_FR').formatmonthname(2010,10,10)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python27\lib\calendar.py", line 522, in formatmonthname
    with TimeEncoding(self.locale) as encoding:
  File "C:\Python27\lib\calendar.py", line 489, in __enter__
    self.oldlocale = _locale.setlocale(_locale.LC_TIME, self.locale)
  File "C:\Python27\lib\locale.py", line 531, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

Is it just my machine or is this a common thing on most machines? If I do a test and I try to set a locale with the setlocale() method, I get this "locale.Error: unsupported locale setting". So I gather that the method setlocale() is broken and we should fix it before fixing the Locale{Text,HTML}Calendar ones.


The way setlocale() is implemented, is this:

def setlocale(category, value=None):
        """ setlocale(integer,string=None) -> string.
            Activates/queries locale processing.
        """
        if value not in (None, '', 'C'):
            raise Error, '_locale emulation only supports "C" locale'
        return 'C'


Please note that the online documentation documents its API like this:
locale.setlocale(category[, locale])  See http://docs.python.org/library/locale.html#locale.setlocale

So you can see that the implementation differs from the documentation in that it documents the 2nd argument as 'locale' where in the implementation there is 'value'. If that's a bug, I don't know.

Anyway, please fix the implementation. I found out some very interesting thing... Note the line  "if value not in (None, '', 'C')"  in the implementation. This is the faulty thing in the function because NoneType is not iterable.

Test it for yourself in the interpreter:
>>> value = None
>>> value not in None
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: argument of type 'NoneType' is not iterable

So this setlocale() always raises an error. Please fix this.

Of course, this is valid:
>>> value = None
>>> value is not None
False

No error here. So try to combine this into a workable patch. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Wed Oct 20 11:18:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 Oct 2010 09:18:48 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287566328.92.0.730400244356.issue10092@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Bostjan, both your points are invalid.  First, the locale settings that a machine supports vary greatly.  "fr_FR" doesn't need to be a valid setting on your machine.

Second, "val in None" will always fail.  "val in (None, ...)" will succeed, since you're testing membership in the given tuple that includes None.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Wed Oct 20 11:20:09 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 20 Oct 2010 09:20:09 +0000
Subject: [issue10151] Docs: can globals() be updated?
In-Reply-To: <1287559187.64.0.23978641371.issue10151@psf.upfronthosting.co.za>
Message-ID: <1287566409.4.0.999948366043.issue10151@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It is documented, however, that globals() returns the dictionary of a module, which can be modified.  For locals(), the situation is quite more complicated, which is why the warning there is warranted.

----------
nosy: +georg.brandl
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10151>
_______________________________________

From report at bugs.python.org  Wed Oct 20 11:37:59 2010
From: report at bugs.python.org (Tim Golden)
Date: Wed, 20 Oct 2010 09:37:59 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1287566328.92.0.730400244356.issue10092@psf.upfronthosting.co.za>
Message-ID: <4CBEB84A.7050605@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

Bo?tjan, the code segment you quote is the *fallback* if the
C module hasn't been built for some reason. The module simply
calls through to the underlying C Library. I notice you're
running on Windows, so this is a useful MS page:

http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx

and you can see there that a call of setlocale (LC_ALL, "English")
is valid (of "French" if you prefer):

Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale (locale.LC_ALL, "French")
'French_France.1252'
>>>

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Wed Oct 20 12:47:53 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 10:47:53 +0000
Subject: [issue10152] symtable.c: ste_tmpname uninitialized
In-Reply-To: <1287571673.13.0.775838367643.issue10152@psf.upfronthosting.co.za>
Message-ID: <1287571673.13.0.775838367643.issue10152@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Found by Valgrind:

==3947== Use of uninitialised value of size 8
==3947==    at 0x5716D13: _itoa_word (in /lib/libc-2.8.90.so)
==3947==    by 0x5719F53: vfprintf (in /lib/libc-2.8.90.so)
==3947==    by 0x5743239: vsnprintf (in /lib/libc-2.8.90.so)
==3947==    by 0x4956AF: PyOS_vsnprintf (mysnprintf.c:74)
==3947==    by 0x495661: PyOS_snprintf (mysnprintf.c:47)
==3947==    by 0x49FC1E: symtable_new_tmpname (symtable.c:1092)
==3947==    by 0x4A2CE6: symtable_handle_comprehension (symtable.c:1648)
==3947==    by 0x4A2F7C: symtable_visit_listcomp (symtable.c:1673)
==3947==    by 0x4A1C63: symtable_visit_expr (symtable.c:1363)
==3947==    by 0x4A07C5: symtable_visit_stmt (symtable.c:1178)
==3947==    by 0x4A0BBE: symtable_visit_stmt (symtable.c:1200)
==3947==    by 0x4A08D4: symtable_visit_stmt (symtable.c:1187)



The patch fixes the issue (unless the intent was to use somewhat randomized tmpnames).

----------
files: ste_tmpname.patch
keywords: patch
messages: 119198
nosy: skrah
priority: normal
severity: normal
status: open
title: symtable.c: ste_tmpname uninitialized
Added file: http://bugs.python.org/file19293/ste_tmpname.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10152>
_______________________________________

From report at bugs.python.org  Wed Oct 20 12:48:20 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 10:48:20 +0000
Subject: [issue10152] symtable.c: ste_tmpname uninitialized
In-Reply-To: <1287571673.13.0.775838367643.issue10152@psf.upfronthosting.co.za>
Message-ID: <1287571700.15.0.23563886929.issue10152@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
stage:  -> patch review
type:  -> behavior
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10152>
_______________________________________

From report at bugs.python.org  Wed Oct 20 12:51:47 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Oct 2010 10:51:47 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1287571907.68.0.784639170638.issue6864@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Richard: I don't understand your message. What abort are you talking about?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Wed Oct 20 12:58:29 2010
From: report at bugs.python.org (Malcolm Box)
Date: Wed, 20 Oct 2010 10:58:29 +0000
Subject: [issue1349106] email.Generator does not separate headers with "\r\n"
Message-ID: <1287572309.9.0.384674125356.issue1349106@psf.upfronthosting.co.za>


Malcolm Box <malcolm.box at gmail.com> added the comment:

David: Great to see a patch for this.

You're right of course, 8bit isn't binary - I meant binary.  The main place this shows up is when you're using MIME not in email (e.g. on the web), where binary transport is entirely possible.

This fix should mean that the MIME libraries are much more usable in non-email environments.  Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1349106>
_______________________________________

From report at bugs.python.org  Wed Oct 20 13:09:36 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 11:09:36 +0000
Subject: [issue10153] Memory leak in pythonrun.c
In-Reply-To: <1287572976.12.0.192446732245.issue10153@psf.upfronthosting.co.za>
Message-ID: <1287572976.12.0.192446732245.issue10153@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

Found by Valgrind, patch attached:

==4921== 24 bytes in 1 blocks are definitely lost in loss record 419 of 2,694
==4921==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==4921==    by 0x417F06: _PyObject_New (object.c:244)
==4921==    by 0x520C4E: PyFile_NewStdPrinter (fileobject.c:364)
==4921==    by 0x499438: Py_InitializeEx (pythonrun.c:281)
==4921==    by 0x49951E: Py_Initialize (pythonrun.c:322)
==4921==    by 0x4B2579: Py_Main (main.c:587)
==4921==    by 0x417D6B: main (python.c:51)

----------
components: Interpreter Core
files: pythonrun.patch
keywords: patch
messages: 119201
nosy: skrah
priority: normal
severity: normal
stage: patch review
status: open
title: Memory leak in pythonrun.c
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file19294/pythonrun.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10153>
_______________________________________

From report at bugs.python.org  Wed Oct 20 13:10:56 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 11:10:56 +0000
Subject: [issue10152] symtable.c: ste_tmpname uninitialized
In-Reply-To: <1287571673.13.0.775838367643.issue10152@psf.upfronthosting.co.za>
Message-ID: <1287573056.64.0.897106609211.issue10152@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
components: +Interpreter Core

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10152>
_______________________________________

From report at bugs.python.org  Wed Oct 20 13:54:34 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Oct 2010 11:54:34 +0000
Subject: [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1287575674.07.0.311032415095.issue10149@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

For other reviewers, I'm reposting just his python program as a text file.

Maciek: I myself don't know enough about expat to comment, but is it possible you have an issue similar to issue 10026?

----------
nosy: +r.david.murray
Added file: http://bugs.python.org/file19295/xml-parse-revisions.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10149>
_______________________________________

From report at bugs.python.org  Wed Oct 20 14:21:40 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Oct 2010 12:21:40 +0000
Subject: [issue10152] symtable.c: ste_tmpname uninitialized
In-Reply-To: <1287571673.13.0.775838367643.issue10152@psf.upfronthosting.co.za>
Message-ID: <1287577300.79.0.933044704977.issue10152@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> benjamin.peterson
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10152>
_______________________________________

From report at bugs.python.org  Wed Oct 20 14:59:37 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Oct 2010 12:59:37 +0000
Subject: [issue7473] Compile error when building a 3-way universal framework
	when a 2-way universal framework is present
In-Reply-To: <1260470622.19.0.0787488117432.issue7473@psf.upfronthosting.co.za>
Message-ID: <1287579577.59.0.484115345875.issue7473@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've verified that the patch does not cause problems when building the OSX installer.

That patch should be applied, with a short comment that explains why the code block is disabled for framework builds.

----------
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7473>
_______________________________________

From report at bugs.python.org  Wed Oct 20 15:09:55 2010
From: report at bugs.python.org (Michael Olson)
Date: Wed, 20 Oct 2010 13:09:55 +0000
Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py
In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>
Message-ID: <1287580195.96.0.330062567798.issue10128@psf.upfronthosting.co.za>


Michael Olson <olson at irinim.net> added the comment:

Ummm, I think I've been unclear on where I was making changes, I changed lib\multiprocessing\forking.py to fix the issue.

Patch attached.

----------
keywords: +patch
resolution: invalid -> 
status: closed -> open
Added file: http://bugs.python.org/file19296/issue10128.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10128>
_______________________________________

From report at bugs.python.org  Wed Oct 20 15:13:15 2010
From: report at bugs.python.org (Michael Olson)
Date: Wed, 20 Oct 2010 13:13:15 +0000
Subject: [issue10128] multiprocessing.Pool throws exception with __main__.py
In-Reply-To: <1287268913.13.0.756366299299.issue10128@psf.upfronthosting.co.za>
Message-ID: <1287580395.07.0.746703163218.issue10128@psf.upfronthosting.co.za>


Michael Olson <olson at irinim.net> added the comment:

As a note, I didn't attach a patch at first because I was fairly sure I was kludging it into submission, but at least this makes it clear as to what I did.

v/r
-- Michael Olson

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10128>
_______________________________________

From report at bugs.python.org  Wed Oct 20 15:41:36 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Oct 2010 13:41:36 +0000
Subject: [issue7473] Compile error when building a 3-way universal framework
	when a 2-way universal framework is present
In-Reply-To: <1260470622.19.0.0787488117432.issue7473@psf.upfronthosting.co.za>
Message-ID: <1287582096.47.0.169790007001.issue7473@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Committed the fix for 3.2 in r85744, for 2.7 in r85745 and for 3.1 in r85746

BTW. The installer does mention which architectures are supported, both in a README on the disk image and in one of the readme screens in the installer.

----------
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7473>
_______________________________________

From report at bugs.python.org  Wed Oct 20 15:56:33 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Oct 2010 13:56:33 +0000
Subject: [issue763708] Failures in test_macostools for --enable-unicode=ucs4
Message-ID: <1287582993.68.0.237235191524.issue763708@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


Removed file: http://bugs.python.org/file13487/issue763708.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue763708>
_______________________________________

From report at bugs.python.org  Wed Oct 20 15:58:49 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Oct 2010 13:58:49 +0000
Subject: [issue763708] Failures in test_macostools for --enable-unicode=ucs4
Message-ID: <1287583129.72.0.733612508482.issue763708@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've attached a new patch that works for me.

The new patch doesn't try to warn when running the configure script, but bails out when you run make by using an '#error' in pymacconfig.h.

(Removing 2.6 because that's in security-fix-only mode and 3.1 because this issue only affects 2.x)

----------
keywords:  -26backport, needs review, patch
versions:  -Python 2.6, Python 3.1
Added file: http://bugs.python.org/file19297/issue763708.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue763708>
_______________________________________

From report at bugs.python.org  Wed Oct 20 16:11:15 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 14:11:15 +0000
Subject: [issue3367] Uninitialized value read in parsetok.c
In-Reply-To: <1216153264.95.0.467111480464.issue3367@psf.upfronthosting.co.za>
Message-ID: <1287583875.51.0.935218628167.issue3367@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I can still reproduce it in py3k just by hitting Ctrl-D in the interactive
interpreter:


$ valgrind --db-attach=yes --suppressions=Misc/valgrind-python.supp ./python 
==16724== Memcheck, a memory error detector
==16724== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==16724== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==16724== Command: ./python
==16724== 
Python 3.2a3+ (py3k:85735M, Oct 20 2010, 14:19:24) 
[GCC 4.2.4 (Ubuntu 4.2.4-3ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 
==16724== Conditional jump or move depends on uninitialised value(s)
==16724==    at 0x4F4DB7: parsetok (parsetok.c:198)
==16724==    by 0x4F4B03: PyParser_ParseFileFlagsEx (parsetok.c:100)
==16724==    by 0x49C8FB: PyParser_ASTFromFile (pythonrun.c:1884)
==16724==    by 0x49AAC6: PyRun_InteractiveOneFlags (pythonrun.c:1124)
==16724==    by 0x49A7B8: PyRun_InteractiveLoopFlags (pythonrun.c:1035)
==16724==    by 0x49A677: PyRun_AnyFileExFlags (pythonrun.c:1004)
==16724==    by 0x4B1EDE: run_file (main.c:296)
==16724==    by 0x4B293E: Py_Main (main.c:681)
==16724==    by 0x417D6B: main (python.c:51)
==16724== 
==16724== 
==16724== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y
==16724== starting debugger with cmd: /usr/bin/gdb -nw /proc/16725/fd/1014 16725
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
Attaching to program: /proc/16725/fd/1014, process 16725
0x00000000004f4db7 in parsetok (tok=0x6c705d0, g=0x80bac0, start=256, err_ret=0x7fefffee0, flags=0x7feffff1c) at Parser/parsetok.c:198
198             if (a >= tok->line_start)
(gdb)

----------
nosy: +skrah
resolution: fixed -> 
status: closed -> open
versions: +Python 3.2 -Python 2.6, Python 3.0

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3367>
_______________________________________

From report at bugs.python.org  Wed Oct 20 16:32:14 2010
From: report at bugs.python.org (Richard)
Date: Wed, 20 Oct 2010 14:32:14 +0000
Subject: [issue6864] IDLE 2.6.1 locks up on Mac OS 10.6
In-Reply-To: <1252417045.55.0.880559864665.issue6864@psf.upfronthosting.co.za>
Message-ID: <1287585134.42.0.0673905802216.issue6864@psf.upfronthosting.co.za>


Richard <public at careaga.net> added the comment:

Sorry to be obscure, Ronald. I mistook my configuration problem, described below for the original problem. But I can reproduce the problem with opening an existing file under IDLE, which is a segmentation fault. When opening a new window, I get a blank screen but no >>> prompt.

I should have done this before on my two boxes. It shows pretty clearly that the abort trap problem in 2.6.x is my configuration problem. On the development box, I have mutliple Pythons, with varying degrees of IDLE success; on the production box I have only the factory installed 2.6.1 with no IDLE problem other than the one originally reported. Both boxes are under 10.6.4.

Development:
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
$ /usr/bin/idle2.6
CGColor with 1 components
Abort trap
# This is probably due to paths crossed with 2.6.6
$ sudo /usr/bin/idle2.6
2010-10-20 10:12:16.329 Python[11954:1707] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs
2010-10-20 10:12:31.868 Python[11954:1707] __CFServiceControllerBeginPBSLoadForLocalizations timed out while talking to pbs
0
#IDLE works, otherwise, except for the segmentation issue

Production:
Python 2.6.1 (r261:67515, Feb 11 2010, 00:51:29) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
#IDLE works, except for the segmentation issue

for completeness:

Development:
Python 3.1.2 (r312:79360M, Mar 24 2010, 01:33:18) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
$ idle3
Floating point exception

Development:
Python 2.7 (r27:82508, Jul  3 2010, 21:12:11) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
** IDLE can't import Tkinter.  Your Python may not be configured for Tk. **

Development:
Python 2.6.6 (r266:84292, Aug 28 2010, 10:17:47) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
#IDLE hangs

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6864>
_______________________________________

From report at bugs.python.org  Wed Oct 20 16:45:45 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Oct 2010 14:45:45 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1287585945.3.0.186742667735.issue9670@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The attached patch explicitly sets the minimal stack size to about 704K, which is the minimal size where 'def f(): f()' doesn't cause a buserror when run in a thread.

----------
keywords: +needs review, patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19298/issue9670.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Wed Oct 20 16:56:33 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Oct 2010 14:56:33 +0000
Subject: [issue6763] Crash on mac os x leopard in mimetypes.guess_type (or
	PyObject_Malloc)
In-Reply-To: <1250976396.98.0.596987057251.issue6763@psf.upfronthosting.co.za>
Message-ID: <1287586593.33.0.204958736391.issue6763@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm closing this as a duplicate of #9670, that is: too deep recursion in a thread doesn't trigger the appropriate exception but causes a hard crash instead.

I have attached a patch to that issue (but haven't applied it yet, I'd like someone else too look at the patch as well).

BTW. I don't think this issue is serious enough to warrant a backport to 2.6.

----------
resolution:  -> duplicate
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6763>
_______________________________________

From report at bugs.python.org  Wed Oct 20 16:59:25 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Oct 2010 14:59:25 +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: <1287586765.29.0.693620018902.issue9047@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Marc-Andre: does the current HEAD of the 2.7 and 3.2 branches work for you?

The build still has duplicate flags, but that doesn't seem to cause problems on my machines. If it also doesn't cause problems on your machines I'd prefer to close this issue as won't fixed because cleaning up the duplicate flags is non-trivial.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9047>
_______________________________________

From report at bugs.python.org  Wed Oct 20 17:31:25 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Wed, 20 Oct 2010 15:31:25 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>
Message-ID: <1287588685.92.0.0691926945263.issue10154@psf.upfronthosting.co.za>


New submission from Stephen Hansen <me+python at ixokai.io>:

In the course of investigating issue10092, Georg discovered that the behavior of locale.normalize() on Mac is bad.

Basically, "en_US.UTF-8" is how the "correct" locale string should be spelled on the Mac. If you drop the dash, it fails: which locale.normalize does, so you can't pass the return value of the function to setlocale, even though that's what its documented to be for.

If that isn't clear, this should demonstrate (from /branches/py3k):


Top-2:build pythonbuildbot$ ./python.exe
Python 3.2a3+ (py3k:85631, Oct 17 2010, 06:45:22) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
[51767 refs]
>>> locale.normalize("en_US.UTF-8")
'en_US.UTF8'
[51770 refs]
>>> locale.setlocale(locale.LC_TIME, 'en_US.UTF8')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/pythonbuildbot/test/build/Lib/locale.py", line 538, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
[51816 refs]
>>> locale.setlocale(locale.LC_TIME, 'en_US.UTF-8')
'en_US.UTF-8'
[51816 refs]

The precise same behavior exists on my stock/system Python 2.6, too, fwiw. (Not that it can be fixed on 2.6, but maybe 2.7?)

----------
assignee: ronaldoussoren
components: Library (Lib), Macintosh
messages: 119213
nosy: ixokai, ronaldoussoren
priority: normal
severity: normal
status: open
title: locale.normalize strips "-" from UTF-8, which fails on Mac
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Wed Oct 20 17:41:40 2010
From: report at bugs.python.org (Leonardo Santagada)
Date: Wed, 20 Oct 2010 15:41:40 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1287589300.13.0.686685764818.issue9670@psf.upfronthosting.co.za>


Leonardo Santagada <santagada at gmail.com> added the comment:

Why not make it bigger so it doesn't crash for much bigger functions?

----------
nosy: +santagada

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Wed Oct 20 17:44:50 2010
From: report at bugs.python.org (And Clover)
Date: Wed, 20 Oct 2010 15:44:50 +0000
Subject: [issue9022] TypeError in wsgiref.handlers when using CGIHandler
In-Reply-To: <1276820747.2.0.467969862682.issue9022@psf.upfronthosting.co.za>
Message-ID: <1287589490.67.0.228630875274.issue9022@psf.upfronthosting.co.za>


And Clover <and at doxdesk.com> added the comment:

Yes, CGIHandler is broken in 3.0-3.1; wsgiref in general has been in limbo until the whole issue of py3k-WSGI is sorted. This seems to be happening now in PEP 3333.

Attached patch to make CGIHandler use the byte interfaces for stdin/stdout, which allows the write calls to work and provides byte streams to the WSGI application as required by PEP 3333.

----------
keywords: +patch
nosy: +aclover
Added file: http://bugs.python.org/file19299/issue9022.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9022>
_______________________________________

From report at bugs.python.org  Wed Oct 20 17:46:23 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Oct 2010 15:46:23 +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: <A0153B5D-DEEC-4B14-8F88-34CB7A1E604F@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

This patch solves the immediate failure:

Index: Lib/locale.py
===================================================================
--- Lib/locale.py	(revision 85743)
+++ Lib/locale.py	(working copy)
@@ -396,6 +396,9 @@
         else:
             encoding = defenc
         #print 'found encoding %r' % encoding
+        if sys.platform == 'darwin' and encoding == 'UTF8':
+            encoding = 'UTF-8'
+
         if encoding:
             return langname + '.' + encoding
         else:

I'm not happy about hardcoding this specific exception though, there should be a better solution than this.

Ronald

----------
Added file: http://bugs.python.org/file19300/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20101020/bb9064c3/attachment.bin>

From report at bugs.python.org  Wed Oct 20 17:48:42 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Oct 2010 15:48:42 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1287589300.13.0.686685764818.issue9670@psf.upfronthosting.co.za>
Message-ID: <19C43D39-8842-4EC3-9E3A-1B3F75A6A6FE@mac.com>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

On 20 Oct, 2010, at 17:41, Leonardo Santagada wrote:

> 
> Leonardo Santagada <santagada at gmail.com> added the comment:
> 
> Why not make it bigger so it doesn't crash for much bigger functions?

I don't mind making it bigger, but a larger size does come with a cost: the larger the initial stack size the less threads you can have without trashing the system (or running out of address space on a 32-bit build). 

I'm fine with increasing it to 1M, which is a nice round number build not larger. 

BTW. I haven't looked up the default stack size for the main thread on OSX.

Ronald
> 
> ----------
> nosy: +santagada
> 
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue9670>
> _______________________________________

----------
Added file: http://bugs.python.org/file19301/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20101020/a250de49/attachment.bin>

From report at bugs.python.org  Wed Oct 20 17:49:01 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Wed, 20 Oct 2010 15:49:01 +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: <1287589741.71.0.134532216976.issue10154@psf.upfronthosting.co.za>


Changes by Ronald Oussoren <ronaldoussoren at mac.com>:


Removed file: http://bugs.python.org/file19300/smime.p7s

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Wed Oct 20 17:53:08 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 20 Oct 2010 15:53:08 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1287589988.66.0.410362093624.issue10089@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a simpler version without comma-separated pairs.

----------
Added file: http://bugs.python.org/file19302/xopts3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Wed Oct 20 17:58:00 2010
From: report at bugs.python.org (Leonardo Santagada)
Date: Wed, 20 Oct 2010 15:58:00 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1287590280.11.0.862486122674.issue9670@psf.upfronthosting.co.za>


Leonardo Santagada <santagada at gmail.com> added the comment:

The default stack size in osx is 8MB. I think it is a safer bet, and no one is supposed to be using more than like 40-50 threads anyway (specially in 32 bit only systems limited to 8 cores).

Is there a user case for hundreds/thousands of threads in python?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Wed Oct 20 18:23:42 2010
From: report at bugs.python.org (And Clover)
Date: Wed, 20 Oct 2010 16:23:42 +0000
Subject: [issue10155] Add fixups for encoding problems to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>


New submission from And Clover <and at doxdesk.com>:

Currently wsgiref's CGIHandler makes a WSGI environ from the CGI environ without changes.

Unfortunately the CGI environ is wrong in a number of common circumstances:

- on Windows, the native environ is Unicode, and different servers choose different decodings for HTTP bytes to store in the environ (most notably for PATH_INFO);

- on Windows with Python 2.x, os.environ is read from the Unicode native environ using the ANSI encoding, which will lose/mangle non-ASCII characters;

- on Posix with Python 3.x, os.environ is read from a native bytes environ using the filesystemencoding which is probably not ISO-8859-1.

- on IIS, PATH_INFO inappropriately includes SCRIPT_NAME unless a hidden, rarely-used, and problematic config option is applied.

Previously, it was not clear in PEP 333 what was supposed to happen with headers and encodings, especially under Python 3. PEP 3333 clears this up. These patches add fixups to wsgiref to try to generate the nearest to a 'correct' environ as per PEP 3333 as possible for the current platform and server software.

They also fix simple_server to use the correct encoding for PATH_INFO, and include the fix for issue 9022, correspondingly updating the simple_server demo app and tests to conform to PEP 3333's expectation that headers will be ISO-8859-1-decoded Unicode strings. The test_bytes_validation test is removed: as I understand it, it's no long allowed to use byte string headers/status.

----------
components: Library (Lib)
files: wsgiref-patches-3.2a3.patch
keywords: patch
messages: 119220
nosy: aclover
priority: normal
severity: normal
status: open
title: Add fixups for encoding problems to wsgiref
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file19303/wsgiref-patches-3.2a3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10155>
_______________________________________

From report at bugs.python.org  Wed Oct 20 18:25:32 2010
From: report at bugs.python.org (And Clover)
Date: Wed, 20 Oct 2010 16:25:32 +0000
Subject: [issue10155] Add fixups for encoding problems to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1287591932.74.0.484416629612.issue10155@psf.upfronthosting.co.za>


And Clover <and at doxdesk.com> added the comment:

(patch for Python 2.x, for what it's worth)

----------
Added file: http://bugs.python.org/file19304/wsgiref-patches-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10155>
_______________________________________

From report at bugs.python.org  Wed Oct 20 18:30:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Oct 2010 16:30:32 +0000
Subject: [issue9670] Exceed Recursion Limit in Thread
In-Reply-To: <1282656201.3.0.572219885558.issue9670@psf.upfronthosting.co.za>
Message-ID: <1287592232.71.0.593710563157.issue9670@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

It would be nice if we could expand this fix to include FreeBSD, which as I understand it has the same problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9670>
_______________________________________

From report at bugs.python.org  Wed Oct 20 18:39:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Oct 2010 16:39:02 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1287592742.88.0.069476788224.issue4388@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> One solution would be to duplicate the UTF-8 decoder for OSX,
> incorporating surrogate escape. This should be much shorter 
> than the full UTF-8 codec, and perhaps at least utf8_code_length 
> could be shared.

Good idea, implemented in the attached patch [osx_utf8_cmdline-3.patch]. I tested the patch on x86 Snow Leopard 3.x and it looks like it fixes the test_cmd_line failure (I modified some tests to remove manually LC_ALL, LC_CTYPE and LANG environment variables).

----------
Added file: http://bugs.python.org/file19305/osx_utf8_cmdline-3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Wed Oct 20 18:56:02 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Oct 2010 16:56:02 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1287592742.88.0.069476788224.issue4388@psf.upfronthosting.co.za>
Message-ID: <201010201855.53329.victor.stinner@haypocalc.com>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

_Py_DecodeUTF8_surrogateescape() is a simplified version of 
PyUnicode_DecodeUTF8Stateful():
 - no "consumed" argument
 - only support surrogateescape error handler
 - no optimization
 - don't resize the buffer at exit

Hum, resize the buffer is maybe a good idea to not waste memory.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Wed Oct 20 19:05:03 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 20 Oct 2010 17:05:03 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <4CBEB84A.7050605@timgolden.me.uk>
Message-ID: <AANLkTinsqN94+=7PpyM7_UOyL6cFJoZUhpywTYJDdKhe@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Thank you so much for your answer. The
locale.setlocale(category=locale.LC_NUMERIC,
locale="Slovenian")  works like a charm in my application. Now the 'n'
format specifier works as I want. But tell me whether the 'n' format
specifier can be forced to round the float to just one decimal place. I know
that the 'f' format specifier does that by specifying ".1f", but 'f' is not
locale-aware. I have set the 'n' format specifier in my application like
".3n", which is okay if the returned number is two integers and one decimal,
but is not okay if the returned number is one integer and two decimals,
because I want just one decimal, always. How can I make that by using the
'n' format specifier?

On Wed, Oct 20, 2010 at 11:37 AM, Tim Golden <report at bugs.python.org> wrote:

>
> Tim Golden <mail at timgolden.me.uk> added the comment:
>
> Bo??tjan, the code segment you quote is the *fallback* if the
> C module hasn't been built for some reason. The module simply
> calls through to the underlying C Library. I notice you're
> running on Windows, so this is a useful MS page:
>
> http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx
>
> and you can see there that a call of setlocale (LC_ALL, "English")
> is valid (of "French" if you prefer):
>
> Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
> (Intel)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import locale
> >>> locale.setlocale (locale.LC_ALL, "French")
> 'French_France.1252'
> >>>
>
> ----------
> nosy: +tim.golden
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10092>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19306/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________
-------------- next part --------------
Thank you so much for your answer. The ??<span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">locale.setlocale(category=locale.LC_NUMERIC, locale=&quot;Slovenian&quot;) ??works like a charm in my application. Now the &#39;n&#39; format specifier works as I want. But tell me whether the &#39;n&#39; format specifier can be forced to round the float to just one decimal place. I know that the &#39;f&#39; format specifier does that by specifying &quot;.1f&quot;, but &#39;f&#39; is not locale-aware. I have set the &#39;n&#39; format specifier in my application like &quot;.3n&quot;, which is okay if the returned number is two integers and one decimal, but is not okay if the returned number is one integer and two decimals, because I want just one decimal, always. How can I make that by using the &#39;n&#39; format specifier?</span><div>
<font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br></span></font></div><div><font class="Apple-style-span" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font><div class="gmail_quote">On Wed, Oct 20, 2010 at 11:37 AM, Tim Golden <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org" target="_blank">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Tim Golden &lt;<a href="mailto:mail at timgolden.me.uk" target="_blank">mail at timgolden.me.uk</a>&gt; added the comment:<br>
<br>
Bo??tjan, the code segment you quote is the *fallback* if the<br>
C module hasn&#39;t been built for some reason. The module simply<br>
calls through to the underlying C Library. I notice you&#39;re<br>
running on Windows, so this is a useful MS page:<br>
<br>
<a href="http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx</a><br>
<br>
and you can see there that a call of setlocale (LC_ALL, &quot;English&quot;)<br>
is valid (of &quot;French&quot; if you prefer):<br>
<br>
Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit<br>
(Intel)] on win32<br>
Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more information.<br>
&gt;&gt;&gt; import locale<br>
&gt;&gt;&gt; locale.setlocale (locale.LC_ALL, &quot;French&quot;)<br>
&#39;French_France.1252&#39;<br>
&gt;&gt;&gt;<br>
<br>
----------<br>
nosy: +tim.golden<br>
<div><div></div><div><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org" target="_blank">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue10092" target="_blank">http://bugs.python.org/issue10092</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>
</div>

From report at bugs.python.org  Wed Oct 20 19:27:07 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 17:27:07 +0000
Subject: [issue10156] Memory leak (r70459)
In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>
Message-ID: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

This is one of two remaining "definitely lost" leaks in py3k. It started
to appear in r70459. How to reproduce:

make distclean && ./configure OPT="-O0 -g" --without-pymalloc && make

valgrind --leak-check=full --suppressions=Misc/valgrind-python.supp ./python > VGOUT 2>&1

Then search for 'definitely'. This leak is not present in release-2.7.


==2058== 56 bytes in 1 blocks are definitely lost in loss record 918 of 2,136
==2058==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==2058==    by 0x4167DE: _PyObject_New (object.c:243)
==2058==    by 0x42C278: _PyUnicode_New (unicodeobject.c:341)
==2058==    by 0x4306BD: PyUnicodeUCS2_DecodeUTF8Stateful (unicodeobject.c:2100)
==2058==    by 0x430671: PyUnicodeUCS2_DecodeUTF8 (unicodeobject.c:2065)
==2058==    by 0x42C8F7: PyUnicodeUCS2_FromStringAndSize (unicodeobject.c:541)
==2058==    by 0x42C973: PyUnicodeUCS2_FromString (unicodeobject.c:559)
==2058==    by 0x50B432: PyDict_SetItemString (dictobject.c:2088)
==2058==    by 0x4258DF: PyType_Ready (typeobject.c:3844)
==2058==    by 0x517B64: PyStructSequence_InitType (structseq.c:522)
==2058==    by 0x4F3B4F: _PyFloat_Init (floatobject.c:1905)
==2058==    by 0x4813CE: Py_InitializeEx (pythonrun.c:217)

----------
components: Interpreter Core
messages: 119226
nosy: mark.dickinson, skrah
priority: normal
severity: normal
status: open
title: Memory leak (r70459)
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Wed Oct 20 19:33:22 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 17:33:22 +0000
Subject: [issue10157] Memory leak (r70152)
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>


New submission from Stefan Krah <stefan-usenet at bytereef.org>:

This is one of two remaining "definitely lost" leaks in py3k. It first
appeared in r70152. How to reproduce:

make distclean && ./configure OPT="-O0 -g" --without-pymalloc && make

valgrind --leak-check=full --suppressions=Misc/valgrind-python.supp ./python > VGOUT 2>&1

Then search for 'definitely'. This leak is not present in release-2.7.


==25233== 106 (56 direct, 50 indirect) bytes in 1 blocks are definitely lost in loss record 1,432 of 2,121
==25233==    at 0x4C2412C: malloc (vg_replace_malloc.c:195)
==25233==    by 0x4167AE: _PyObject_New (object.c:243)
==25233==    by 0x42C1C4: _PyUnicode_New (unicodeobject.c:341)
==25233==    by 0x430562: PyUnicodeUCS2_DecodeUTF8Stateful (unicodeobject.c:2036)
==25233==    by 0x430516: PyUnicodeUCS2_DecodeUTF8 (unicodeobject.c:2001)
==25233==    by 0x479F81: r_object (marshal.c:726)
==25233==    by 0x47A03E: r_object (marshal.c:745)
==25233==    by 0x47A720: r_object (marshal.c:873)
==25233==    by 0x47AF4B: PyMarshal_ReadObjectFromString (marshal.c:1053)
==25233==    by 0x47AE2A: PyMarshal_ReadLastObjectFromFile (marshal.c:1012)
==25233==    by 0x471C5B: read_compiled_module (import.c:823)
==25233==    by 0x47230C: load_source_module (import.c:1043)

----------
assignee: amaury.forgeotdarc
components: Interpreter Core
messages: 119227
nosy: amaury.forgeotdarc, benjamin.peterson, pitrou, skrah
priority: normal
severity: normal
status: open
title: Memory leak (r70152)
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10157>
_______________________________________

From report at bugs.python.org  Wed Oct 20 19:34:29 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 17:34:29 +0000
Subject: [issue10157] Memory leak (r70152)
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1287596069.42.0.19313188541.issue10157@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
assignee: amaury.forgeotdarc -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10157>
_______________________________________

From report at bugs.python.org  Wed Oct 20 19:44:15 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Wed, 20 Oct 2010 17:44:15 +0000
Subject: [issue10121] test_multiprocessing stuck in test_make_pool if run in a
	loop
In-Reply-To: <1287232773.28.0.893033557088.issue10121@psf.upfronthosting.co.za>
Message-ID: <1287596655.03.0.652381974855.issue10121@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

just for the reference, the loop I ran was:

 while date ; do ./python Lib/test/regrtest.py -v test_multiprocessing ; done

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10121>
_______________________________________

From report at bugs.python.org  Wed Oct 20 19:58:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 20 Oct 2010 17:58:31 +0000
Subject: [issue10157] Memory leak (r70152)
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1287597511.66.0.516928181128.issue10157@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10157>
_______________________________________

From report at bugs.python.org  Wed Oct 20 19:58:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 20 Oct 2010 17:58:55 +0000
Subject: [issue10156] Memory leak (r70459)
In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>
Message-ID: <1287597535.04.0.233159458464.issue10156@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Wed Oct 20 20:05:29 2010
From: report at bugs.python.org (Maciek J)
Date: Wed, 20 Oct 2010 18:05:29 +0000
Subject: [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1287597929.66.0.0602225715872.issue10149@psf.upfronthosting.co.za>


Maciek J <egil at wp.pl> added the comment:

Hm... It turns out that there is a "buffer_text" attribute:
http://docs.python.org/library/pyexpat.html#xml.parsers.expat.xmlparser.buffer_text
And setting this attribute to "True" seems to solve the problem.

It solves my problem, but docs are still very confusing. I see two things that should be fixed:
1. In CharacterDataHandler description it should be explicitly noted that data may be chunked even if it is short(!).
2. Description of buffer_text attribute should contain a notice that data may also be arbitrary chunked if this is set to False. My data _was_not_ chunked at new line characters (as the description suggest). It was chunked in the middle of a sentence (there were no whitespace in it!).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10149>
_______________________________________

From report at bugs.python.org  Wed Oct 20 20:45:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 20 Oct 2010 18:45:40 +0000
Subject: [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1287600340.17.0.0198513999935.issue10149@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
assignee:  -> docs at python
components: +Documentation -XML
nosy: +docs at python
stage:  -> needs patch
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10149>
_______________________________________

From report at bugs.python.org  Wed Oct 20 21:37:24 2010
From: report at bugs.python.org (David Watson)
Date: Wed, 20 Oct 2010 19:37:24 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <20101020193714.GA2978@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

I was looking at the MSDN pages linked to above, and these two
pages seemed to suggest that Unicode characters appearing in DNS
names represented UTF-8 sequences, and that Windows allowed such
non-ASCII byte sequences in the DNS by default:

http://msdn.microsoft.com/en-us/library/ms724220%28v=VS.85%29.aspx
http://msdn.microsoft.com/en-us/library/ms682032%28v=VS.85%29.aspx

(See the discussion of DNS_ERROR_NON_RFC_NAME in the latter.)
Can anyone confirm if this is the case?

The BSD-style gethostname() function can't be returning UTF-8,
though, or else the "N?tk?tti" example above would have been
decoded successfully, given that Python currently uses
PyUnicode_FromString().

Also, if GetComputerNameEx() only offers a choice of DNS names or
NetBIOS names, and both are byte-oriented underneath (that was my
reading of the "Computer Names" page), then presumably there
shouldn't be a problem with mapping the result to a bytes
equivalent when necessary?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Wed Oct 20 21:49:50 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Wed, 20 Oct 2010 19:49:50 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <20101020193714.GA2978@dbwatson.ukfsn.org>
Message-ID: <4CBF47DB.9080202@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Also, if GetComputerNameEx() only offers a choice of DNS names or
> NetBIOS names, and both are byte-oriented underneath (that was my
> reading of the "Computer Names" page), then presumably there
> shouldn't be a problem with mapping the result to a bytes
> equivalent when necessary?

They aren't byte-oriented underneath.It depends on whether use
GetComputerNameA or GetComputerNameW whether you get bytes or Unicode.
If bytes, they are converted as if by WideCharToMultiByte using
CP_ACP, which in turn will introduce question marks and the like
for unconvertable characters.

----------
title: socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Wed Oct 20 21:57:25 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Wed, 20 Oct 2010 19:57:25 +0000
Subject: [issue1467929] %-formatting and dicts
Message-ID: <1287604645.99.0.510378425833.issue1467929@psf.upfronthosting.co.za>


Changes by Vetoshkin Nikita <nikita.vetoshkin at gmail.com>:


Removed file: http://bugs.python.org/file19271/issue1467929_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1467929>
_______________________________________

From report at bugs.python.org  Wed Oct 20 21:57:56 2010
From: report at bugs.python.org (Vetoshkin Nikita)
Date: Wed, 20 Oct 2010 19:57:56 +0000
Subject: [issue1467929] %-formatting and dicts
Message-ID: <1287604676.54.0.59210547918.issue1467929@psf.upfronthosting.co.za>


Vetoshkin Nikita <nikita.vetoshkin at gmail.com> added the comment:

Updated patch: some tests added.

----------
Added file: http://bugs.python.org/file19307/issue1467929_py3k.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1467929>
_______________________________________

From report at bugs.python.org  Wed Oct 20 22:54:22 2010
From: report at bugs.python.org (Bob Halley)
Date: Wed, 20 Oct 2010 20:54:22 +0000
Subject: [issue10158] BadInternalCall running test_multiprocessing
In-Reply-To: <1287608062.36.0.615501498317.issue10158@psf.upfronthosting.co.za>
Message-ID: <1287608062.36.0.615501498317.issue10158@psf.upfronthosting.co.za>


New submission from Bob Halley <halley at dnspython.org>:

For reasons not germane to this bug report, I was running a modified Python 2.7 where PyTrash_UNWIND_LEVEL in Include/object.h had been defined to 10 instead of 50.

With such a python, running test_multiprocessing causes a BadInternalCall to be triggered at line 903 of weakrefobject.c.

test_finalize (__main__.WithProcessesTestFinalize) ... Process Process-18:
Traceback (most recent call last):
  File "/Users/halley/src/release27-maint/Lib/multiprocessing/process.py", line 229, in _bootstrap
    util._run_after_forkers()
  File "/Users/halley/src/release27-maint/Lib/multiprocessing/util.py", line 125, in _run_after_forkers
    items = list(_afterfork_registry.items())
  File "/Users/halley/src/release27-maint/Lib/weakref.py", line 116, in items
    for key, wr in self.data.items():
SystemError: Objects/weakrefobject.c:903: bad argument to internal function

I'm running the head of the release27-maint branch, but the problem occurs with the released 2.7 too.

The trigger for the error is that object->ob_refcount is 1.

I stuck an abort() into the code just before the BadInternalCall, and looked at the core.  The ob_type is a Semaphore, and the last bit of the call chain is:

(gdb) bt
#0  0x00007fff8791c3d6 in __kill ()
#1  0x00007fff879bc972 in abort ()
#2  0x000000010007eb05 in PyObject_ClearWeakRefs (object=<value temporarily unavailable, due to optimizations>) at Objects/weakrefobject.c:903
#3  0x000000010006c949 in subtype_dealloc (self=0x10070a150) at Objects/typeobject.c:952
#4  0x000000010005341b in _PyTrash_destroy_chain () at Objects/object.c:2435
#5  0x000000010003bfaf in listiter_next (it=0x1006db8d0) at Objects/listobject.c:2917
#6  0x00000001000b9f16 in PyEval_EvalFrameEx (f=0x1013b91a0, throwflag=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:2496
#7  0x00000001000c0966 in PyEval_EvalFrameEx (f=0x1013bcc40, throwflag=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:4098
#8  0x00000001000c0966 in PyEval_EvalFrameEx (f=0x10137a500, throwflag=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:4098
#9  0x00000001000c0966 in PyEval_EvalFrameEx (f=0x101374aa0, throwflag=<value temporarily unavailable, due to optimizations>) at Python/ceval.c:4098
#10 0x00000001000c1826 in PyEval_EvalCodeEx (co=0x10065d1b0, globals=<value temporarily unavailable, due to optimizations>, locals=<value temporarily unavailable, due to optimizations>, args=0x100708458, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
#11 0x0000000100037580 in function_call (func=0x100678488, arg=0x100708440, kw=0x0) at Objects/funcobject.c:526
#12 0x00000001000063e2 in PyObject_Call (func=0x100678488, arg=0x100708440, kw=0x0) at Objects/abstract.c:2529
#13 0x00000001000177bd in instancemethod_call (func=0x100678488, arg=0x100708440, kw=0x0) at Objects/classobject.c:2578
#14 0x00000001000063e2 in PyObject_Call (func=0x100704780, arg=0x1006f17d0, kw=0x0) at Objects/abstract.c:2529
#15 0x0000000100071a38 in slot_tp_init (self=<value temporarily unavailable, due to optimizations>, args=0x1006f17d0, kwds=0x0) at Objects/typeobject.c:5651
#16 0x000000010006ee75 in type_call (type=0x10130bd10, args=0x1006f17d0, kwds=0x0) at Objects/typeobject.c:726
#17 0x00000001000063e2 in PyObject_Call (func=0x10130bd10, arg=0x1006f17d0, kw=0x0) at Objects/abstract.c:2529

Note that the trashcan function _PyTrash_destroy_chain() is involved.

I don't understand this code well enough to have figured out what's going wrong yet.  I worry that there's some subtle interaction with weakrefs, subtyped objects, and the trashcan, but maybe it's something simpler!

Regards,

/Bob

----------
components: Interpreter Core
messages: 119233
nosy: rthalley
priority: normal
severity: normal
status: open
title: BadInternalCall running test_multiprocessing
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10158>
_______________________________________

From report at bugs.python.org  Wed Oct 20 23:14:46 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 21:14:46 +0000
Subject: [issue10157] Memory leak (r70152)
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1287609286.27.0.863998148917.issue10157@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I tracked it down to r68683, which is still a large commit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10157>
_______________________________________

From report at bugs.python.org  Wed Oct 20 23:25:40 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Oct 2010 21:25:40 +0000
Subject: [issue10152] symtable.c: ste_tmpname uninitialized
In-Reply-To: <1287571673.13.0.775838367643.issue10152@psf.upfronthosting.co.za>
Message-ID: <1287609940.59.0.402612454616.issue10152@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85757

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10152>
_______________________________________

From report at bugs.python.org  Wed Oct 20 23:35:25 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Oct 2010 21:35:25 +0000
Subject: [issue10158] BadInternalCall running test_multiprocessing
In-Reply-To: <1287608062.36.0.615501498317.issue10158@psf.upfronthosting.co.za>
Message-ID: <1287610525.27.0.405415268168.issue10158@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> jnoller
nosy: +jnoller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10158>
_______________________________________

From report at bugs.python.org  Wed Oct 20 23:47:46 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Oct 2010 21:47:46 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <A0153B5D-DEEC-4B14-8F88-34CB7A1E604F@mac.com>
Message-ID: <4CBF637A.3000204@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
> 
> This patch solves the immediate failure:
> 
> Index: Lib/locale.py
> ===================================================================
> --- Lib/locale.py	(revision 85743)
> +++ Lib/locale.py	(working copy)
> @@ -396,6 +396,9 @@
>          else:
>              encoding = defenc
>          #print 'found encoding %r' % encoding
> +        if sys.platform == 'darwin' and encoding == 'UTF8':
> +            encoding = 'UTF-8'
> +
>          if encoding:
>              return langname + '.' + encoding
>          else:
> 
> I'm not happy about hardcoding this specific exception though, there should be a better solution than this.

Could you tell me the values of localename, code, langname and encoding
at that step in the process ?

We may need to add an locale_encoding_alias from 'UTF8' to 'UTF-8',
since the version with the hyphen is what the C lib uses.

----------
nosy: +lemburg
title: locale.normalize strips "-" from UTF-8, which fails on Mac -> locale.normalize strips "-" from UTF-8,	which fails on Mac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Thu Oct 21 00:10:04 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Oct 2010 22:10:04 +0000
Subject: [issue10156] Memory leak (r70459)
In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>
Message-ID: <1287612604.11.0.028769880869.issue10156@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The stack corresponds to the allocation of type(sys.float_info).__doc__.

Why would only this object appear as a memory leak?  It is certainly not deallocated, but all other types are in the same situation.
For example, sys.int_info is very similar, and happens to be defined in r70459. Why doesn't it appear in the report?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Thu Oct 21 00:24:44 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 22:24:44 +0000
Subject: [issue10156] Memory leak (r70459)
In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>
Message-ID: <1287613484.67.0.0667865614901.issue10156@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

To add to the mystery, the leak disappears if the key value is not
interned in PyDict_SetItemString:


Index: Objects/dictobject.c
===================================================================
--- Objects/dictobject.c        (revision 70459)
+++ Objects/dictobject.c        (working copy)
@@ -2088,7 +2088,6 @@
        kv = PyUnicode_FromString(key);
        if (kv == NULL)
                return -1;
-       PyUnicode_InternInPlace(&kv); /* XXX Should we really? */
        err = PyDict_SetItem(v, kv, item);
        Py_DECREF(kv);
        return err;

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Thu Oct 21 00:29:41 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 20 Oct 2010 22:29:41 +0000
Subject: [issue10156] Memory leak (r70459)
In-Reply-To: <1287613484.67.0.0667865614901.issue10156@psf.upfronthosting.co.za>
Message-ID: <4CBF6D43.8060508@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stefan Krah wrote:
> 
> Stefan Krah <stefan-usenet at bytereef.org> added the comment:
> 
> To add to the mystery, the leak disappears if the key value is not
> interned in PyDict_SetItemString:

I'm not sure how you determine what is a leak and what not.
Interned Unicode objects stay alive until the interpreter
is finalized.

Are you suggesting that the finalization does not free the
interned Unicode strings or not all of them ?

> Index: Objects/dictobject.c
> ===================================================================
> --- Objects/dictobject.c        (revision 70459)
> +++ Objects/dictobject.c        (working copy)
> @@ -2088,7 +2088,6 @@
>         kv = PyUnicode_FromString(key);
>         if (kv == NULL)
>                 return -1;
> -       PyUnicode_InternInPlace(&kv); /* XXX Should we really? */
>         err = PyDict_SetItem(v, kv, item);
>         Py_DECREF(kv);
>         return err;

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Thu Oct 21 00:40:14 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Wed, 20 Oct 2010 22:40:14 +0000
Subject: [issue10159] rlcompleter's tests depend on dict order
In-Reply-To: <1287614414.29.0.153122456911.issue10159@psf.upfronthosting.co.za>
Message-ID: <1287614414.29.0.153122456911.issue10159@psf.upfronthosting.co.za>


New submission from Andreas St?hrk <andy-python at hammerhartes.de>:

Some tests in test_rlcompleter make assumptions about the order of the list of names that the completion methods of a Completer object return. That order is not guaranteed and will break when running the tests under e.g. PyPy.

The attached patch against py3k branch tries to fix that.

----------
components: Tests
files: test_rlcompleter_order.patch
keywords: patch
messages: 119240
nosy: Trundle
priority: normal
severity: normal
status: open
title: rlcompleter's tests depend on dict order
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19308/test_rlcompleter_order.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10159>
_______________________________________

From report at bugs.python.org  Thu Oct 21 00:47:17 2010
From: report at bugs.python.org (Stefan Krah)
Date: Wed, 20 Oct 2010 22:47:17 +0000
Subject: [issue10156] Memory leak (r70459)
In-Reply-To: <4CBF6D43.8060508@egenix.com>
Message-ID: <20101020224559.GA19660@yoda.bytereef.org>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Marc-Andre Lemburg <report at bugs.python.org> wrote:
> I'm not sure how you determine what is a leak and what not.
> Interned Unicode objects stay alive until the interpreter
> is finalized.
> 
> Are you suggesting that the finalization does not free the
> interned Unicode strings or not all of them ?

No, Valgrind's "definitely lost" category means that all pointers
to an allocated region have been lost, so it would not be possible
to free the area. [1]

There are hundreds of "possibly lost" warnings as well, but I did
not report those.

My experience is that Valgrind is usually correct with "definitely
lost", see e.g. #10153. That said, of course it _could_ be a false
alarm.

[1] Last category from:

   http://mail.python.org/pipermail/python-dev/2002-October/029758.html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Thu Oct 21 01:08:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Oct 2010 23:08:58 +0000
Subject: [issue4388] test_cmd_line fails on MacOS X
In-Reply-To: <1227329681.44.0.462897262909.issue4388@psf.upfronthosting.co.za>
Message-ID: <1287616138.88.0.533280395131.issue4388@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I commited my patch to Python 3.2 (r85765), with a specific test in test_cmd_line. Reopen the issue if the bug is not fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4388>
_______________________________________

From report at bugs.python.org  Thu Oct 21 01:34:53 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Oct 2010 23:34:53 +0000
Subject: [issue10159] rlcompleter's tests depend on dict order
In-Reply-To: <1287614414.29.0.153122456911.issue10159@psf.upfronthosting.co.za>
Message-ID: <1287617693.97.0.430470578607.issue10159@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The patch looks good to me.

----------
nosy: +ned.deily, pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10159>
_______________________________________

From report at bugs.python.org  Thu Oct 21 01:36:11 2010
From: report at bugs.python.org (And Clover)
Date: Wed, 20 Oct 2010 23:36:11 +0000
Subject: [issue10155] Add fixups for encoding problems to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1287617771.85.0.376907852165.issue10155@psf.upfronthosting.co.za>


And Clover <and at doxdesk.com> added the comment:

(same again for branch PJ Eby's wsgiref svn: same as previous 2.7 patch aside from the line numbers)

----------
Added file: http://bugs.python.org/file19309/wsgiref-patches-eby2692.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10155>
_______________________________________

From report at bugs.python.org  Thu Oct 21 01:42:58 2010
From: report at bugs.python.org (David Watson)
Date: Wed, 20 Oct 2010 23:42:58 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <4CBF47DB.9080202@v.loewis.de>
Message-ID: <20101020234248.GA4405@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

> > Also, if GetComputerNameEx() only offers a choice of DNS names or
> > NetBIOS names, and both are byte-oriented underneath (that was my
> > reading of the "Computer Names" page), then presumably there
> > shouldn't be a problem with mapping the result to a bytes
> > equivalent when necessary?
> 
> They aren't byte-oriented underneath.It depends on whether use
> GetComputerNameA or GetComputerNameW whether you get bytes or Unicode.
> If bytes, they are converted as if by WideCharToMultiByte using
> CP_ACP, which in turn will introduce question marks and the like
> for unconvertable characters.

Sorry, I didn't mean how Windows constructs the result for the
"A" interface - I was talking about Python code being able to map
the result from the Unicode interface to the form used in the
protocol (e.g. DNS).  I believe the proposal is to use the DNS
name, so since the DNS is byte oriented, I would have thought
that the Unicode "DNS name" result would always have a bytes
equivalent that the DNS resolver code would use - perhaps its
UTF-8 encoding?

----------
title: socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Thu Oct 21 01:51:10 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 20 Oct 2010 23:51:10 +0000
Subject: [issue10158] BadInternalCall running test_multiprocessing
In-Reply-To: <1287608062.36.0.615501498317.issue10158@psf.upfronthosting.co.za>
Message-ID: <1287618670.35.0.86611880515.issue10158@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Does it happen when compiled in debug mode? There may be asserts that will give a better (or earlier) error message.

Some thoughts: the '_PyTrash_delete_later' chain can only contain a limited set of objects: lists, frames... (which code contain the Py_TRASHCAN_SAFE_BEGIN macro)... and the stack dumps suggests (subtype_dealloc) that it is also an instance of a user-defined class.  The only candidate I see is the class 'multiprocessing.managers.ProcessLocalSet', which inherits from 'set'.

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10158>
_______________________________________

From report at bugs.python.org  Thu Oct 21 01:56:24 2010
From: report at bugs.python.org (Ned Deily)
Date: Wed, 20 Oct 2010 23:56:24 +0000
Subject: [issue10155] Add fixups for encoding problems to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1287618984.71.0.261734084083.issue10155@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +pje

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10155>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:10:21 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Thu, 21 Oct 2010 00:10:21 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>


New submission from ??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net>:

(Discovered in that StackOverflow answer: http://stackoverflow.com/questions/3940518/3942509#3942509 ; check the comments too)

operator.attrgetter in its simplest form (i.e. with a single non-dotted name) needs more time to execute than an equivalent lambda expression.

Attached file so3940518.py runs a simple benchmark comparing: a list comprehension of plain attribute access; attrgetter; and lambda. I will append sample benchmark times at the end of the comment.

Browsing Modules/operator.c, I noticed that the dotted_getattr function was using PyUnicode_Check and (possibly) splitting on dots on *every* call of the attrgetter, which I thought to be most inefficient.

I changed the py3k-daily-snapshot source to make the PyUnicode_Check calls in the attrgetter_new function; also, I modified the algorithm to pre-parse the operator.attrgetter functions for possible dots in the names, in order for the dotted_getattr function to become speedier.

The only ?drawback? is that now operator.attrgetter raises a TypeError on creation, not on subsequent calls of the attrgetter object; this shouldn't be a compatibility problem. However, I obviously had to update both Doc/library/operator.rst and Lib/test/test_operator.py .

I am not sure whether I should attach a zip/tar file with both the attachments (the sample benchmark and the diff); so I'll attach the diff in a further comment.

On the Ubuntu server 9.10 where I made the changes, I ran the so3940518.py sample benchmark before and after the changes.

Run before the changes (third column is seconds, less is better):

list comp 0.40999999999999925 1000000
map attrgetter 1.3899999999999997 1000000
map lambda 1.0099999999999998 1000000

Run after the changes:

list comp 0.40000000000000036 1000000
map attrgetter 0.5199999999999996 1000000
map lambda 0.96 1000000

----------
assignee: docs at python
components: Documentation, Library (Lib), Tests
files: so3940518.py
messages: 119247
nosy: docs at python, tzot
priority: normal
severity: normal
status: open
title: operator.attrgetter slower than lambda after adding dotted names ability
versions: Python 3.2
Added file: http://bugs.python.org/file19310/so3940518.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:14:05 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Oct 2010 00:14:05 +0000
Subject: [issue10161] unittest: use ascii() instead of repr() to display
	values on error
In-Reply-To: <1287620045.08.0.616475344874.issue10161@psf.upfronthosting.co.za>
Message-ID: <1287620045.08.0.616475344874.issue10161@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

On a failure, unittest does its best to display values. But sometimes, the output doesn't help me. Example:

FAIL: test_listdir (test.test_pep277.UnicodeFileTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_pep277.py", line 157, in test_listdir
    self.assertEqual(sf0, sf2)
AssertionError: Items in the first set but not the second:
'@test_18608_tmp/ ????????????'
'@test_18608_tmp/??????????????????????????????????????????'
Items in the second set but not the first:
'@test_18608_tmp/ ????????????'
'@test_18608_tmp/??????????????????????????????????????????'
'@test_18608_tmp/????????????'

This is a test on unicode filenames. I would prefer to see non-ASCII characters as \xHH or \uXXXX than strange characters or boxes.

Do you think that it is a good idea to replace calls to repr() by ascii() in the unittest library?

In Python2, repr(unicode) escapes all non-ASCII characters. But in Python3, only control characters and surrogates are escaped. So the output depends on the terminal encoding.

Write non-ASCII characters in a backtrace may also raise a new error if the terminal is unable to a character. Raise an error while printing an error is just horrible :-)

--

Attached patch is a try to replace repr() by ascii() in the unittest module. But I don't know this library, so don't trust the patch :-)

----------
components: Library (Lib), Unicode
files: unittest_ascii.patch
keywords: patch
messages: 119248
nosy: haypo
priority: normal
severity: normal
status: open
title: unittest: use ascii() instead of repr() to display values on error
versions: Python 3.2
Added file: http://bugs.python.org/file19311/unittest_ascii.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10161>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:22:39 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Thu, 21 Oct 2010 00:22:39 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287620559.26.0.228445009836.issue10160@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

Here comes the diff to Modules/operator.c, Doc/library/operator.rst and Lib/test/test_operator.py . As far as I could check, there are no leaks, but a more experienced eye in core development could not hurt. Also, obviously test_operatory.py passes all tests.

Should this be accepted, I believe it should be backported to 2.7 (at least). I can do that, just let me know.

----------
keywords: +patch
Added file: http://bugs.python.org/file19312/issue10160.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:22:55 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Oct 2010 00:22:55 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287620575.44.0.891571883745.issue10160@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee: docs at python -> rhettinger
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:27:33 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Thu, 21 Oct 2010 00:27:33 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287620853.99.0.50107479976.issue10160@psf.upfronthosting.co.za>


Changes by ??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net>:


Removed file: http://bugs.python.org/file19312/issue10160.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:28:48 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Thu, 21 Oct 2010 00:28:48 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287620928.13.0.470488767783.issue10160@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

Newer version of the diff, since I forgot some "if(0) fprintf" debug calls that shouldn't be there.

----------
Added file: http://bugs.python.org/file19313/issue10160.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:40:53 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Thu, 21 Oct 2010 00:40:53 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287621653.02.0.326065744057.issue10160@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

An explanation to the changes.

The old code kept the operator.itemgetter arguments in the ag->attr member. If the argument count (ag->nattrs) was 1, the single argument was kept; if more than 1, a tuple of the original arguments was kept.

On every attrgetter_call call, if ag->nattrs was 1, dotted_getattr was called with the plain ag->attr as attribute name; if > 2, dotted_getattr was called for every one of the original arguments.

Now, ag->attr is always a tuple, containing either dotless strings or tuples of dotless strings:

operator.attrgetter("name1", "name2.name3", "name4")

stores ("name1", ("name2", "name3"), "name4") in ag->attr.

dotted_getattr accordingly chooses based on type (either str or tuple, ensured by attrgetter_new) whether to do a single access or a recursive one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:42:58 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Oct 2010 00:42:58 +0000
Subject: [issue7828] chr() and ord() documentation for wide characters
In-Reply-To: <1264999918.27.0.407460194608.issue7828@psf.upfronthosting.co.za>
Message-ID: <1287621778.83.0.773395081548.issue7828@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
components: +Unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7828>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:44:37 2010
From: report at bugs.python.org (And Clover)
Date: Thu, 21 Oct 2010 00:44:37 +0000
Subject: [issue10162] mimetypes read_windows_registry should tolerate
	permissions errors
In-Reply-To: <1287621877.59.0.625449070173.issue10162@psf.upfronthosting.co.za>
Message-ID: <1287621877.59.0.625449070173.issue10162@psf.upfronthosting.co.za>


New submission from And Clover <and at doxdesk.com>:

It is relatively common to have keys in the HKEY_CLASSES_ROOT MIME database that are not readable to all users, typically written by third-party applications. (My WinXP test box has a dozen, for apps like Flash, Silverlight and Java.)

Currently, initialising mimetypes causes Python to try to read them all, and if the user running Python doesn't have permission to read a key (in particular, if the user is a low-privilege daemon user such as IUSR_...), the script that caused mimetypes to be called will error out.

This patch moves the try-block around the call to OpenKey as well as QueryValueEx, allowing the key to be skipped if unreadable.

----------
components: Library (Lib)
files: mimetypes-patch-3.2a3.patch
keywords: patch
messages: 119252
nosy: aclover
priority: normal
severity: normal
status: open
title: mimetypes read_windows_registry should tolerate permissions errors
type: feature request
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file19314/mimetypes-patch-3.2a3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10162>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:45:51 2010
From: report at bugs.python.org (And Clover)
Date: Thu, 21 Oct 2010 00:45:51 +0000
Subject: [issue10162] mimetypes read_windows_registry should tolerate
	permissions errors
In-Reply-To: <1287621877.59.0.625449070173.issue10162@psf.upfronthosting.co.za>
Message-ID: <1287621951.37.0.468044968958.issue10162@psf.upfronthosting.co.za>


And Clover <and at doxdesk.com> added the comment:

(same against 2.7 branch)

----------
Added file: http://bugs.python.org/file19315/mimetypes-patch-2.7.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10162>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:54:29 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Oct 2010 00:54:29 +0000
Subject: [issue9167] argv double encoding on OSX
In-Reply-To: <1278346074.17.0.914375109611.issue9167@psf.upfronthosting.co.za>
Message-ID: <1287622469.76.0.810548735974.issue9167@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I just closed #4388 with r85765 (Python 3.2): always use UTF-8 to decode the command line arguments on Mac OS X, not the locale encoding.

I suppose that it does fix this issue. Can someone check that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9167>
_______________________________________

From report at bugs.python.org  Thu Oct 21 02:58:22 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 21 Oct 2010 00:58:22 +0000
Subject: [issue8776] Bytes version of sys.argv
In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
Message-ID: <1287622702.09.0.494128511609.issue8776@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Since r85765 (issue #4388), always use UTF-8 to decode the command line arguments on Mac OS X, not the locale encoding. Which means that the pseudo-code becomes:

 if os.name != 'nt':
     if sys.platform == 'darwin':
        encoding = 'utf-8'
     else:
        encoding = locale.getpreferredencoding()
     sys.argvb = [arg.decode(encoding, 'surrogateescape') for arg in sys.argv]

sys.argvb should be synchronized with sys.argv, as os.environb with os.environ.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8776>
_______________________________________

From report at bugs.python.org  Thu Oct 21 03:16:58 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Oct 2010 01:16:58 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1287623818.61.0.850482485643.issue10142@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Jes?s, can you attach a patch (with the appropriate #ifdefs)?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Thu Oct 21 03:43:29 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 21 Oct 2010 01:43:29 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <AANLkTinsqN94+=7PpyM7_UOyL6cFJoZUhpywTYJDdKhe@mail.gmail.com>
Message-ID: <AANLkTikRL89GavNsfjShFSdEna4e7E2WHTOF1HMbnAcR@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Please respond...

On Wed, Oct 20, 2010 at 7:05 PM, Bo??tjan Mejak <report at bugs.python.org>wrote:

>
> Bo????tjan Mejak <bostjan.mejak at gmail.com> added the comment:
>
> Thank you so much for your answer. The
> locale.setlocale(category=locale.LC_NUMERIC,
> locale="Slovenian")  works like a charm in my application. Now the 'n'
> format specifier works as I want. But tell me whether the 'n' format
> specifier can be forced to round the float to just one decimal place. I
> know
> that the 'f' format specifier does that by specifying ".1f", but 'f' is not
> locale-aware. I have set the 'n' format specifier in my application like
> ".3n", which is okay if the returned number is two integers and one
> decimal,
> but is not okay if the returned number is one integer and two decimals,
> because I want just one decimal, always. How can I make that by using the
> 'n' format specifier?
>
> On Wed, Oct 20, 2010 at 11:37 AM, Tim Golden <report at bugs.python.org>
> wrote:
>
> >
> > Tim Golden <mail at timgolden.me.uk> added the comment:
> >
> > Bo????tjan, the code segment you quote is the *fallback* if the
> > C module hasn't been built for some reason. The module simply
> > calls through to the underlying C Library. I notice you're
> > running on Windows, so this is a useful MS page:
> >
> > http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx
> >
> > and you can see there that a call of setlocale (LC_ALL, "English")
> > is valid (of "French" if you prefer):
> >
> > Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit
> > (Intel)] on win32
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> import locale
> > >>> locale.setlocale (locale.LC_ALL, "French")
> > 'French_France.1252'
> > >>>
> >
> > ----------
> > nosy: +tim.golden
> >
> > _______________________________________
> > Python tracker <report at bugs.python.org>
> > <http://bugs.python.org/issue10092>
> > _______________________________________
> >
>
> ----------
> Added file: http://bugs.python.org/file19306/unnamed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10092>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19316/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________
-------------- next part --------------
Please respond...<br><br><div class="gmail_quote">On Wed, Oct 20, 2010 at 7:05 PM, Bo??tjan Mejak <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Bo????tjan Mejak &lt;<a href="mailto:bostjan.mejak at gmail.com">bostjan.mejak at gmail.com</a>&gt; added the comment:<br>
<div class="im"><br>
Thank you so much for your answer. The<br>
locale.setlocale(category=locale.LC_NUMERIC,<br>
locale=&quot;Slovenian&quot;) ??works like a charm in my application. Now the &#39;n&#39;<br>
format specifier works as I want. But tell me whether the &#39;n&#39; format<br>
specifier can be forced to round the float to just one decimal place. I know<br>
that the &#39;f&#39; format specifier does that by specifying &quot;.1f&quot;, but &#39;f&#39; is not<br>
locale-aware. I have set the &#39;n&#39; format specifier in my application like<br>
&quot;.3n&quot;, which is okay if the returned number is two integers and one decimal,<br>
but is not okay if the returned number is one integer and two decimals,<br>
because I want just one decimal, always. How can I make that by using the<br>
&#39;n&#39; format specifier?<br>
<br>
On Wed, Oct 20, 2010 at 11:37 AM, Tim Golden &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt; wrote:<br>
<br>
&gt;<br>
</div><div class="im">&gt; Tim Golden &lt;<a href="mailto:mail at timgolden.me.uk">mail at timgolden.me.uk</a>&gt; added the comment:<br>
&gt;<br>
</div>&gt; Bo????tjan, the code segment you quote is the *fallback* if the<br>
<div><div></div><div class="h5">&gt; C module hasn&#39;t been built for some reason. The module simply<br>
&gt; calls through to the underlying C Library. I notice you&#39;re<br>
&gt; running on Windows, so this is a useful MS page:<br>
&gt;<br>
&gt; <a href="http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx" target="_blank">http://msdn.microsoft.com/en-us/library/x99tb11d%28VS.71%29.aspx</a><br>
&gt;<br>
&gt; and you can see there that a call of setlocale (LC_ALL, &quot;English&quot;)<br>
&gt; is valid (of &quot;French&quot; if you prefer):<br>
&gt;<br>
&gt; Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit<br>
&gt; (Intel)] on win32<br>
&gt; Type &quot;help&quot;, &quot;copyright&quot;, &quot;credits&quot; or &quot;license&quot; for more information.<br>
&gt; &gt;&gt;&gt; import locale<br>
&gt; &gt;&gt;&gt; locale.setlocale (locale.LC_ALL, &quot;French&quot;)<br>
&gt; &#39;French_France.1252&#39;<br>
&gt; &gt;&gt;&gt;<br>
&gt;<br>
&gt; ----------<br>
&gt; nosy: +tim.golden<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/issue10092" target="_blank">http://bugs.python.org/issue10092</a>&gt;<br>
&gt; _______________________________________<br>
&gt;<br>
<br>
</div></div>----------<br>
Added file: <a href="http://bugs.python.org/file19306/unnamed" target="_blank">http://bugs.python.org/file19306/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/issue10092" target="_blank">http://bugs.python.org/issue10092</a>&gt;<br>
_______________________________________</div></div></blockquote></div><br>

From report at bugs.python.org  Thu Oct 21 04:04:13 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Oct 2010 02:04:13 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287626653.86.0.185298691453.issue10160@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for noticing this.  I wasn't aware that it had slowed down after dotted name support had been added.

Since it is a mild performance issue, I'm lowering the priority.  Will take a further look when I get the chance.  A first look at the patch shows that it is bigger than I expected.  Isn't it possible to check for a dot on construction and just record the boolean so that a fast, non-splitting path can be used.

I'm reluctant to make the code volume grow much for this function.  It is already a bit voluminous for the minor convenience it offers.

----------
priority: normal -> low
stage:  -> patch review
type:  -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Thu Oct 21 04:33:58 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Oct 2010 02:33:58 +0000
Subject: [issue10158] BadInternalCall running test_multiprocessing
In-Reply-To: <1287608062.36.0.615501498317.issue10158@psf.upfronthosting.co.za>
Message-ID: <1287628438.56.0.349547799675.issue10158@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10158>
_______________________________________

From report at bugs.python.org  Thu Oct 21 04:43:52 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Oct 2010 02:43:52 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <1286999616.97.0.806385422046.issue10092@psf.upfronthosting.co.za>
Message-ID: <1287629032.5.0.970303920983.issue10092@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The bug tracker is not an appropriate place to get help on using Python.  Please ask your question on a forum where you are more likely to get help, such as python-list.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Thu Oct 21 05:57:39 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 21 Oct 2010 03:57: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: <1287633459.31.0.72670487376.issue10155@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/issue10155>
_______________________________________

From report at bugs.python.org  Thu Oct 21 06:03:10 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Thu, 21 Oct 2010 04:03:10 +0000
Subject: [issue9022] TypeError in wsgiref.handlers when using CGIHandler
In-Reply-To: <1276820747.2.0.467969862682.issue9022@psf.upfronthosting.co.za>
Message-ID: <1287633790.45.0.527623298546.issue9022@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/issue9022>
_______________________________________

From report at bugs.python.org  Thu Oct 21 06:34:49 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 Oct 2010 04:34:49 +0000
Subject: [issue10162] mimetypes read_windows_registry should tolerate
	permissions errors
In-Reply-To: <1287621877.59.0.625449070173.issue10162@psf.upfronthosting.co.za>
Message-ID: <1287635689.17.0.946290239478.issue10162@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
components: +Windows
nosy: +brian.curtin, tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10162>
_______________________________________

From report at bugs.python.org  Thu Oct 21 07:09:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 21 Oct 2010 05:09:55 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <20101020234248.GA4405@dbwatson.ukfsn.org>
Message-ID: <4CBFCB1D.3080003@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Sorry, I didn't mean how Windows constructs the result for the
> "A" interface - I was talking about Python code being able to map
> the result from the Unicode interface to the form used in the
> protocol (e.g. DNS).  I believe the proposal is to use the DNS
> name

I disagree with the proposal - it should return whatever
name gethostname from winsock.dll returns (which I expect
to be the netbios name).

> so since the DNS is byte oriented, I would have thought
> that the Unicode "DNS name" result would always have a bytes
> equivalent that the DNS resolver code would use - perhaps its
> UTF-8 encoding?

No no no. When Microsoft calls it the DNS name, they don't actually
mean that it has to do anything with DNS. In particular, it's not
byte-oriented.

----------
title: socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Thu Oct 21 07:33:25 2010
From: report at bugs.python.org (Alex)
Date: Thu, 21 Oct 2010 05:33:25 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287639205.87.0.251173550816.issue10160@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

Voice of ignorance here: why can't this be implemented in the "naive" way one might in Python, use the existing string splitting algorithms of stringlib, but just leave it in __new__.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Thu Oct 21 07:51:16 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 21 Oct 2010 05:51:16 +0000
Subject: [issue9167] argv double encoding on OSX
In-Reply-To: <1278346074.17.0.914375109611.issue9167@psf.upfronthosting.co.za>
Message-ID: <1287640276.63.0.56863859187.issue9167@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

Thank you. I'll check, but probably only sometime next week.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9167>
_______________________________________

From report at bugs.python.org  Thu Oct 21 07:58:40 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 21 Oct 2010 05:58:40 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1287640720.15.0.621582421243.issue4111@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I've the same question as Jes?s Cea Avi?n: what is needed to get this in 3.2?  This would IMHO be a useful feature.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Oct 21 08:56:01 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Thu, 21 Oct 2010 06:56:01 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287644161.72.0.406199879747.issue10160@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

Modules/operator.c grows by ~70 lines, most of it the setup code for ag->attr; also I loop twice over the args of attrgetter_new, choosing fast code that runs once per attrgetter creation than temporary data.

Alex's suggestion to make use of Python-level functions to shorten the code of attrgetter_new could obviously work to decrease the source lines. I don't know how fast I would produce such a version if requested, though.

Whatever the way attrgetter_new sets up the data, I would suggest that you keep the logic changes in general, i.e. set-up in attrgetter_new and keep a thinner dotted_getattr , since it avoids running the same checks and splitting over and over again for every attrgetter_call invocation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Thu Oct 21 09:10:18 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Thu, 21 Oct 2010 07:10:18 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287645018.82.0.392760191322.issue9778@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I've attached a patch that fixes hashing for numerical types, sys.hash_info is now correct, fixes typeobject.c/wrap_hashfunc and tupleobject.c/tuplehash to use Py_ssize_t instead of long, and uses Py_ssize_t instead of Py_hash_t.

I think it is clearer to use Py_ssize_t instead of Py_hash_t. I found two occurances where PyLong_FromLong needed to be replaced by PyLong_FromSsize_t and I think bugs like that would be easier to catch if Py_ssize_t is used.

----------
Added file: http://bugs.python.org/file19317/py_ssize_t_hash_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Thu Oct 21 09:40:17 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 07:40:17 +0000
Subject: [issue10159] rlcompleter's tests depend on dict order
In-Reply-To: <1287614414.29.0.153122456911.issue10159@psf.upfronthosting.co.za>
Message-ID: <1287646817.91.0.429521285554.issue10159@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied in r85766. Thanks!

----------
nosy: +georg.brandl
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10159>
_______________________________________

From report at bugs.python.org  Thu Oct 21 09:46:04 2010
From: report at bugs.python.org (Tim Golden)
Date: Thu, 21 Oct 2010 07:46:04 +0000
Subject: [issue10162] mimetypes read_windows_registry should tolerate
	permissions errors
In-Reply-To: <1287635690.63.0.970884247819.issue10162@psf.upfronthosting.co.za>
Message-ID: <4CBFEFA9.8070108@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

I've only read the patch and not applied it, yet. But in principle I'm 
+1 on this. If Brian doesn't get there first, I'll try to apply later.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10162>
_______________________________________

From report at bugs.python.org  Thu Oct 21 09:46:54 2010
From: report at bugs.python.org (Tim Golden)
Date: Thu, 21 Oct 2010 07:46:54 +0000
Subject: [issue10092] calendar does not restore locale properly
In-Reply-To: <AANLkTinsqN94+=7PpyM7_UOyL6cFJoZUhpywTYJDdKhe@mail.gmail.com>
Message-ID: <4CBFEFE9.9030901@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

I'm afraid this falls outside my particular area of knowledge, and also 
outside the remit of the bug tracker. Perhaps you could post to 
python-list to see if anyone there can help?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10092>
_______________________________________

From report at bugs.python.org  Thu Oct 21 11:08:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Oct 2010 09:08:24 +0000
Subject: [issue10157] Memory leak (r70152)
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1287652104.16.0.128116738211.issue10157@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Your traceback suggests it's a string allocated when reading a module file...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10157>
_______________________________________

From report at bugs.python.org  Thu Oct 21 11:15:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Oct 2010 09:15:31 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1287652531.97.0.962626904482.issue4111@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I've the same question as Jes?s Cea Avi?n: what is needed to get this
> in 3.2?

Same as usual: someone to review, apply, commit. Why do you ask?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Thu Oct 21 11:24:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Oct 2010 09:24:47 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <4CBFCB1D.3080003@v.loewis.de>
Message-ID: <4CC006D9.5030305@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:
> 
>> Sorry, I didn't mean how Windows constructs the result for the
>> "A" interface - I was talking about Python code being able to map
>> the result from the Unicode interface to the form used in the
>> protocol (e.g. DNS).  I believe the proposal is to use the DNS
>> name
> 
> I disagree with the proposal - it should return whatever
> name gethostname from winsock.dll returns (which I expect
> to be the netbios name).
> 
>> so since the DNS is byte oriented, I would have thought
>> that the Unicode "DNS name" result would always have a bytes
>> equivalent that the DNS resolver code would use - perhaps its
>> UTF-8 encoding?
> 
> No no no. When Microsoft calls it the DNS name, they don't actually
> mean that it has to do anything with DNS. In particular, it's not
> byte-oriented.

Just to clarify: I was proposing to use the
GetComputerNameExW() win32 API with ComputerNamePhysicalDnsHostname,
which returns Unicode without needing any roundtrip via bytes
and the issues associated with this.

I don't understand why Martin insists that the MS "DNS name"
doesn't have anything to with DNS... the fully qualified
DNS name of a machine is determined as hostname.domainname,
just like you would expect in DNS.

http://msdn.microsoft.com/en-us/library/ms724301(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/ms724224(v=VS.85).aspx

As I said earlier: NetBIOS is being phased out in favor of
DNS. MS is using a convention which mandates that NetBIOS names
match DNS names. The only difference between the two is that
NetBIOS names have a length limitation:

http://msdn.microsoft.com/en-us/library/ms724931(v=VS.85).aspx

Perhaps Martin could clarify why he insists on using the
ANSI WinSock interface gethostname instead.

PS: WinSock provides many other Unicode APIs for socket
module interfaces as well, so at least for that platform,
we could use those to resolve uncertainties about the
encoding used in name resolution.

On other platforms, I guess we'll just have to do some trial
and error to see what works and what not. E.g. on Linux it is
possible to set the hostname to a non-ASCII value, but then
the resolver returns an error, so it's not very practical:

# hostname l\303\266wis
# hostname
l?wis
# hostname -f
hostname: Resolver Error 0 (no error)

Using the IDNA version doesn't help either:

# hostname xn--lwis-5qa
# hostname
xn--lwis-5qa
# hostname -f
hostname: Resolver Error 0 (no error)

Python2 happily returns the host name, but fails to return
a fully qualified domain name:

'l\xc3\xb6wis'
>>> socket.getfqdn()
'l\xc3\xb6wis'

and

'xn--lwis-5qa'
>>> socket.getfqdn()
'xn--lwis-5qa'

Just for comparison:

# hostname newton
# hostname
newton
# hostname -f
newton.egenix.internal

and

'newton'
>>> socket.getfqdn()
'newton.egenix.internal'

So at least on Linux, using non-ASCII hostnames doesn't really
appear to be an option at this time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Thu Oct 21 12:20:12 2010
From: report at bugs.python.org (Bob Halley)
Date: Thu, 21 Oct 2010 10:20:12 +0000
Subject: [issue10158] BadInternalCall running test_multiprocessing
In-Reply-To: <1287608062.36.0.615501498317.issue10158@psf.upfronthosting.co.za>
Message-ID: <1287656412.09.0.515912002154.issue10158@psf.upfronthosting.co.za>


Bob Halley <halley at dnspython.org> added the comment:

I rebuilt using --with-pydebug and -O0 -g.  It now triggers an assertion a bit earlier.

test_finalize (__main__.WithProcessesTestFinalize) ... Assertion failed: (op->ob_refcnt == 0), function _PyTrash_destroy_chain, file Objects/object.c, line 2433

(gdb) bt
#0  0x00007fff8791c3d6 in __kill ()
#1  0x00007fff879bc972 in abort ()
#2  0x00007fff879a99b4 in __assert_rtn ()
#3  0x00000001000796e0 in _PyTrash_destroy_chain () at Objects/object.c:2433
#4  0x0000000100053efe in list_dealloc (op=0x10114cc18) at Objects/listobject.c:317
#5  0x000000010007905b in _Py_Dealloc (op=0x10114cc18) at Objects/object.c:2228
#6  0x000000010005aee7 in listiter_next (it=0x10160d610) at Objects/listobject.c:2917
#7  0x00000001001158c8 in PyEval_EvalFrameEx (f=0x1014c72c0, throwflag=0) at Python/ceval.c:2496
[ ... snip ... ]

(gdb) f 3
#3  0x00000001000796e0 in _PyTrash_destroy_chain () at Objects/object.c:2433
2433	        assert(op->ob_refcnt == 0);
(gdb) list
2428	         * fool Py_DECREF into calling it indirectly, but
2429	         * Py_DECREF was already called on this object, and in
2430	         * assorted non-release builds calling Py_DECREF again ends
2431	         * up distorting allocation statistics.
2432	         */
2433	        assert(op->ob_refcnt == 0);
2434	        ++_PyTrash_delete_nesting;
2435	        (*dealloc)(op);
2436	        --_PyTrash_delete_nesting;
2437	    }

(gdb) p *op
$2 = {
  _ob_next = 0x0, 
  _ob_prev = 0x0, 
  ob_refcnt = 1, 
  ob_type = 0x101441d70
}

(gdb) p *op->ob_type
$4 = {
  _ob_next = 0x10076d798, 
  _ob_prev = 0x101442930, 
  ob_refcnt = 9, 
  ob_type = 0x1001f84e0, 
  ob_size = 0, 
  tp_name = 0x1013e88b4 "Semaphore", 
  tp_basicsize = 48, 
  tp_itemsize = 0, 
  tp_dealloc = 0x10009dd9d <subtype_dealloc>, 
  tp_print = 0, 
  tp_getattr = 0, 
  tp_setattr = 0, 
  tp_compare = 0, 
  tp_repr = 0x1000af4a0 <slot_tp_repr>, 
  tp_as_number = 0x101441f08, 
  tp_as_sequence = 0x101442058, 
  tp_as_mapping = 0x101442040, 
  tp_hash = 0x1000761bc <_Py_HashPointer>, 
  tp_call = 0, 
  tp_str = 0x1000a44e4 <object_str>, 
  tp_getattro = 0x10007728a <PyObject_GenericGetAttr>, 
  tp_setattro = 0x100077676 <PyObject_GenericSetAttr>, 
  tp_as_buffer = 0x1014420a8, 
  tp_flags = 940027, 
  tp_doc = 0x0, 
  tp_traverse = 0x10009da40 <subtype_traverse>, 
  tp_clear = 0x10009dce5 <subtype_clear>, 
  tp_richcompare = 0, 
  tp_weaklistoffset = 40, 
  tp_iter = 0, 
  tp_iternext = 0x100076c13 <_PyObject_NextNotImplemented>, 
  tp_methods = 0x0, 
  tp_members = 0x1014420e8, 
  tp_getset = 0x0, 
  tp_base = 0x1014499f0, 
  tp_dict = 0x101442930, 
  tp_descr_get = 0, 
  tp_descr_set = 0, 
  tp_dictoffset = 32, 
  tp_init = 0x1000b06dd <slot_tp_init>, 
  tp_alloc = 0x10009d7a7 <PyType_GenericAlloc>, 
  tp_new = 0x1000a3f03 <object_new>, 
  tp_free = 0x10016bda4 <PyObject_GC_Del>, 
  tp_is_gc = 0, 
  tp_bases = 0x1010bc840, 
  tp_mro = 0x100744060, 
  tp_cache = 0x0, 
  tp_subclasses = 0x10074d240, 
  tp_weaklist = 0x10075f528, 
  tp_del = 0, 
  tp_version_tag = 194
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10158>
_______________________________________

From report at bugs.python.org  Thu Oct 21 13:03:54 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 21 Oct 2010 11:03:54 +0000
Subject: [issue10157] Memory leak (r70152)
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1287659034.92.0.306197931924.issue10157@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I also thought that it might be a pointer that's lost in marshal.c.
However, perhaps a pointer is lost in Py_Finalize. With this ...

Index: Modules/main.c
===================================================================
--- Modules/main.c      (revision 85766)
+++ Modules/main.c      (working copy)
@@ -697,6 +697,7 @@
         sts = PyRun_AnyFileFlags(stdin, "<stdin>", &cf) != 0;
     }
 
+    exit(0);
     Py_Finalize();
 
 #ifdef __INSURE__


... Valgrind does not report the leak.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10157>
_______________________________________

From report at bugs.python.org  Thu Oct 21 13:11:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 11:11:20 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287659480.39.0.279433908642.issue10160@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components:  -Documentation
nosy:  -docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Thu Oct 21 13:21:50 2010
From: report at bugs.python.org (Henry Eshbaugh)
Date: Thu, 21 Oct 2010 11:21:50 +0000
Subject: [issue10163] 7/200 and 7%200 show weird results
In-Reply-To: <1287660110.32.0.294845890342.issue10163@psf.upfronthosting.co.za>
Message-ID: <1287660110.32.0.294845890342.issue10163@psf.upfronthosting.co.za>


New submission from Henry Eshbaugh <newts500 at gmail.com>:

This may be happening with other numbers, but I got weird results with the modulus and division operators, after I imported the math module. I tried to do 7/200 and got 0, and 200%7 yielded 7, an impossibility with modulus.

----------
messages: 119274
nosy: Henry.Eshbaugh
priority: normal
severity: normal
status: open
title: 7/200 and 7%200 show weird results

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10163>
_______________________________________

From report at bugs.python.org  Thu Oct 21 13:24:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 11:24:36 +0000
Subject: [issue10163] 7/200 and 7%200 show weird results
In-Reply-To: <1287660110.32.0.294845890342.issue10163@psf.upfronthosting.co.za>
Message-ID: <1287660276.62.0.789596582938.issue10163@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The result of 7 / 200 is easy to explain -- this is how integer division works in Python 2.  (To get a floating result, one of the numbers must be a float.)

200 % 7 giving 7 however is strange.  Are you sure this is what you calculated?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10163>
_______________________________________

From report at bugs.python.org  Thu Oct 21 13:44:19 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 11:44:19 +0000
Subject: [issue10117] Tools/scripts/reindent.py fails on non-UTF-8 encodings
In-Reply-To: <1287161682.26.0.892900314694.issue10117@psf.upfronthosting.co.za>
Message-ID: <1287661459.6.0.690933527263.issue10117@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

When working as a filter, reindent should use sys.{stdin,stdout}.encoding (defaulting to sys.getdefaultencoding()) for reading and writing, respectively.  Detecting encoding on streams is not worth it IMO.  People can set PYTHONIOENCODING for baroque needs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10117>
_______________________________________

From report at bugs.python.org  Thu Oct 21 13:54:33 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Oct 2010 11:54:33 +0000
Subject: [issue1349106] email.Generator does not separate headers with "\r\n"
Message-ID: <1287662073.96.0.354675167617.issue1349106@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Updated patch that adds a missing test for BytesGenerator.flatten and fixes the bugs in it.  Also added versionchanged tags to the docs for the linesep argument.

I think this is ready to go in.

----------
stage: patch review -> commit review
Added file: http://bugs.python.org/file19318/email_linesep.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1349106>
_______________________________________

From report at bugs.python.org  Thu Oct 21 13:54:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Oct 2010 11:54:43 +0000
Subject: [issue1349106] email.Generator does not separate headers with "\r\n"
Message-ID: <1287662083.95.0.557127708025.issue1349106@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file19291/email_linesep.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1349106>
_______________________________________

From report at bugs.python.org  Thu Oct 21 13:59:03 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Oct 2010 11:59:03 +0000
Subject: [issue1349106] email.Generator does not separate headers with "\r\n"
Message-ID: <1287662343.2.0.54699421866.issue1349106@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


Removed file: http://bugs.python.org/file19318/email_linesep.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1349106>
_______________________________________

From report at bugs.python.org  Thu Oct 21 14:00:00 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Oct 2010 12:00:00 +0000
Subject: [issue1349106] email.Generator does not separate headers with "\r\n"
Message-ID: <1287662400.69.0.0949788438263.issue1349106@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Removed some debugging cruft from the latest patch.

----------
Added file: http://bugs.python.org/file19319/email_linesep.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1349106>
_______________________________________

From report at bugs.python.org  Thu Oct 21 14:04:33 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 21 Oct 2010 12:04:33 +0000
Subject: [issue10163] 7/200 and 7%200 show weird results
In-Reply-To: <1287660110.32.0.294845890342.issue10163@psf.upfronthosting.co.za>
Message-ID: <1287662673.98.0.356981235382.issue10163@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Which version of python? Could you run this from the command line and paste the complete session, including the version info that python prints on startup?

----------
nosy: +eric.smith, mark.dickinson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10163>
_______________________________________

From report at bugs.python.org  Thu Oct 21 14:16:57 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 12:16:57 +0000
Subject: [issue10161] unittest: use ascii() instead of repr() to display
	values on error
In-Reply-To: <1287620045.08.0.616475344874.issue10161@psf.upfronthosting.co.za>
Message-ID: <1287663417.26.0.200767853536.issue10161@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10161>
_______________________________________

From report at bugs.python.org  Thu Oct 21 14:20:38 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 12:20:38 +0000
Subject: [issue5017] import suds help( suds ) fails
In-Reply-To: <1232501801.2.0.242744979679.issue5017@psf.upfronthosting.co.za>
Message-ID: <1287663638.63.0.1283800911.issue5017@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
components: +Library (Lib) -Demos and Tools

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5017>
_______________________________________

From report at bugs.python.org  Thu Oct 21 14:48:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Oct 2010 12:48:17 +0000
Subject: [issue10164] Add an assertBytesMultiLineEqual to unittest and use it
	for bytes assertEqual
In-Reply-To: <1287665297.21.0.48545376383.issue10164@psf.upfronthosting.co.za>
Message-ID: <1287665297.21.0.48545376383.issue10164@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

Just as with regular strings, when comparing failed output involving bytes strings it is really helpful to have a diff showing which bytes have changed.  The attached patch adds an assertMultiLineEqual method to unittest and uses it for comparing bytes in assertEqual.

The diff output is created by first breaking the byte strings into lines using 'splitlines(True)' just as in assertMultiLineEqual, but then each line is converted to a string using 'repr' before the lines sets are passed to ndiff.  This results in output containing escaped bytes, making it easier to compare the differences in the byte strings.

(NB: this patch is the end result of several attempts to make the unittest output more useful in the email package when testing bytes handling).

----------
files: bytes_multi_line_equal.diff
keywords: patch
messages: 119280
nosy: michael.foord, r.david.murray
priority: normal
severity: normal
stage: patch review
status: open
title: Add an assertBytesMultiLineEqual to unittest and use it for bytes assertEqual
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19320/bytes_multi_line_equal.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10164>
_______________________________________

From report at bugs.python.org  Thu Oct 21 14:50:00 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 12:50:00 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1287665400.01.0.72267264057.issue8999@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied in r85767.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Thu Oct 21 14:50:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 12:50:06 +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: <1287665406.51.0.186939272684.issue9095@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Now done in r85767.

----------
dependencies:  -`make patchcheck` should check the whitespace of .c/.h files
nosy: +georg.brandl
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9095>
_______________________________________

From report at bugs.python.org  Thu Oct 21 14:53:50 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 12:53:50 +0000
Subject: [issue3964] quiet the freeze makefile
In-Reply-To: <1222356648.66.0.370920569039.issue3964@psf.upfronthosting.co.za>
Message-ID: <1287665630.59.0.756462892934.issue3964@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing as "works for me".

----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3964>
_______________________________________

From report at bugs.python.org  Thu Oct 21 14:59:35 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 12:59:35 +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: <1287665975.29.0.857999699112.issue9919@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Patch looks good, committed in r85768.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9919>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:01:51 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 13:01:51 +0000
Subject: [issue6364] freeze tool broken in Python 3.x
In-Reply-To: <1246245349.44.0.542405438388.issue6364@psf.upfronthosting.co.za>
Message-ID: <1287666111.44.0.0477023774895.issue6364@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

An equivalent patch had already been committed in r83606.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6364>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:02:29 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 13:02:29 +0000
Subject: [issue1772721] [python-mode] Properly highlight lambda with no
	arguments
Message-ID: <1287666149.79.0.0420952150924.issue1772721@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

python-mode.el is not maintained in Python anymore.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772721>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:29:20 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 13:29:20 +0000
Subject: [issue3077] h2py char literal doesn't work
In-Reply-To: <1213172768.79.0.156029263713.issue3077@psf.upfronthosting.co.za>
Message-ID: <1287667760.67.0.966117244786.issue3077@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r85770.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3077>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:30:37 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 13:30:37 +0000
Subject: [issue9102] pybench: Cannot compare 2.x and 3.x benchmarks
In-Reply-To: <1277739722.07.0.677340784013.issue9102@psf.upfronthosting.co.za>
Message-ID: <1287667837.08.0.394467011375.issue9102@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9102>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:31:08 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 21 Oct 2010 13:31:08 +0000
Subject: [issue10165] char overwrite mode is by default on in Python console
	under Vista
In-Reply-To: <1287667868.12.0.532990029308.issue10165@psf.upfronthosting.co.za>
Message-ID: <1287667868.12.0.532990029308.issue10165@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

I never used Python console much, but now I see it has a very annoying behavior under Windows Vista. By default entered char overwrites the char under cursor. If you press Insert key once - it allows to insert key, but after you press enter - overwrite mode is back.

----------
messages: 119289
nosy: techtonik
priority: normal
severity: normal
status: open
title: char overwrite mode is by default on in Python console under Vista
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10165>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:31:14 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 13:31:14 +0000
Subject: [issue5978] cProfile and profile don't work with pygtk/pyqt and
	sys.exit(0)
In-Reply-To: <1241895448.39.0.497331485225.issue5978@psf.upfronthosting.co.za>
Message-ID: <1287667874.21.0.756844637838.issue5978@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> docs at python
components: +Documentation -Demos and Tools
nosy: +docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5978>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:35:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 13:35:02 +0000
Subject: [issue1203650] Allow larger programs to be frozen under Win32
Message-ID: <1287668102.16.0.352171409887.issue1203650@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied in r85771.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1203650>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:36:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Oct 2010 13:36:55 +0000
Subject: [issue10165] char overwrite mode is by default on in Python console
	under Vista
In-Reply-To: <1287667868.12.0.532990029308.issue10165@psf.upfronthosting.co.za>
Message-ID: <1287668215.6.0.0829588307927.issue10165@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

This has nothing to do with Python.


IIRC from another issue, you have pyreadline installed. Your cmd.exe settings may be conflicting with something that pyreadline is trying to do.

----------
nosy: +brian.curtin
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10165>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:37:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 13:37:36 +0000
Subject: [issue6088] Python3.0.1.1 is not available when system locale is
	zh_TW.eucTW
In-Reply-To: <1243007545.21.0.68248439701.issue6088@psf.upfronthosting.co.za>
Message-ID: <1287668256.17.0.334689688283.issue6088@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This is very probably resolved in 3.1 or 3.2, where lots of environment vs Unicode bugs were fixed.

----------
nosy: +georg.brandl
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6088>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:40:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 13:40:07 +0000
Subject: [issue3486] bytes.join does not accept a sequence of bytearrays
In-Reply-To: <1217612850.46.0.924257550681.issue3486@psf.upfronthosting.co.za>
Message-ID: <1287668407.07.0.432979344498.issue3486@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

py3k bytes won't be backported now.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3486>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:42:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Oct 2010 13:42:44 +0000
Subject: [issue10089] Add support for arbitrary -X options
In-Reply-To: <1286996500.23.0.0250789164181.issue10089@psf.upfronthosting.co.za>
Message-ID: <1287668564.7.0.694040300288.issue10089@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85772.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10089>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:46:00 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 13:46:00 +0000
Subject: [issue4829] confusing error for file("foo", "w++")
In-Reply-To: <1231067838.12.0.558588021919.issue4829@psf.upfronthosting.co.za>
Message-ID: <1287668760.08.0.882660397819.issue4829@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Amended error message in r85773.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4829>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:47:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 13:47:48 +0000
Subject: [issue5218] Check for tp_iter in ceval:ext_do_call before overriding
	exception message
In-Reply-To: <1234380763.79.0.974439208897.issue5218@psf.upfronthosting.co.za>
Message-ID: <1287668868.38.0.6390614214.issue5218@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Is this ready to commit?

----------
assignee:  -> pitrou
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5218>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:48:56 2010
From: report at bugs.python.org (Tim Golden)
Date: Thu, 21 Oct 2010 13:48:56 +0000
Subject: [issue10165] char overwrite mode is by default on in Python console
	under Vista
In-Reply-To: <1287667868.12.0.532990029308.issue10165@psf.upfronthosting.co.za>
Message-ID: <4CC044C3.3050001@timgolden.me.uk>


Tim Golden <mail at timgolden.me.uk> added the comment:

If you don't often use the console, then I expect your console settings 
have Insert mode off. (Alt-Space > Properties > Options > Insert Mode [x])

----------
nosy: +tim.golden

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10165>
_______________________________________

From report at bugs.python.org  Thu Oct 21 15:53:59 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Thu, 21 Oct 2010 13:53:59 +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: <1287669239.43.0.118232747043.issue10154@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

Mark, the locals() right before "if encoding:" (line 399) are:

>>> locale.normalize("en_US.UTF-8")
{'code': 'en_US.ISO8859-1', 'langname': 'en_US', 'encoding': 'UTF8', 'norm_encoding': 'utf_8', 'defenc': 'ISO8859-1', 'localename': 'en_US.UTF-8', 'lookup_name': 'en_us.utf-8', 'fullname': 'en_us.utf-8'}
'en_US.UTF8'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Thu Oct 21 16:02:10 2010
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 21 Oct 2010 14:02:10 +0000
Subject: [issue10163] 7/200 and 7%200 show weird results
In-Reply-To: <1287660110.32.0.294845890342.issue10163@psf.upfronthosting.co.za>
Message-ID: <1287669730.86.0.388875062598.issue10163@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Seconding Eric's comment.  This is what I get on my machine;  can you cut and paste the equivalent output on yours (including whatever else is required to reproduce the results you describe)

Python 2.6.1 (r261:67515, Feb 11 2010, 15:47:53) 
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 200 % 7
4

In any case, please let us know which version of Python you're using, and where you got it from.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10163>
_______________________________________

From report at bugs.python.org  Thu Oct 21 16:11:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 14:11:57 +0000
Subject: [issue10163] 7/200 and 7%200 show weird results
In-Reply-To: <1287660110.32.0.294845890342.issue10163@psf.upfronthosting.co.za>
Message-ID: <1287670317.2.0.804103400298.issue10163@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The bug title interestingly says "7%200", which does result in 7.  I therefore think the OP just confused the order of operands for "%".

----------
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10163>
_______________________________________

From report at bugs.python.org  Thu Oct 21 16:15:07 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Oct 2010 14:15:07 +0000
Subject: [issue10154] locale.normalize strips "-" from UTF-8,
	which fails on Mac
In-Reply-To: <1287669239.43.0.118232747043.issue10154@psf.upfronthosting.co.za>
Message-ID: <4CC04AE7.6030305@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Stephen Hansen wrote:
> 
> Stephen Hansen <me+python at ixokai.io> added the comment:
> 
> Mark, the locals() right before "if encoding:" (line 399) are:
> 
>>>> locale.normalize("en_US.UTF-8")
> {'code': 'en_US.ISO8859-1', 'langname': 'en_US', 'encoding': 'UTF8', 'norm_encoding': 'utf_8', 'defenc': 'ISO8859-1', 'localename': 'en_US.UTF-8', 'lookup_name': 'en_us.utf-8', 'fullname': 'en_us.utf-8'}
> 'en_US.UTF8'

Thanks.

Line 646 in the alias table is wrong:

    'utf_8':                        'UTF8',

should read:

    'utf_8':                        'UTF-8',

I wonder why this wasn't reported earlier - did the GlibC change
the UTF-8 spelling at some point ? I do vaguely remember that I
had to remove the hyphen due to problems with setlocale() not
accepting 'UTF-8', but that was at the time I wrote that part
of locale.py, i.e. many years ago.

It doesn't appear to be necessary anymore. I checked on openSUSE
10.3 and 11.3. Both work fine with 'UTF-8' and 'UTF8'.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Thu Oct 21 16:19:53 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 21 Oct 2010 14:19:53 +0000
Subject: [issue10165] char overwrite mode is by default on in Python console
	under Vista
In-Reply-To: <1287667868.12.0.532990029308.issue10165@psf.upfronthosting.co.za>
Message-ID: <1287670793.89.0.827426128657.issue10165@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

I don't have pyreadline installed.

But I had Insert Mode disabled for Python, indeed. I wonder if the setting comes disabled by default?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10165>
_______________________________________

From report at bugs.python.org  Thu Oct 21 16:23:11 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Oct 2010 14:23:11 +0000
Subject: [issue10165] char overwrite mode is by default on in Python console
	under Vista
In-Reply-To: <1287667868.12.0.532990029308.issue10165@psf.upfronthosting.co.za>
Message-ID: <1287670991.63.0.0685311051819.issue10165@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

> I wonder if the setting comes disabled by default?

Correct.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10165>
_______________________________________

From report at bugs.python.org  Thu Oct 21 16:49:13 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 21 Oct 2010 14:49:13 +0000
Subject: [issue10165] char overwrite mode is by default on in Python console
	under Vista
In-Reply-To: <1287670991.63.0.0685311051819.issue10165@psf.upfronthosting.co.za>
Message-ID: <AANLkTim_0jqSFakcGmHowCb9ZJsSGMk8-cd__wjrqBEq@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

>> I wonder if the setting comes disabled by default?
>
> Correct.

Can we turn it on by default in Windows installer?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10165>
_______________________________________

From report at bugs.python.org  Thu Oct 21 16:50:00 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 21 Oct 2010 14:50:00 +0000
Subject: [issue10157] Memory leak (r70152)
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1287672600.81.0.283682283895.issue10157@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Hello. Does this patch fix the problem?

----------
keywords: +patch
nosy: +ocean-city
Added file: http://bugs.python.org/file19321/py3k_issue10157.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10157>
_______________________________________

From report at bugs.python.org  Thu Oct 21 16:50:07 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Oct 2010 14:50:07 +0000
Subject: [issue10162] mimetypes read_windows_registry should tolerate
	permissions errors
In-Reply-To: <1287621877.59.0.625449070173.issue10162@psf.upfronthosting.co.za>
Message-ID: <1287672607.82.0.51034688537.issue10162@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in py3k (r85774, minor correction in r85775), and release27-maint (r85776).

Thanks for the patches!

----------
assignee:  -> brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: feature request -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10162>
_______________________________________

From report at bugs.python.org  Thu Oct 21 17:01:23 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Oct 2010 15:01:23 +0000
Subject: [issue10165] char overwrite mode is by default on in Python console
	under Vista
In-Reply-To: <1287667868.12.0.532990029308.issue10165@psf.upfronthosting.co.za>
Message-ID: <1287673283.56.0.931446788046.issue10165@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm not sure if it's possible, but even if so, I don't think we should do it. For cmd.exe itself and all processes that run in it, the default is to have it off, and you can enable it on a case-by-case basis.

Insert mode really should only be enabled by those who know what it does. For example, left clicking while a process is using stdout will block until you left click, and I can see that confusing users who are not aware of what happened or why.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10165>
_______________________________________

From report at bugs.python.org  Thu Oct 21 17:02:49 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Oct 2010 15:02:49 +0000
Subject: [issue10165] char overwrite mode is by default on in Python console
	under Vista
In-Reply-To: <1287667868.12.0.532990029308.issue10165@psf.upfronthosting.co.za>
Message-ID: <1287673369.27.0.282680874322.issue10165@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

"will block until you left click"
should be...
"will block until you right click (or hit enter)"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10165>
_______________________________________

From report at bugs.python.org  Thu Oct 21 17:27:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Oct 2010 15:27:06 +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: <1287674826.68.0.247115386276.issue10154@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If other Posix-y systems accept both spellings and only Macs insist on the dash, we should probably indeed change the alias entry to use it.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10154>
_______________________________________

From report at bugs.python.org  Thu Oct 21 17:45:06 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Thu, 21 Oct 2010 15:45:06 +0000
Subject: [issue10165] char overwrite mode is by default on in Python console
	under Vista
In-Reply-To: <1287673369.27.0.282680874322.issue10165@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=JPv2_r3N49mg_NqDiJYPngP3f1Ros7zrtF0JJ@mail.gmail.com>


anatoly techtonik <techtonik at gmail.com> added the comment:

You must have been mistaken this for QuickEdit mode.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10165>
_______________________________________

From report at bugs.python.org  Thu Oct 21 17:50:14 2010
From: report at bugs.python.org (=?utf-8?q?Adam_Biela=C5=84ski?=)
Date: Thu, 21 Oct 2010 15:50:14 +0000
Subject: [issue10166] maximum recursion depth exceeded in lib\pstats.py
In-Reply-To: <1287676214.72.0.937902766344.issue10166@psf.upfronthosting.co.za>
Message-ID: <1287676214.72.0.937902766344.issue10166@psf.upfronthosting.co.za>


New submission from Adam Biela?ski <abgans at gmail.com>:

There's a bug in module lib\pstats.py, line 150. 

Let me paste a little piece of surrounding code:

    class Stats:
      (....)
        def add(self, *arg_list):
            if not arg_list: return self
            if len(arg_list) > 1: self.add(*arg_list[1:])  #Line 150, the problem is right here!
            other = arg_list[0]
            (... do some processing with first item from arg_list ...)

This is the code for adding profiling stats from multiple files (names are on arg_list) so that they can be displayed in cumulated and readable form.

As you can see it chops off the first item from the list and then uses recursion to process the rest of it. It's no wonder then that when you profiled a little too many function calls, you're bound to see RuntimeError with 'maximum recursion depth exceeded' message when you try using this. IMO this should be done with iteration instead, like:

        def add(self, *arg_list):
            if not arg_list: return self
            for other in arg_list: #Preserved variable name only for sake of comparison with previous snippet
                (... do some processing with each item from arg_list, merging results in some rightful manner ...)


You can find a patch for this issue in the attachment.

----------
components: Library (Lib)
files: pstats.patch
keywords: patch
messages: 119311
nosy: Adam.Biela?ski
priority: normal
severity: normal
status: open
title: maximum recursion depth exceeded in lib\pstats.py
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file19322/pstats.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10166>
_______________________________________

From mail at timgolden.me.uk  Thu Oct 21 17:03:09 2010
From: mail at timgolden.me.uk (Tim Golden)
Date: Thu, 21 Oct 2010 16:03:09 +0100
Subject: [issue10165] char overwrite mode is by default on in Python console
	under Vista
Message-ID: <4CC0562D.4030901@timgolden.me.uk>

Agree that it's not really up to us; and that it's trivial to change 
once for all future python processes.

As to the left-click blocking, I think that's "Quick Edit" mode you're 
thinking of, not "Insert"

TJG

From report at bugs.python.org  Thu Oct 21 17:56:05 2010
From: report at bugs.python.org (And Clover)
Date: Thu, 21 Oct 2010 15:56:05 +0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1287676565.53.0.0376969638445.issue2193@psf.upfronthosting.co.za>


And Clover <and at doxdesk.com> added the comment:

The various attempts by RFCs to codify HTTP cookies are useless and bear no resemblance to what browsers actually do.

In the real world, every byte in the range 0x20-0x7E is allowed, except for the semicolon, the equals (in names), and in Opera, in some places, the double-quote. Many browsers even allow most of the control codes! The question of non-ASCII Unicode characters is tricky, but none of them cause a token break.

Contrary to RFC2109 and its successors, no browser takes any notice of quoted-string cookies or backslash-escaping, so the effort Cookie.py puts into producing an encoded string and 'parsing' input cookies is completely wasted. It should do what everyone else does: split on semicolon, left-strip the whitespace, split each cookie on first equals.

(In reality cookie names and values have no inherent encoding scheme, so if you want to include out-of-band characters like semicolon, control characters or non-ASCII characters you have to use an ad-hoc encoding scheme, often URL-encoding.)

----------
nosy: +aclover

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
_______________________________________

From report at bugs.python.org  Thu Oct 21 18:05:05 2010
From: report at bugs.python.org (Alexander Collins)
Date: Thu, 21 Oct 2010 16:05:05 +0000
Subject: [issue10167] ESET Torgan Alert [python-3.1.2.amd64 ON Win7-64]
In-Reply-To: <1287677105.85.0.830529518835.issue10167@psf.upfronthosting.co.za>
Message-ID: <1287677105.85.0.830529518835.issue10167@psf.upfronthosting.co.za>


New submission from Alexander Collins <abdullah.lemon at gmail.com>:

While trying to install 3.1.2 on my windows 7. I was faced with a Trojan alert from my ESET "NOD32" anti-virus.

The link to the file: http://www.python.org/ftp/python/3.1.2/python-3.1.2.amd64.msi

A snapshot is attached.


Windows 7 x64
ESET Smart Security 4.2.64.12

----------
components: Installation
files: pythonSecurityWarningESET.png
messages: 119313
nosy: Mr.Collins
priority: normal
severity: normal
status: open
title: ESET Torgan Alert [python-3.1.2.amd64 ON Win7-64]
type: security
versions: Python 3.1
Added file: http://bugs.python.org/file19323/pythonSecurityWarningESET.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10167>
_______________________________________

From report at bugs.python.org  Thu Oct 21 18:06:55 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Oct 2010 16:06:55 +0000
Subject: [issue10167] ESET Trojan Alert [python-3.1.2.amd64 ON Win7-64]
In-Reply-To: <1287677105.85.0.830529518835.issue10167@psf.upfronthosting.co.za>
Message-ID: <1287677215.03.0.606563913836.issue10167@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
title: ESET Torgan Alert [python-3.1.2.amd64 ON Win7-64] -> ESET Trojan Alert [python-3.1.2.amd64 ON Win7-64]

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10167>
_______________________________________

From report at bugs.python.org  Thu Oct 21 18:15:36 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Oct 2010 16:15:36 +0000
Subject: [issue10167] ESET Trojan Alert [python-3.1.2.amd64 ON Win7-64]
In-Reply-To: <1287677105.85.0.830529518835.issue10167@psf.upfronthosting.co.za>
Message-ID: <1287677736.93.0.760596847334.issue10167@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I just ran that installer on Windows 7 x64 with Sophos AV and got no such warning.

FWIW, the checksum of the downloaded installer matched the one listed on http://www.python.org/download/releases/3.1.2/

----------
components: +Windows
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10167>
_______________________________________

From report at bugs.python.org  Thu Oct 21 18:40:05 2010
From: report at bugs.python.org (Alexander Collins)
Date: Thu, 21 Oct 2010 16:40:05 +0000
Subject: [issue10167] ESET Trojan Alert [python-3.1.2.amd64 ON Win7-64]
In-Reply-To: <1287677105.85.0.830529518835.issue10167@psf.upfronthosting.co.za>
Message-ID: <1287679205.29.0.451348865675.issue10167@psf.upfronthosting.co.za>


Alexander Collins <abdullah.lemon at gmail.com> added the comment:

Checksum matches. I am not sure why did it detect that.

The AV report: ( I shoulda posted that earlier -_-')

//- Report starts ...

10/21/2010 11:54:12 AM	
Real-time file system protection	
file	C:\Windows\Installer\{D40AF016-506C-43FB-A738-BD54FA8C1E86}\python_icon.exe	
Win32/Agent.RRQ trojan	
cleaned by deleting - quarantined	
NT AUTHORITY\SYSTEM	
Event occurred on a new file created by the application: C:\Windows\System32\msiexec.exe


//- Report ends ...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10167>
_______________________________________

From report at bugs.python.org  Thu Oct 21 18:44:29 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 21 Oct 2010 16:44:29 +0000
Subject: [issue10168] tkinter.Canvas.coords should return a list, not a map
In-Reply-To: <1287679469.77.0.585032581167.issue10168@psf.upfronthosting.co.za>
Message-ID: <1287679469.77.0.585032581167.issue10168@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Apparently a 2.x to 3.x migration artifact.  Canvas.coords() is documented as returning a list:

    def coords(self, *args):
        """Return a list of coordinates for the item given in ARGS."""

but in 3.x it returns a map object.

Attached patch fixes that.

----------
components: Tkinter
files: canvas-coords.diff
keywords: patch
messages: 119316
nosy: belopolsky
priority: normal
severity: normal
stage: unit test needed
status: open
title: tkinter.Canvas.coords should return a list, not a map
type: behavior
versions: Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19324/canvas-coords.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10168>
_______________________________________

From report at bugs.python.org  Thu Oct 21 18:45:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Oct 2010 16:45:26 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1287679526.25.0.502296479511.issue8716@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Only OSX 10.4.0 I can run test_tk:

rdmurray at buddy:~/python/py3k>./python.exe -m test.regrtest -uall test_tk         
[1/1] test_tk
Thu Oct 21 12:41:16 buddy.home.bitdance.com python.exe[93560] <Error>: kCGErrorFailure: Set a breakpoint @ CGErrorBreakpoint() to catch errors as they are logged.
_RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
1 test OK.

But test_ttk_guionly crashes with the abort trace after printing the above.  I presume this means test_ttk_guionly was factored out at some point after this issue was raised, but it is interesting that test_tk produces the warning about the window connection but only _guionly crashes.

----------
title: test_tk fails on OS X if run from buildbot slave daemon -- crashes Python -> test_tk/test_tkk_guionly fails on OS X if run from buildbot slave daemon -- crashes Python
versions:  -Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Thu Oct 21 18:48:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Oct 2010 16:48:12 +0000
Subject: [issue5120] Disabling test_ttk_guionly on mac
In-Reply-To: <1233437150.39.0.445953575427.issue5120@psf.upfronthosting.co.za>
Message-ID: <1287679692.93.0.0124115277811.issue5120@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Presumably this is the same issue 8716.  That issue contains additional details and a patch from Ronald, so I'm not closing it as a duplicate.  

I don't know if the patch on this issue would actually address the issue.  I tried to apply it to py3k but it did not apply cleanly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5120>
_______________________________________

From report at bugs.python.org  Thu Oct 21 18:48:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 21 Oct 2010 16:48:43 +0000
Subject: [issue8716] test_tk/test_tkk_guionly fails on OS X if run from
	buildbot slave daemon -- crashes Python
In-Reply-To: <1273861312.32.0.0344970613986.issue8716@psf.upfronthosting.co.za>
Message-ID: <1287679723.88.0.972103627462.issue8716@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

See also issue 5120.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8716>
_______________________________________

From report at bugs.python.org  Thu Oct 21 19:11:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Oct 2010 17:11:27 +0000
Subject: [issue3356] some tests fail with 'make EXTRA_CFLAGS="-DPy_DEBUG"'
	(test_distutils, test_set)
In-Reply-To: <1216070128.91.0.762620118024.issue3356@psf.upfronthosting.co.za>
Message-ID: <1287681087.45.0.649896218164.issue3356@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3356>
_______________________________________

From report at bugs.python.org  Thu Oct 21 19:16:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Oct 2010 17:16:49 +0000
Subject: [issue10153] Memory leak in pythonrun.c
In-Reply-To: <1287572976.12.0.192446732245.issue10153@psf.upfronthosting.co.za>
Message-ID: <1287681409.64.0.264343271967.issue10153@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/issue10153>
_______________________________________

From report at bugs.python.org  Thu Oct 21 19:22:08 2010
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Thu, 21 Oct 2010 17:22:08 +0000
Subject: [issue10169] socket.sendto raises incorrect exception when passed
	incorrect types
In-Reply-To: <1287681728.0.0.651147678785.issue10169@psf.upfronthosting.co.za>
Message-ID: <1287681728.0.0.651147678785.issue10169@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <invalid at example.invalid>:

>>> s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
>>> s.bind(('', 0))
>>> s.sendto(u'hell?', s.getsockname())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sendto() takes exactly 3 arguments (2 given)
>>> s.sendto(3, s.getsockname())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: sendto() takes exactly 3 arguments (2 given)
>>> s.sendto('hello', s.getsockname())
5

The TypeError gives the wrong explanation for what's wrong.

----------
components: Library (Lib)
messages: 119320
nosy: exarkun
priority: normal
severity: normal
status: open
title: socket.sendto raises incorrect exception when passed incorrect types
type: behavior
versions: Python 2.6, Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10169>
_______________________________________

From report at bugs.python.org  Thu Oct 21 19:23:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 17:23:04 +0000
Subject: [issue8999] Add Mercurial support to patchcheck
In-Reply-To: <1276593572.4.0.720668123002.issue8999@psf.upfronthosting.co.za>
Message-ID: <1287681784.81.0.622805194322.issue8999@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Great, thanks!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8999>
_______________________________________

From report at bugs.python.org  Thu Oct 21 19:30:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 17:30:58 +0000
Subject: [issue10168] tkinter.Canvas.coords should return a list, not a map
In-Reply-To: <1287679469.77.0.585032581167.issue10168@psf.upfronthosting.co.za>
Message-ID: <1287682258.76.0.268592828384.issue10168@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> duplicate
stage: unit test needed -> committed/rejected
status: open -> closed
superseder:  -> changed return type from tkinter.Canvas.coords

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10168>
_______________________________________

From report at bugs.python.org  Thu Oct 21 19:31:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 17:31:52 +0000
Subject: [issue6878] changed return type from tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1287682312.83.0.535003369008.issue6878@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +belopolsky
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________

From report at bugs.python.org  Thu Oct 21 19:48:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 21 Oct 2010 17:48:15 +0000
Subject: [issue6878] changed return type from tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1287683295.57.0.150515965917.issue6878@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Searching through tkinter for map() calls reveals many other places where map object is returned instead of a list.  For example:

    def keys(self):
        """Return a list of all resource names of this widget."""
        return map(lambda x: x[0][1:], ..

    def pack_slaves(self):
        """Return a list of all slaves of this widget                                                                                                                    
        in its packing order."""
        return map(self._nametowidget, ..

    def place_slaves(self):
        """Return a list of all slaves of this widget                                                                                                                    
        in its packing order."""
        return map(self._nametowidget, ..


    def wm_colormapwindows(self, *wlist):
        ...
        Return current list of widgets if WLIST is empty."""
        return map(..

While in some cases it may be arguable that returning an iterable is more appropriate for 3.x, I believe preserving backward compatible API is more important.   API changes should also be accompanied with 2to3 fixes, so some action is required in any case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________

From report at bugs.python.org  Thu Oct 21 20:02:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 21 Oct 2010 18:02:46 +0000
Subject: [issue6878] changed return type from tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1287684166.68.0.212180087071.issue6878@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch fixes other uses of map() in tkinter.

----------
Added file: http://bugs.python.org/file19325/issue6878.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________

From report at bugs.python.org  Thu Oct 21 20:03:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 18:03:25 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1287684205.0.0.673774060736.issue7061@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

>From your commit:
-Excursus about the use of compound shapes
+Compound shapes
 -----------------------------------------

Having more hyphens than title characters is not an error for reST, but it?s not done in the rest of the document.  I suggest ?fixing? that when you do further changes in the file (it?s not worth a commit in itself).  Cheers!

----------
assignee: georg.brandl -> docs at python
nosy: +docs at python, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Thu Oct 21 20:05:56 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Thu, 21 Oct 2010 18:05:56 +0000
Subject: [issue5017] import suds help( suds ) fails
In-Reply-To: <1232501801.2.0.242744979679.issue5017@psf.upfronthosting.co.za>
Message-ID: <1287684356.45.0.236307703275.issue5017@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/issue5017>
_______________________________________

From report at bugs.python.org  Thu Oct 21 20:10:04 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Oct 2010 18:10:04 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287684604.28.0.52507917705.issue10126@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Hi ?ric, what's the status on the backport?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Thu Oct 21 20:12:22 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 21 Oct 2010 18:12:22 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1287684205.0.0.673774060736.issue7061@psf.upfronthosting.co.za>
Message-ID: <AANLkTimn7EdGZmL-j-vsXdSeUwOnEP1CnvqofB_Tq=9Q@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Oct 21, 2010 at 2:03 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> Having more hyphens than title characters is not an error for reST, but it?s not done in the rest of the document.
> ?I suggest ?fixing? that when you do further changes in the file (it?s not worth a commit in itself). ?Cheers!

There are other ReST imperfections in turtle doc.  For example,
:class: tag is often missing on class names. (Search for "Turtle" with
capital 'T'.)   The hyphen fix, however seems easier to commit than to
remember.   I'll do it now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Thu Oct 21 20:16:31 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 21 Oct 2010 18:16:31 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <AANLkTimn7EdGZmL-j-vsXdSeUwOnEP1CnvqofB_Tq=9Q@mail.gmail.com>
Message-ID: <AANLkTik8U9e3jFyNa845XjvULnnc29GftAyTx-tYf9SL@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Oct 21, 2010 at 2:12 PM, Alexander Belopolsky
<belopolsky at users.sourceforge.net> wrote:
> The hyphen fix, however seems easier to commit than to
> remember. ? I'll do it now.
>

Committed in r85778.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Thu Oct 21 20:54:02 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 18:54:02 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287687242.01.0.61338525917.issue10126@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Done in r85779 and r85780, please test.

----------
components: +Distutils
nosy: +Canfield, matejcik, sandro.tosi, valeo
resolution:  -> fixed
stage: needs patch -> committed/rejected
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Thu Oct 21 20:58:09 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 21 Oct 2010 18:58:09 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1287687489.95.0.88716780852.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I also wonder if the title should be changed from "Turtle graphics for Tk" to simply "Turtle graphics".  As explained in issue3884, msg73465 turtle's use of Tk is an implementation detail and the title may be confusing to the target audience.  Presumably turtle module is targeted towards young and novice users who don't know and don need to know about Tk.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Thu Oct 21 21:00:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 19:00:44 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1287687644.14.0.10462557389.issue7061@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1.

BTW, aren?t the fixes relevant for 2.7 too?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Thu Oct 21 21:01:52 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 21 Oct 2010 19:01:52 +0000
Subject: [issue10167] ESET Trojan Alert [python-3.1.2.amd64 ON Win7-64]
In-Reply-To: <1287677105.85.0.830529518835.issue10167@psf.upfronthosting.co.za>
Message-ID: <1287687712.15.0.487566809267.issue10167@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

I'm not really sure if there's anything we can or should do here.


Martin, has this happened before, and if so is there anything to be done by us?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10167>
_______________________________________

From report at bugs.python.org  Thu Oct 21 21:33:25 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 21 Oct 2010 19:33:25 +0000
Subject: [issue10153] Memory leak in pythonrun.c
In-Reply-To: <1287572976.12.0.192446732245.issue10153@psf.upfronthosting.co.za>
Message-ID: <1287689605.49.0.328282509503.issue10153@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


Removed file: http://bugs.python.org/file19294/pythonrun.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10153>
_______________________________________

From report at bugs.python.org  Thu Oct 21 21:34:19 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 21 Oct 2010 19:34:19 +0000
Subject: [issue10153] Memory leak in pythonrun.c
In-Reply-To: <1287572976.12.0.192446732245.issue10153@psf.upfronthosting.co.za>
Message-ID: <1287689659.24.0.672296060311.issue10153@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

There is actually a second refleak of the same kind. New patch attached.

----------
Added file: http://bugs.python.org/file19326/pythonrun2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10153>
_______________________________________

From report at bugs.python.org  Thu Oct 21 21:48:19 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 21 Oct 2010 19:48:19 +0000
Subject: [issue10157] Memory leak (r70152)
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1287690499.04.0.253928247411.issue10157@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Hirokazu, the patch looks good to me. Unfortunately Valgrind still
reports the leak.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10157>
_______________________________________

From report at bugs.python.org  Thu Oct 21 22:20:11 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 21 Oct 2010 20:20:11 +0000
Subject: [issue10170] Relationship between turtle speed setting and actual
	speed is not documented
In-Reply-To: <1287692411.21.0.472855700629.issue10170@psf.upfronthosting.co.za>
Message-ID: <1287692411.21.0.472855700629.issue10170@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

As Terry J. Reedy mentioned in his comment on issue 7061, turtle documentation is lacking information on how speed "codes" 0-10 translate into actual turtle speed.

Attached script measures the speed of the two primitive operations that form the basis of turtle functionality at various speed settings.  The results below show highly irregular pattern.  The columns are: the speed code, time to draw a 200 unit line, time to complete a 360 degrees turn and the ratio of the two times.


         0: 0.01 0.01 0.83
         1: 1.04 2.05 0.51
         2: 0.49 1.06 0.46
         3: 0.30 0.72 0.42
         4: 0.23 0.54 0.44
         5: 0.17 0.44 0.38
         6: 0.13 0.39 0.35
         7: 0.08 0.32 0.26
         8: 0.08 0.28 0.30
         9: 0.10 0.27 0.37
        10: 0.08 0.23 0.36


>From the source code, it appears that the on-screen speed is controlled by the number of animation steps while each step takes approximately time controlled by the "delay" setting that defaults to 10 milliseconds.

The number of steps is determined by somewhat peculiar computations.  For a rotation by angle of a degrees at speed setting s, the number of steps is

       n = 2 + int(a / (3 * s))

and for drawing a line of length d,

       n = 1 +  int(d / (3 * 1.1**s * s))

I am not sure what was the reason for these choices, but I think it would be better if numeric speed code had a more direct relationship to the apparent speed.

----------
assignee: docs at python
components: Demos and Tools, Documentation
messages: 119334
nosy: belopolsky, docs at python, eric.araujo, georg.brandl, gregorlingl, terry.reedy
priority: normal
severity: normal
status: open
title: Relationship between turtle speed setting and actual speed is not documented
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10170>
_______________________________________

From report at bugs.python.org  Thu Oct 21 22:35:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 21 Oct 2010 20:35:06 +0000
Subject: [issue4117] missing update() in _Screen.setup() of Lib/turtle.py
In-Reply-To: <1223938964.4.0.025382695872.issue4117@psf.upfronthosting.co.za>
Message-ID: <1287693306.22.0.768511884228.issue4117@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

See also "turtle.py update for 3.1" post on python-dev specifically mentioning this bug as fixed.

http://mail.python.org/pipermail/python-dev/2009-May/089383.html

----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4117>
_______________________________________

From report at bugs.python.org  Thu Oct 21 22:46:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 21 Oct 2010 20:46:40 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1287687644.14.0.10462557389.issue7061@psf.upfronthosting.co.za>
Message-ID: <AANLkTimMDC=skYm_yzahNf5ebrvJRXL+e=-rFcLk9hcQ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Oct 21, 2010 at 3:00 PM, ?ric Araujo <report at bugs.python.org> wrote:
..
> +1. [remove reference to Tk from title]
>
If we do that, I think we should move turtle documentation out of the
"Graphical User Interfaces with Tk" chapter.  It would be more
appropriate to place it under "Program Frameworks".

> BTW, aren?t the fixes relevant for 2.7 too?
>

They probably are, but for a purely educational module such as turtle,
I don't see much value in improving it in 2.x releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Thu Oct 21 22:55:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 20:55:15 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1287694515.77.0.465580593476.issue7061@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed that Program Frameworks is the most adequate section.

For the backport, I don?t see that turtle should have different rules than other modules, but I?m not firmly attached to this, so do as you wish.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Thu Oct 21 22:55:59 2010
From: report at bugs.python.org (Alexander Collins)
Date: Thu, 21 Oct 2010 20:55:59 +0000
Subject: [issue10167] ESET Trojan Alert [python-3.1.2.amd64 ON Win7-64]
In-Reply-To: <1287677105.85.0.830529518835.issue10167@psf.upfronthosting.co.za>
Message-ID: <1287694559.74.0.951725809839.issue10167@psf.upfronthosting.co.za>


Alexander Collins <abdullah.lemon at gmail.com> added the comment:

I'll attempt to contact my anti-virus provider and see what they have to say about that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10167>
_______________________________________

From report at bugs.python.org  Thu Oct 21 23:46:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 21:46:25 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287697585.73.0.310877315159.issue10126@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The backport fixed test_build_ext (the method) but not test_get_outputs.  Barry and I are on it.

----------
resolution: fixed -> 
stage: committed/rejected -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Thu Oct 21 23:51:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Oct 2010 21:51:43 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1287697903.89.0.570736876924.issue5639@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch for py3k, including http.client and urllib support.

----------
Added file: http://bugs.python.org/file19327/sni.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Thu Oct 21 23:56:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 21:56:49 +0000
Subject: [issue10143] Update "os.pathconf" values
In-Reply-To: <1287459031.95.0.424598520823.issue10143@psf.upfronthosting.co.za>
Message-ID: <1287698209.19.0.932893176963.issue10143@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you produce a patch?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10143>
_______________________________________

From report at bugs.python.org  Fri Oct 22 00:02:21 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 22:02:21 +0000
Subject: [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1287698541.41.0.965673804613.issue10149@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Would you like to turn your suggestions (+ hinting at buffer_text someplace) into a patch for Doc/library/pyexpat.rst?

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10149>
_______________________________________

From report at bugs.python.org  Fri Oct 22 00:05:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 22:05:43 +0000
Subject: [issue10076] Regex objects became uncopyable in 2.5
In-Reply-To: <1286916324.24.0.772801528988.issue10076@psf.upfronthosting.co.za>
Message-ID: <1287698743.58.0.0195313337613.issue10076@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +ezio.melotti

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10076>
_______________________________________

From report at bugs.python.org  Fri Oct 22 00:08:55 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Oct 2010 22:08:55 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287698935.13.0.468279513739.issue10126@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

It's possible the proposed patch for 2.7 should be used in python 3 also.  Or as __ap__ suggestions in irc, os.path.dirname(sys.executable)

----------
Added file: http://bugs.python.org/file19328/10126-py27.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Fri Oct 22 00:13:56 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Thu, 21 Oct 2010 22:13:56 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287699236.73.0.217156720778.issue10126@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Fixed in 2.7 by r85784

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Fri Oct 22 00:27:34 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 22:27:34 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1287700054.3.0.180318227159.issue10060@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

There are half a dozen duplicate bugs of this one, with various suggestions on each.  They should be summed up and linked.  I should be able to do it this week-end if no-one does it first.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Fri Oct 22 00:37:24 2010
From: report at bugs.python.org (David Watson)
Date: Thu, 21 Oct 2010 22:37:24 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <4CC006D9.5030305@egenix.com>
Message-ID: <20101021223714.GA3834@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

> On other platforms, I guess we'll just have to do some trial
> and error to see what works and what not. E.g. on Linux it is
> possible to set the hostname to a non-ASCII value, but then
> the resolver returns an error, so it's not very practical:
> 
> # hostname l\303\266wis
> # hostname
> l?wis
> # hostname -f
> hostname: Resolver Error 0 (no error)
> 
> Using the IDNA version doesn't help either:
> 
> # hostname xn--lwis-5qa
> # hostname
> xn--lwis-5qa
> # hostname -f
> hostname: Resolver Error 0 (no error)

I think what's happening here is that simply that you're setting
the hostname to something which doesn't exist in the relevant
name databases - the man page for Linux's hostname(1) says that
"The FQDN is the name gethostbyname(2) returns for the host name
returned by gethostname(2).".  If the computer's usual name is
"newton", that may be why it works and the others don't.

It works for me if I add "127.0.0.9 l?wis.egenix.com l?wis" to
/etc/hosts and then set the hostname to "l?wis" (all UTF-8):
hostname -f prints "l?wis.egenix.com", and Python 2's
socket.getfqdn() returns the corresponding bytes; non-UTF-8 names
work too.  (Note that the FQDN must appear before the bare
hostname in the /etc/hosts entry, and I used the address
127.0.0.9 simply to avoid a collision with existing entries - by
default, Ubuntu assigns the FQDN to 127.0.1.1.)

----------
title: socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Fri Oct 22 00:46:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 22:46:31 +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: <1287701191.98.0.575885024244.issue9807@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FTR, the ld bug with --enable-shared is tracked in #10126.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9807>
_______________________________________

From report at bugs.python.org  Fri Oct 22 00:49:07 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 22:49:07 +0000
Subject: [issue4359] at runtime, distutils uses buildtime files
In-Reply-To: <1227138737.98.0.796971482315.issue4359@psf.upfronthosting.co.za>
Message-ID: <1287701347.67.0.161623325168.issue4359@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

... and #9807 spawned #9878.

----------
superseder: deriving configuration information for different builds with the same prefix -> Avoid parsing pyconfig.h and Makefile by autogenerating extension module

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4359>
_______________________________________

From report at bugs.python.org  Fri Oct 22 00:51:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 22:51:05 +0000
Subject: [issue10147] Python Documentation bugs
In-Reply-To: <1287515992.96.0.884562024831.issue10147@psf.upfronthosting.co.za>
Message-ID: <1287701465.77.0.122615919807.issue10147@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Adjectives require hyphens but nouns do not.  ?thread-safety? should be reverted to ?thread safety?.  I haven?t searched for a grammar reference, but you can take Wikipedia as an example: ?Thread safety is a computer programming concept applicable in the context of multi-threaded programs. A piece of code is thread-safe if it functions correctly during simultaneous execution by multiple threads.?

----------
nosy: +eric.araujo
versions:  -3rd party, Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10147>
_______________________________________

From report at bugs.python.org  Fri Oct 22 00:52:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 22:52:35 +0000
Subject: [issue10169] socket.sendto raises incorrect exception when passed
	incorrect types
In-Reply-To: <1287681728.0.0.651147678785.issue10169@psf.upfronthosting.co.za>
Message-ID: <1287701555.87.0.121055671502.issue10169@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +pitrou
versions: +Python 3.1 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10169>
_______________________________________

From report at bugs.python.org  Fri Oct 22 00:55:04 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 22:55:04 +0000
Subject: [issue6878] changed return type from tkinter.Canvas.coords
In-Reply-To: <1252603508.57.0.591042976978.issue6878@psf.upfronthosting.co.za>
Message-ID: <1287701704.46.0.731598742663.issue6878@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.  Would look better with tests, and even slightly better with consistent indentation :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6878>
_______________________________________

From report at bugs.python.org  Fri Oct 22 01:13:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 23:13:06 +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: <1287702786.99.0.614907326517.issue9877@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Committed in distutils2/_backport/sysconfig.py as [4ef3e9e41c10].  I?ll push this week-end.

----------
components: +Distutils2
status: pending -> closed
versions: +3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9877>
_______________________________________

From report at bugs.python.org  Fri Oct 22 01:19:06 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 21 Oct 2010 23:19:06 +0000
Subject: [issue10147] Python Documentation bugs
In-Reply-To: <1287701465.77.0.122615919807.issue10147@psf.upfronthosting.co.za>
Message-ID: <4CC0CA66.6050104@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> Adjectives require hyphens but nouns do not.  ?thread-safety? should be reverted to ?thread safety?.  I haven?t searched for a grammar reference, but you can take Wikipedia as an example: ?Thread safety is a computer programming concept applicable in the context of multi-threaded programs. A piece of code is thread-safe if it functions correctly during simultaneous execution by multiple threads.?

Are you sure ?

http://en.wikipedia.org/wiki/English_compound#Types_of_compound_nouns

This appears to be more a question of personal style than a
grammar rule.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10147>
_______________________________________

From report at bugs.python.org  Fri Oct 22 01:43:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 23:43:10 +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: <1287704590.28.0.761460512593.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I think it is:

$ pwd
/tmp/?ric
$ LC_ALL=C ./python
Fatal Python error: Py_Initialize: Unable to get the locale encoding
SystemError: NULL result without error in PyObject_Call
Abandon

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri Oct 22 01:44:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 23:44:15 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287704655.34.0.160146436304.issue10126@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Applied on py3k in r85784.  I had no bug with 3.1, so I left things alone.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Fri Oct 22 01:45:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 23:45:11 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287704711.39.0.57049922011.issue10126@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

That was actually r85786.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Fri Oct 22 01:45:35 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 21 Oct 2010 23:45:35 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287704735.51.0.0655105264423.issue10126@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Fri Oct 22 02:03:32 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 22 Oct 2010 00:03:32 +0000
Subject: [issue10156] Memory leak (r70459)
In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>
Message-ID: <1287705812.96.0.350985343924.issue10156@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Re disabling interning in PyDict_SetItemString:

A comment in unicodeobject.c says that globals should not be used
before calling _PyUnicode_Init. But in Py_InitializeEx (pythonrun.c)
_PyUnicode_Init is called after _Py_ReadyTypes, _PyFrame_Init,
_PyLong_Init, PyByteArray_Init and _PyFloat_Init.

In fact, when I move _PyUnicode_Init up, the error concerning
_PyFloat_Init disappears.


Problem is, PyType_Ready also uses PyDict_SetItemString, but I
presume that _Py_ReadyTypes has to be called before anything else.
In that case it would be unavoidable that PyDict_SetItemString is
used before _PyUnicode_Init, and it might be a good idea to disable
interning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Fri Oct 22 02:45:27 2010
From: report at bugs.python.org (Maciek J)
Date: Fri, 22 Oct 2010 00:45:27 +0000
Subject: [issue10149] Data truncation in expat parser
In-Reply-To: <1287539001.05.0.466094845115.issue10149@psf.upfronthosting.co.za>
Message-ID: <1287708327.32.0.826524998411.issue10149@psf.upfronthosting.co.za>


Maciek J <egil at wp.pl> added the comment:

I'm not familiar with the rst format, but I hope this works.

----------
keywords: +patch
Added file: http://bugs.python.org/file19329/pyexpat.rst.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10149>
_______________________________________

From report at bugs.python.org  Fri Oct 22 03:03:10 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Oct 2010 01:03:10 +0000
Subject: [issue9167] argv double encoding on OSX
In-Reply-To: <1278346074.17.0.914375109611.issue9167@psf.upfronthosting.co.za>
Message-ID: <1287709390.24.0.712161685757.issue9167@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

rdmurray at buddy:~/python/py3k>uname -a
Darwin buddy.home.bitdance.com 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386


rdmurray at buddy:~/python/release31-maint>LC_ALL="C" ./python.exe
Python 3.1.2 (release31-maint:85783, Oct 21 2010, 20:31:06)
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys
>>> snowman = '\u2603'
>>> os.system(sys.executable + " -c 'import sys; [print(a.encode(\"utf8\")) for a in sys.argv]' foo bar " + snowman)
b'-c'
b'foo'
b'bar'
b'\xc3\xa2\xc2\x98\xc2\x83'
0


rdmurray at buddy:~/python/py3k>LC_ALL="C" ./python.exe 
Python 3.2a3+ (py3k:85768, Oct 21 2010, 12:31:12) 
[GCC 4.2.1 (Apple Inc. build 5659)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os, sys
>>> snowman = '\u2603'
>>> os.system(sys.executable + " -c 'import sys; [print(a.encode(\"utf8\")) for a in sys.argv]' foo bar " + snowman)
b'-c'
b'foo'
b'bar'
b'\xe2\x98\x83'
0

----------
nosy: +r.david.murray
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9167>
_______________________________________

From report at bugs.python.org  Fri Oct 22 04:34:26 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Fri, 22 Oct 2010 02:34:26 +0000
Subject: [issue10171] Ugly buttons in some Tkinter objects in Windows
In-Reply-To: <1287714866.92.0.753573590678.issue10171@psf.upfronthosting.co.za>
Message-ID: <1287714866.92.0.753573590678.issue10171@psf.upfronthosting.co.za>


New submission from Rafe Kettler <rafe.kettler at gmail.com>:

Some of the dialogs in Tkinter don't correctly show buttons in newer versions of Windows (XP, Vista, 7). Instead, they use square Win2000-and-before-type buttons. Here's some Python 2.7 code that illustrates this:

import tkMessageBox
tkMessageBox.showinfo()

import tkColorChooser
tkColorChooser.askcolor()

I attached a screenshot as well, illustrating what is meant by "ugly buttons."

I'm not sure if this is on the Tk or Tkinter side, but since the rest of Tkinter uses new-style buttons, these few objects should too (as far as I'm aware, these are the only objects that exhibit this behavior.

----------
components: Tkinter
files: uglybuttons.png
messages: 119359
nosy: rafe.kettler
priority: normal
severity: normal
status: open
title: Ugly buttons in some Tkinter objects in Windows
versions: Python 2.7, Python 3.1
Added file: http://bugs.python.org/file19330/uglybuttons.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10171>
_______________________________________

From report at bugs.python.org  Fri Oct 22 04:38:43 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Oct 2010 02:38:43 +0000
Subject: [issue10164] Add an assertBytesMultiLineEqual to unittest and use it
	for bytes assertEqual
In-Reply-To: <1287665297.21.0.48545376383.issue10164@psf.upfronthosting.co.za>
Message-ID: <1287715123.38.0.87162557324.issue10164@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

After talking with Michael on #python-dev, I've revised the patch to make it a real assertBytesEqual method rather than a pretend-the-bytes-are-strings method.  This version allows the byte strings to be split on an arbitrary byte string, which makes it more useful for getting diffs of structured binary data if that data has a convenient break point.  And the default is no splitting, which is what assertEqual uses when comparing bytes.

One of the tests is failing, and it's late and I can't figure out where the extra space is coming from.  Maybe someone else will check it out and spot the problem before I get back to it.

----------
Added file: http://bugs.python.org/file19331/assertBytesEqual.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10164>
_______________________________________

From report at bugs.python.org  Fri Oct 22 05:04:22 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Oct 2010 03:04:22 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287716662.44.0.978166224301.issue10093@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

After thinking about what warning to go with, I take back my python-dev suggestion of ResourceWarning and switch to DebugWarning. It is in fact harder to add in DebugWarning as a superclass to ResourceWarning than the other way around, especially once people start doing custom filters and decide that DebugWarning should not be filtered as a whole but ResourceWarning should (or some such crazy thing).

----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 22 08:11:07 2010
From: report at bugs.python.org (Vladimir Iofik)
Date: Fri, 22 Oct 2010 06:11:07 +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: <1287727867.68.0.136449898282.issue9291@psf.upfronthosting.co.za>


Vladimir Iofik <v-iofik at yandex.ru> added the comment:

Here is a better patch.

----------
nosy: +vj
Added file: http://bugs.python.org/file19332/9291a.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9291>
_______________________________________

From report at bugs.python.org  Fri Oct 22 08:28:13 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 22 Oct 2010 06:28:13 +0000
Subject: [issue10166] maximum recursion depth exceeded in lib\pstats.py
In-Reply-To: <1287676214.72.0.937902766344.issue10166@psf.upfronthosting.co.za>
Message-ID: <1287728893.34.0.550252326183.issue10166@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r85787.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10166>
_______________________________________

From report at bugs.python.org  Fri Oct 22 08:43:12 2010
From: report at bugs.python.org (Vladimir Iofik)
Date: Fri, 22 Oct 2010 06:43:12 +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: <1287729792.57.0.434221828315.issue9291@psf.upfronthosting.co.za>


Vladimir Iofik <v-iofik at yandex.ru> added the comment:

UnicodeDecodeException is thrown because 'ctype' is already a string, 
so it is first implicitly decoded by default encoder (which is 'ascii') and then reencoded back. I see no reason in all these actions, so I simply removed them. I think Antoine Pitrou (who is the author of these lines) can shed some light on this, but I guess it's just a copy-paste of the code below.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9291>
_______________________________________

From report at bugs.python.org  Fri Oct 22 10:01:52 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Fri, 22 Oct 2010 08:01:52 +0000
Subject: [issue10147] Python Documentation bugs
In-Reply-To: <4CC0CA66.6050104@egenix.com>
Message-ID: <AANLkTin+_B8_Lo=s+GMOnKX=819V1Vi2w4=i=ryEj90u@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

All the words that Georg Brandl fixed for this issue are okay as they stand.
Please leave them as they are written. Thank you.

On Fri, Oct 22, 2010 at 1:19 AM, Marc-Andre Lemburg
<report at bugs.python.org>wrote:

>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> ??ric Araujo wrote:
> >
> > ??ric Araujo <merwok at netwok.org> added the comment:
> >
> > Adjectives require hyphens but nouns do not.  ???thread-safety??? should be
> reverted to ???thread safety???.  I haven???t searched for a grammar reference,
> but you can take Wikipedia as an example: ???Thread safety is a computer
> programming concept applicable in the context of multi-threaded programs. A
> piece of code is thread-safe if it functions correctly during simultaneous
> execution by multiple threads.???
>
> Are you sure ?
>
> http://en.wikipedia.org/wiki/English_compound#Types_of_compound_nouns
>
> This appears to be more a question of personal style than a
> grammar rule.
>
> ----------
> nosy: +lemburg
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10147>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19333/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10147>
_______________________________________
-------------- next part --------------
All the words that Georg Brandl fixed for this issue are okay as they stand. Please leave them as they are written. Thank you.<br><br><div class="gmail_quote">On Fri, Oct 22, 2010 at 1:19 AM, Marc-Andre Lemburg <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Marc-Andre Lemburg &lt;<a href="mailto:mal at egenix.com">mal at egenix.com</a>&gt; added the comment:<br>
<div class="im"><br>
??ric Araujo wrote:<br>
&gt;<br>
&gt; ??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
&gt;<br>
&gt; Adjectives require hyphens but nouns do not. ?????thread-safety??? should be reverted to ???thread safety???. ??I haven???t searched for a grammar reference, but you can take Wikipedia as an example: ???Thread safety is a computer programming concept applicable in the context of multi-threaded programs. A piece of code is thread-safe if it functions correctly during simultaneous execution by multiple threads.???<br>

<br>
</div>Are you sure ?<br>
<br>
<a href="http://en.wikipedia.org/wiki/English_compound#Types_of_compound_nouns" target="_blank">http://en.wikipedia.org/wiki/English_compound#Types_of_compound_nouns</a><br>
<br>
This appears to be more a question of personal style than a<br>
grammar rule.<br>
<br>
----------<br>
nosy: +lemburg<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/issue10147" target="_blank">http://bugs.python.org/issue10147</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Fri Oct 22 10:35:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 08:35:28 +0000
Subject: [issue3902] distutils does not create __init__.py for packages
	containing extension modules
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1287736528.4.0.662038521665.issue3902@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  To the best of my knowledge, distutils never generates Python files, and the docs for ext_modules or ext_package don?t imply __init__.py will be generated.  IOW, for ?pkg.foo?, you?re supposed to have pkg/__init__.py and pkg/foo.c.

I think this bug is invalid, or is a request for a small doc improvement.  Do you agree?

----------
assignee: tarek -> eric.araujo
nosy: +eric.araujo -terry.reedy
title: distutils does not correctly create packages for compiled extensions -> distutils does not create __init__.py for packages containing extension modules

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Fri Oct 22 10:35:33 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 08:35:33 +0000
Subject: [issue3902] distutils does not create __init__.py for packages
	containing extension modules
In-Reply-To: <1221761506.23.0.180859211428.issue3902@psf.upfronthosting.co.za>
Message-ID: <1287736533.24.0.591725087545.issue3902@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg113049

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3902>
_______________________________________

From report at bugs.python.org  Fri Oct 22 10:45:41 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 22 Oct 2010 08:45:41 +0000
Subject: [issue7639] bdist_msi fails on files with long names
In-Reply-To: <1262718207.72.0.84290104112.issue7639@psf.upfronthosting.co.za>
Message-ID: <1287737141.55.0.204823590229.issue7639@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

Creating bdist_msi installers with files such as 'aixc++' (containing '+'), '.buildinfo' (starting with '.'), and 'py.~1.5.~' (containing '~') currently also fails, even with the proposed patch. 

The revised patch should fix these cases and further improves the make_short function to generate short names compatible with NTFS.

----------
Added file: http://bugs.python.org/file19334/msilib.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7639>
_______________________________________

From report at bugs.python.org  Fri Oct 22 10:51:54 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Oct 2010 08:51:54 +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: <1287737514.93.0.225020148311.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> $ LC_ALL=C ./python
> Fatal Python error: Py_Initialize: Unable to get the locale encoding
> SystemError: NULL result without error in PyObject_Call
> Abandon

What is your Python version? I fixed Python 3.2, but I don't plan to fix Python 3.1 for this problem (Python doesn't work if it is installed in a non-ascii directory).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri Oct 22 10:54:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 08:54:20 +0000
Subject: [issue7726] Remove required metadata warnings for sdist
In-Reply-To: <1263748397.28.0.736883943174.issue7726@psf.upfronthosting.co.za>
Message-ID: <1287737660.42.0.316049878057.issue7726@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t think warnings should be removed, at least not by default.  They?re warnings, not errors, which is IMO a nice compromise between accepting anything and requiring that rules be followed.  We could add an option like --no-warnings in distutils2, but I?m worried people could just disable it globally instead of fixing the actual problems.  I?m inclined to reject this report.  Tarek, opinion?

Since the warnings go to stderr, you can suppress them with shell redirection, although I wouldn?t advise that since you could miss unrelated warnings or errors.  Does that cover your need?

*musing* Maybe we could revamp the required fields.  Name and version are required by various distutils[2] and pkgutil APIs, so not setting them will screw up queries or uninstallation for example.  We could make distutils2 fail when they?re not present.  But then, why not fail if a distribution to be installed has the same name+version that an already present distribution?  What I?m saying is that it?s better to do no checks than incomplete checks, and this is the realm of a distribution manager, not the underlying library, but then again, distutils2 provides a simple distribution manager too, so I?m not sure this should be in or out of it, and at which level (lib/command/manager).

(Removing Terry from nosy at his request in private email.)

----------
nosy: +eric.araujo -terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7726>
_______________________________________

From report at bugs.python.org  Fri Oct 22 10:54:25 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 08:54:25 +0000
Subject: [issue7726] Remove required metadata warnings for sdist
In-Reply-To: <1263748397.28.0.736883943174.issue7726@psf.upfronthosting.co.za>
Message-ID: <1287737665.99.0.919342756028.issue7726@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg113019

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7726>
_______________________________________

From report at bugs.python.org  Fri Oct 22 10:56:30 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 08:56:30 +0000
Subject: [issue1274324] 'setup.py install' fail on linux from read-only storage
Message-ID: <1287737790.05.0.218557210596.issue1274324@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> eric.araujo
nosy:  -terry.reedy
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1274324>
_______________________________________

From report at bugs.python.org  Fri Oct 22 10:58:24 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 22 Oct 2010 08:58:24 +0000
Subject: [issue9167] argv double encoding on OSX
In-Reply-To: <1278346074.17.0.914375109611.issue9167@psf.upfronthosting.co.za>
Message-ID: <1287737904.5.0.87055353585.issue9167@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

FYI, you should use ascii() instead of a.encode(\"utf8\") to dump arguments. It's easier to check '\u2603' than b'\xe2\x98\x83' for me :-)

So the bug is fixed in Python 3.2, great! I was thinking that we need a test for that, but then I remembered that I already wrote such test :-) My test checks 3 unicode characters: \xe9, \u20ac, \U0010ffff; but also invalid byte sequences:

text = (
  b'\xff'         # invalid byte
  b'\xc3\xa9'     # valid utf-8 character
  b'\xc3\xff'     # invalid byte sequence
  b'\xed\xa0\x80' # lone surrogate character (invalid)
)

And it should be enough :-) See test_osx_utf8() of test_cmd_line to see the whole test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9167>
_______________________________________

From report at bugs.python.org  Fri Oct 22 11:02:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 09:02:09 +0000
Subject: [issue4032] distutils cannot recognize ".dll.a" as library on cygwin
In-Reply-To: <1223055534.39.0.439061882395.issue4032@psf.upfronthosting.co.za>
Message-ID: <1287738129.62.0.779597419702.issue4032@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Can you produce a patch?

(Removing Terry from nosy at his request)

----------
components: +Distutils2
nosy: +eric.araujo -terry.reedy
versions: +3rd party, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4032>
_______________________________________

From report at bugs.python.org  Fri Oct 22 11:02:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 09:02:18 +0000
Subject: [issue4032] distutils cannot recognize ".dll.a" as library on cygwin
In-Reply-To: <1223055534.39.0.439061882395.issue4032@psf.upfronthosting.co.za>
Message-ID: <1287738138.57.0.934542132926.issue4032@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
Removed message: http://bugs.python.org/msg113008

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4032>
_______________________________________

From report at bugs.python.org  Fri Oct 22 11:06:43 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 09:06:43 +0000
Subject: [issue5926] bdist_msi - add support for minimum Python version for
	pure Python packages
In-Reply-To: <1241465384.5.0.639061880588.issue5926@psf.upfronthosting.co.za>
Message-ID: <1287738403.89.0.184737891516.issue5926@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

distutils is frozen, new features land into distutils2 (http://bitbucket.org/tarek/distutils2/).  Do you want 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/issue5926>
_______________________________________

From report at bugs.python.org  Fri Oct 22 11:10:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 09:10:28 +0000
Subject: [issue5936] Add MSI suport for uninstalling individual versions
In-Reply-To: <1241490601.47.0.970158126843.issue5936@psf.upfronthosting.co.za>
Message-ID: <1287738628.42.0.489200817055.issue5936@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

?For example, if you installed a new version of Python, this would allow
you to add your already installed pure Python modules to this Python
installation by just going to Add/Remove Programs and selecting the
feature for the new version.?

Would you have to do this for every installed distribution?  Seems cumbersome.

distutils being feature-frozen, I?m reassigning to distutils2.  I?m willing to review a patch and test MSIs, and may even try to implement it myself to learn about MSI, but not before next year.

----------
assignee:  -> tarek
components: +Distutils2 -Distutils
nosy: +loewis -terry.reedy
versions: +3rd party -Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5936>
_______________________________________

From report at bugs.python.org  Fri Oct 22 11:19:02 2010
From: report at bugs.python.org (Christoph Gohlke)
Date: Fri, 22 Oct 2010 09:19:02 +0000
Subject: [issue1128] msilib.Directory.make_short only handles file names with
	a single dot in them
In-Reply-To: <1189179520.92.0.794860414513.issue1128@psf.upfronthosting.co.za>
Message-ID: <1287739142.85.0.660119827482.issue1128@psf.upfronthosting.co.za>


Christoph Gohlke <cgohlke at uci.edu> added the comment:

The revised patch for issue7639 now generates better short names for file names containing spaces, '+', and leading '.'.

http://bugs.python.org/file19334/msilib.diff

Test cases that could be added to MsilibTest.test_makeshort():

TEST          :  test
TES~1.T       :  t.e.s.t
TEST~1        :  .test
TESTTEST      :  testtest
TESTTE~1      :  .testtest
TESTTE~2      :  test test
TESTTE~3      :  test test test
AFILE~1.DOC   :  A file.doc
THISIS~1.TXT  :  This is a really long filename.123.456.789.txt
THISIS~1.789  :  This is a really long filename.123.456.7890
TEST__~1      :  test++
TE____~1      :  te++++++
TEST~1.__     :  test.++
TEST.123      :  test.123
TEST~1.123    :  test.1234
TEXT~1.123    :  text.1234
TESTTE~1.__   :  testtest.++
FOO.TXT       :  foo.txt
FOO2~1.TXT    :  foo.2.txt
SOMELO~1.TXT  :  someLongName.txt
SOMELO~2.TXT  :  someLongerName.txt
PY~15~1.~     :  py.~1.5.~

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1128>
_______________________________________

From report at bugs.python.org  Fri Oct 22 11:43:10 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 09:43:10 +0000
Subject: [issue1371826] distutils is silent about multiple -I/-L/-R
Message-ID: <1287740590.69.0.45232120503.issue1371826@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Skip, do you agree with my proposal (no behavior change in d1, better behavior in d2) or do you think it could be confusing?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1371826>
_______________________________________

From report at bugs.python.org  Fri Oct 22 11:58:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Oct 2010 09:58:56 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287741536.81.0.548650073736.issue10126@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You broke many 2.7, 3.1 and 3.x buildbots.

----------
priority: high -> critical
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Fri Oct 22 11:59:13 2010
From: report at bugs.python.org (Steven Bethard)
Date: Fri, 22 Oct 2010 09:59:13 +0000
Subject: [issue5936] Add MSI suport for uninstalling individual versions
In-Reply-To: <1241490601.47.0.970158126843.issue5936@psf.upfronthosting.co.za>
Message-ID: <1287741553.59.0.163820601817.issue5936@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

> Would you have to do this for every installed distribution?
> Seems cumbersome.

Well, the feature not being implemented yet, it's hard to tell what it would do. ;-) But I think the simplest approach would actually yield a dialog where you simply check off the versions of Python that you want the module installed to. (In MSI terminology, you'd be adding or removing "features".) So you *would* have to do this for every module you installed, but *not* for every (module, version) combination.

Now let's just hope that someone implements it in distutils2. ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5936>
_______________________________________

From report at bugs.python.org  Fri Oct 22 12:51:55 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 22 Oct 2010 10:51:55 +0000
Subject: [issue4032] distutils cannot recognize ".dll.a" as library on cygwin
In-Reply-To: <1223055534.39.0.439061882395.issue4032@psf.upfronthosting.co.za>
Message-ID: <1287744715.55.0.246255086838.issue4032@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I used to create the patch
http://bugs.python.org/file11597/experimental_distutils.patch
in #1706863, but cygwin guys wanted this code implemented
in CCygwinCompiler class (See #2445).

I think #2445 should be resolved before.

----------
dependencies: +Use The CygwinCCompiler Under Cygwin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4032>
_______________________________________

From report at bugs.python.org  Fri Oct 22 12:57:16 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 22 Oct 2010 10:57:16 +0000
Subject: [issue4032] distutils cannot recognize ".dll.a" as library on cygwin
In-Reply-To: <1223055534.39.0.439061882395.issue4032@psf.upfronthosting.co.za>
Message-ID: <1287745036.4.0.750375186086.issue4032@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Can you port that patch? I don't have cygwin installed now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4032>
_______________________________________

From report at bugs.python.org  Fri Oct 22 13:12:37 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 22 Oct 2010 11:12:37 +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: <1287745957.7.0.257164546961.issue10027@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I created test branch "branches/py3k-stat-on-windows" and
committed the new patch in r85789. This achieves msg119108.
I tested this on Windows7 buildbot where symlink support
exists, it seems working correct.
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/1840

----------
Added file: http://bugs.python.org/file19335/py3k_posixpath_traverse_via_DeviceIoControl.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10027>
_______________________________________

From report at bugs.python.org  Fri Oct 22 14:03:55 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Fri, 22 Oct 2010 12:03:55 +0000
Subject: [issue9289] test_long_key(test_winreg) fails on win2k + py2.x
In-Reply-To: <1279414134.03.0.595847788627.issue9289@psf.upfronthosting.co.za>
Message-ID: <1287749035.24.0.5726030466.issue9289@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I committed in r85790(release27-maint).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed
title: Skip test_long_key(test_winreg) on win2k + py2.x -> test_long_key(test_winreg) fails on win2k + py2.x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9289>
_______________________________________

From report at bugs.python.org  Fri Oct 22 14:14:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Oct 2010 12:14:06 +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: <1287749646.67.0.747732871566.issue10164@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
title: Add an assertBytesMultiLineEqual to unittest and use it for bytes assertEqual -> Add an assertBytesEqual to unittest and use it for bytes assertEqual

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10164>
_______________________________________

From report at bugs.python.org  Fri Oct 22 14:28:51 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 22 Oct 2010 12:28:51 +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: <1287750531.94.0.366204149945.issue10171@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +gpolo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10171>
_______________________________________

From report at bugs.python.org  Fri Oct 22 15:38:05 2010
From: report at bugs.python.org (Winston C. Yang)
Date: Fri, 22 Oct 2010 13:38:05 +0000
Subject: [issue10172] code block has no syntax coloring
In-Reply-To: <1287754685.88.0.964365557653.issue10172@psf.upfronthosting.co.za>
Message-ID: <1287754685.88.0.964365557653.issue10172@psf.upfronthosting.co.za>


New submission from Winston C. Yang <winston at cs.wisc.edu>:

The following code block in http://docs.python.org/tutorial/errors.html has no syntax coloring:

import sys

try:
    f = open('myfile.txt')
    s = f.readline()
    i = int(s.strip())
except IOError as (errno, strerror):
    print "I/O error({0}): {1}".format(errno, strerror)
except ValueError:
    print "Could not convert data to an integer."
except:
    print "Unexpected error:", sys.exc_info()[0]
    raise

----------
assignee: docs at python
components: Documentation
messages: 119382
nosy: docs at python, wcyang
priority: normal
severity: normal
status: open
title: code block has no syntax coloring
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10172>
_______________________________________

From report at bugs.python.org  Fri Oct 22 16:23:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 14:23:13 +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: <1287757393.81.0.0690040091627.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?m trying to build py3k on posix in a subdir called sep-build-dir-?ric, with locale set to C.  I get these errors:
gcc [...] -DSVNVERSION="\"`LC_ALL=C svnversion ..`\"" -o Modules/getbuildinfo.o ../Modules/getbuildinfo.c
svn: Error converting entry in directory '..' to UTF-8
svn: Can't convert string from native encoding to 'UTF-8':
svn: sep-build-dir-?\195?\169ric
[...]
gcc -pthread   -Xlinker -export-dynamic -o python Modules/python.o libpython3.2m.a -lpthread -ldl  -lutil   -lm  
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
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  Fri Oct 22 16:26:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 14:26:27 +0000
Subject: [issue9912] Fail when vsvarsall.bat produces stderr
In-Reply-To: <1285082676.18.0.058541871992.issue9912@psf.upfronthosting.co.za>
Message-ID: <1287757587.19.0.148465137676.issue9912@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I?d replace ?created stderr? with ?printed on stderr?, but otherwise msvc9_log.diff looks good.

distutils is feature-frozen, but I think any changes that help debugging are good.  Tarek, do you agree?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9912>
_______________________________________

From report at bugs.python.org  Fri Oct 22 16:27:09 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 14:27:09 +0000
Subject: [issue9912] Fail when vsvarsall.bat produces stderr
In-Reply-To: <1285082676.18.0.058541871992.issue9912@psf.upfronthosting.co.za>
Message-ID: <1287757629.68.0.941704023988.issue9912@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Distutils2
stage: needs patch -> patch review
versions: +3rd party -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9912>
_______________________________________

From report at bugs.python.org  Fri Oct 22 16:31:45 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 22 Oct 2010 14:31:45 +0000
Subject: [issue9912] Fail when vsvarsall.bat produces stderr
In-Reply-To: <1287757587.19.0.148465137676.issue9912@psf.upfronthosting.co.za>
Message-ID: <4CC1A04E.6060107@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

?ric Araujo wrote:
> 
> ?ric Araujo <merwok at netwok.org> added the comment:
> 
> I?d replace ?created stderr? with ?printed on stderr?, but otherwise msvc9_log.diff looks good.
> 
> distutils is feature-frozen, but I think any changes that help debugging are good.  Tarek, do you agree?

I hear you saying that a lot. Could you provide a reference to where
this was decided ?

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9912>
_______________________________________

From report at bugs.python.org  Fri Oct 22 16:39:12 2010
From: report at bugs.python.org (Stefan Krah)
Date: Fri, 22 Oct 2010 14:39:12 +0000
Subject: [issue10156] Initialization of globals in unicodeobject.c
In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>
Message-ID: <1287758352.38.0.41673734899.issue10156@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I've verified the leak manually. The cause is that global variables in
unicodeobject.c, e.g. free_list, are used before _PyUnicode_Init() is
called. Later on _PyUnicode_Init() sets these variables to NULL, losing
the allocated memory.

Here is an example of the earliest use of free_list during
_Py_ReadyTypes (),
well before _PyUnicode_Init():


Breakpoint 1, unicode_dealloc (unicode=0x1b044c0) at Objects/unicodeobject.c:392
392         switch (PyUnicode_CHECK_INTERNED(unicode)) {
(gdb) bt
#0  unicode_dealloc (unicode=0x1b044c0) at Objects/unicodeobject.c:392
#1  0x000000000044fc69 in PyUnicode_InternInPlace (p=0x7fff303852b8) at Objects/unicodeobject.c:9991
#2  0x000000000044fed3 in PyUnicode_InternFromString (cp=0x568861 "__len__") at Objects/unicodeobject.c:10025
#3  0x00000000004344d0 in init_slotdefs () at Objects/typeobject.c:5751
#4  0x0000000000434840 in add_operators (type=0x7be260) at Objects/typeobject.c:5905
#5  0x000000000042eec8 in PyType_Ready (type=0x7be260) at Objects/typeobject.c:3810
#6  0x000000000042edfc in PyType_Ready (type=0x7bde60) at Objects/typeobject.c:3774
#7  0x000000000041aa5f in _Py_ReadyTypes () at Objects/object.c:1514
#8  0x00000000004992ff in Py_InitializeEx (install_sigs=1) at Python/pythonrun.c:232
#9  0x000000000049957f in Py_Initialize () at Python/pythonrun.c:321
#10 0x00000000004b289f in Py_Main (argc=1, argv=0x1afa010) at Modules/main.c:590
#11 0x0000000000417dcc in main (argc=1, argv=0x7fff30385758) at ./Modules/python.c:59
(gdb) n
411         if (PyUnicode_CheckExact(unicode) &&
(gdb) 
414             if (unicode->length >= KEEPALIVE_SIZE_LIMIT) {
(gdb) 
419             if (unicode->defenc) {
(gdb) 
423             *(PyUnicodeObject **)unicode = free_list;
(gdb) n
424             free_list = unicode;
(gdb) n
425             numfree++;
(gdb) n
411         if (PyUnicode_CheckExact(unicode) &&


A possible fix could be to initialize the globals right at the start
in main.c. Note that there are still several Unicode API functions in
main.c before PyType_Ready has been called on the Unicode type.


With the patch, Valgrind does not show the leak any longer.

----------
keywords: +patch
priority: normal -> high
stage:  -> patch review
title: Memory leak (r70459) -> Initialization of globals in unicodeobject.c
Added file: http://bugs.python.org/file19336/unicode_init_globals.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Fri Oct 22 16:40:03 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 22 Oct 2010 14:40:03 +0000
Subject: [issue1371826] distutils is silent about multiple -I/-L/-R
Message-ID: <1287758403.95.0.759813653943.issue1371826@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I would prefer the gcc-like behavior.  I realize there
are constraints on making changes in distutils1, so what
you propose sounds fine to me.

----------
nosy: +skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1371826>
_______________________________________

From report at bugs.python.org  Fri Oct 22 16:40:21 2010
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 22 Oct 2010 14:40:21 +0000
Subject: [issue1371826] distutils is silent about multiple -I/-L/-R
Message-ID: <1287758421.78.0.950071149612.issue1371826@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
nosy:  -skip.montanaro

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1371826>
_______________________________________

From report at bugs.python.org  Fri Oct 22 16:55:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 14:55:38 +0000
Subject: [issue5342] distutils removing old files,
	deleting unneeded old files from installed location.
In-Reply-To: <1235256230.9.0.667035234316.issue5342@psf.upfronthosting.co.za>
Message-ID: <1287759338.84.0.591750314861.issue5342@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/issue5342>
_______________________________________

From report at bugs.python.org  Fri Oct 22 16:55:51 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 14:55:51 +0000
Subject: [issue4673] Distutils should provide an uninstall command
In-Reply-To: <1229380134.57.0.765808366709.issue4673@psf.upfronthosting.co.za>
Message-ID: <1287759351.58.0.391133967005.issue4673@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +distutils removing old files, deleting unneeded old files from installed location.

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4673>
_______________________________________

From report at bugs.python.org  Fri Oct 22 16:58:27 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 14:58:27 +0000
Subject: [issue1692592] Stripping debugging symbols from compiled C extensions
Message-ID: <1287759507.55.0.42626680925.issue1692592@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
assignee:  -> tarek
components: +Distutils2 -Distutils
nosy: +eric.araujo, tarek
stage: unit test needed -> patch review
versions: +3rd party -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692592>
_______________________________________

From report at bugs.python.org  Fri Oct 22 17:12:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 15:12:24 +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: <1287760344.16.0.826469196202.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Building in the same directory works.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri Oct 22 17:14:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 15:14:12 +0000
Subject: [issue4459] bdist_rpm should enable --fix-python by default
In-Reply-To: <1227969751.28.0.990351219395.issue4459@psf.upfronthosting.co.za>
Message-ID: <1287760452.53.0.580785789147.issue4459@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

FYI, this is fixed in the new bdist_rpm2 command: https://bitbucket.org/tarek/pypi2rpm/changeset/ce6626df0225

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4459>
_______________________________________

From report at bugs.python.org  Fri Oct 22 17:16:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 15:16:01 +0000
Subject: [issue808129] Change --changelog to accept files
Message-ID: <1287760561.93.0.194033216033.issue808129@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The feature freeze does apply.  Tarek has started a standalone project to build RPMs; I suggest you transfer this bug to https://bitbucket.org/tarek/pypi2rpm/

Happy hacking!

----------
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue808129>
_______________________________________

From report at bugs.python.org  Fri Oct 22 17:31:21 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 22 Oct 2010 15:31:21 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287761481.07.0.480954751882.issue10126@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: eric.araujo -> barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Fri Oct 22 17:48:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 15:48:08 +0000
Subject: [issue1649329] Support for non-filesystem-based catalogs in gettext
Message-ID: <1287762488.08.0.7420548647.issue1649329@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

The specific problem of gettext+eggs seems to be solved by this project: https://pypi.python.org/pypi/EggTranslations/

Since the egg format is not retained in distutils2, I don?t think any support for it should be added in the stdlib.

FWIW, I like the use of file-like objects to build Translation instances.  It?s easier to specify than a VFS and very versatile.

----------
components:  -Distutils
stage: unit test needed -> patch review
title: gettext.py incompatible with eggs -> Support for non-filesystem-based catalogs in gettext
versions: +Python 3.2 -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1649329>
_______________________________________

From report at bugs.python.org  Fri Oct 22 18:43:19 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Fri, 22 Oct 2010 16:43:19 +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: <1287765799.88.0.487798701722.issue10171@psf.upfronthosting.co.za>


Changes by Rafe Kettler <rafe.kettler at gmail.com>:


----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10171>
_______________________________________

From report at bugs.python.org  Fri Oct 22 19:21:11 2010
From: report at bugs.python.org (S S)
Date: Fri, 22 Oct 2010 17:21:11 +0000
Subject: [issue10106] missing packages
In-Reply-To: <1287074140.25.0.416505470052.issue10106@psf.upfronthosting.co.za>
Message-ID: <1287768071.11.0.339224276365.issue10106@psf.upfronthosting.co.za>


S S <senya72 at gmail.com> added the comment:

finally was able to figure it out.
i had another product installed, which uses python 2.4 that product during installation put PYTHONHOME into system variable environment. 

as soon as i either change that PYTHONHOME to my latest python path c:\python26 everything starts working.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10106>
_______________________________________

From report at bugs.python.org  Fri Oct 22 19:36:11 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 22 Oct 2010 17:36:11 +0000
Subject: [issue10126] test_distutils failure with --enable-shared
In-Reply-To: <1287260751.98.0.49456572991.issue10126@psf.upfronthosting.co.za>
Message-ID: <1287768971.94.0.613089670743.issue10126@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I believe all known failures in 2.7, 3.1, and 3.2 both with and without --enable-shared are now fixed.  Let's see what the buildbots say.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10126>
_______________________________________

From report at bugs.python.org  Fri Oct 22 19:37:08 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 17:37:08 +0000
Subject: [issue10090] python -m locale fails on OSX
In-Reply-To: <1286998392.83.0.0924618610068.issue10090@psf.upfronthosting.co.za>
Message-ID: <1287769028.89.0.216931385048.issue10090@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
dependencies: +locale.normalize strips "-" from UTF-8,	which fails on Mac

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10090>
_______________________________________

From report at bugs.python.org  Fri Oct 22 19:40:24 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 22 Oct 2010 17:40:24 +0000
Subject: [issue10155] Add fixups for encoding problems to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1287769224.85.0.917483581767.issue10155@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Your patch adds a new handler, which is arguably a new feature that has to be rejected in a bugfix branch.

----------
nosy: +eric.araujo
versions: +Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10155>
_______________________________________

From report at bugs.python.org  Fri Oct 22 20:04:52 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Oct 2010 18:04:52 +0000
Subject: [issue10156] Initialization of globals in unicodeobject.c
In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>
Message-ID: <1287770692.78.0.43937561904.issue10156@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

About the patch: why should _PyUnicode_Init() try to call _PyUnicode_InitGlobals() again?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Fri Oct 22 20:20:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Oct 2010 18:20:06 +0000
Subject: [issue5639] Support TLS SNI extension in ssl module
In-Reply-To: <1238567905.09.0.139467917453.issue5639@psf.upfronthosting.co.za>
Message-ID: <1287771606.51.0.735813735282.issue5639@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed with docs in r85793.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5639>
_______________________________________

From report at bugs.python.org  Fri Oct 22 20:45:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Oct 2010 18:45:47 +0000
Subject: [issue10115] Support accept4() for atomic setting of flags at socket
	creation
In-Reply-To: <1287149004.76.0.643231504051.issue10115@psf.upfronthosting.co.za>
Message-ID: <1287773147.37.0.706053775928.issue10115@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've removed the accept4() call in the meantime (in r85796), so that this issue can be re-classified as a feature request.

----------
priority: critical -> normal
title: accept4 can fail with errno 90 -> Support accept4() for atomic setting of flags at socket creation
type: behavior -> feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10115>
_______________________________________

From report at bugs.python.org  Fri Oct 22 21:02:09 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 22 Oct 2010 19:02:09 +0000
Subject: [issue5936] Add MSI suport for uninstalling individual versions
In-Reply-To: <1241490601.47.0.970158126843.issue5936@psf.upfronthosting.co.za>
Message-ID: <1287774129.03.0.737073009047.issue5936@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

It possible to script MSI, so that one could write a tool that manages all MSI files that have the multi-version feature, and add and remove them to Python installation in batches.

Alternatively, it would also be possible to integrate this into the Python installer, so that installation offers you to add a list of packages, and uninstallation removes all installations from the version (so that PythonXY could end up empty and get removed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5936>
_______________________________________

From report at bugs.python.org  Fri Oct 22 21:45:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Oct 2010 19:45:30 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1287776730.28.0.269134606081.issue9935@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85797.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9935>
_______________________________________

From report at bugs.python.org  Fri Oct 22 21:49:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Oct 2010 19:49:57 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287776997.87.0.743075126003.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> After thinking about what warning to go with, I take back my python-dev 
> suggestion of ResourceWarning and switch to DebugWarning.

So what is your advice now?
I've thought about the DebugWarning name myself and I think it's a rather bad name, because many warnings are debug-related in practice. I'd just say stick with ResourceWarning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 22 22:01:13 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Oct 2010 20:01:13 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287776997.87.0.743075126003.issue10093@psf.upfronthosting.co.za>
Message-ID: <AANLkTinBMU4mXdEDSRjQ-zHoTt1o-wEXAZCwSPR0M5H7@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Fri, Oct 22, 2010 at 12:49, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
>> After thinking about what warning to go with, I take back my python-dev
>> suggestion of ResourceWarning and switch to DebugWarning.
>
> So what is your advice now?
> I've thought about the DebugWarning name myself and I think it's a rather bad name, because many warnings are debug-related in practice. I'd just say stick with ResourceWarning.

That's true. And the warning hierarchy is rather shallow anyway. I'm
fine with ResourceWarning then.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 22 23:38:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Oct 2010 21:38:01 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1287783481.03.0.268066579322.issue9935@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The commit broke the Windows buildbots because (un)pickling a TextIOWrapper now raises an exception:

>>> f = open("LICENSE")
>>> pickle.dumps(f)
b'\x80\x03c_io\nTextIOWrapper\nq\x00)\x81q\x01}q\x02X\x04\x00\x00\x00modeq\x03X\x01\x00\x00\x00rq\x04sb.'
>>> g = pickle.loads(pickle.dumps(f))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: '_io.TextIOWrapper' object has no attribute '__dict__'


It should be noted that it didn't work before, but no exception was raised. The result was just nonsensical:

>>> f = open("LICENSE")
>>> pickle.dumps(f)
b'\x80\x03c_io\nTextIOWrapper\nq\x00)\x81q\x01.'
>>> g = pickle.loads(pickle.dumps(f))
>>> g
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on uninitialized object


The very fact that test_multiprocessing tries to pickle a file object is unfortunate, and is probably a bug in itself. test_multiprocessing is known for pickling lots of things, since it generally transfers a whole TestCase instance...

----------
assignee:  -> pitrou
nosy: +jnoller
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9935>
_______________________________________

From report at bugs.python.org  Sat Oct 23 00:02:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Oct 2010 22:02:49 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1287784969.67.0.0665364702615.issue9935@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The difference has to do with the result of __reduce__:

With the patch:

>>> open("LICENSE").__reduce_ex__(3)
(<function __newobj__ at 0x7fa392a0ff30>, (<class '_io.TextIOWrapper'>,), {'mode': 'r'}, None, None)

Without:

>>> open("LICENSE").__reduce_ex__(3)
(<function __newobj__ at 0x7f2cf2361a70>, (<class '_io.TextIOWrapper'>,), None, None, None)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9935>
_______________________________________

From report at bugs.python.org  Sat Oct 23 00:13:57 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 22 Oct 2010 22:13:57 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287785637.48.0.657862834659.issue10093@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

I wonder why you think a warning is needed if files aren't closed explicitly. The fact that they get closed on garbage collection is one of the nice features of Python and has made programming easy for years. 

Explicitly having to close files may have some benefits w/r to resource management, but in most cases is not needed. I disagree that we should discourage not explicitly closing files. After all, this is Python, not C.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Sat Oct 23 00:17:33 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Oct 2010 22:17:33 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1287785853.06.0.999498237481.issue10093@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

But this is meant to be an optional warning; users will never see it. Me as a developer, I would like to know when I leave a file open as that is a waste of resources, plus with no guarantee of everything being flushed to disk.

Besides, the context manager for files makes the chance of leaving a file open a much more blaring mistake.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Sat Oct 23 00:36:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Oct 2010 22:36:33 +0000
Subject: [issue10173] Don't pickle TestCase instances in test_multiprocessing
In-Reply-To: <1287786993.14.0.756780399794.issue10173@psf.upfronthosting.co.za>
Message-ID: <1287786993.14.0.756780399794.issue10173@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

unittest.TestCase instances aren't supposed to be picklable, but test_multiprocessing does it anyway (under Windows). Here is a patch.

----------
components: Tests
files: tmp.patch
keywords: patch
messages: 119407
nosy: asksol, jnoller, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Don't pickle TestCase instances in test_multiprocessing
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2
Added file: http://bugs.python.org/file19337/tmp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10173>
_______________________________________

From report at bugs.python.org  Sat Oct 23 00:41:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Oct 2010 22:41:42 +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: <1287787302.36.0.960096729284.issue10173@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +michael.foord

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10173>
_______________________________________

From report at bugs.python.org  Sat Oct 23 00:52:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 22 Oct 2010 22:52:01 +0000
Subject: [issue10143] Update "os.pathconf" values
In-Reply-To: <1287459031.95.0.424598520823.issue10143@psf.upfronthosting.co.za>
Message-ID: <1287787921.01.0.57836160716.issue10143@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> jcea

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10143>
_______________________________________

From report at bugs.python.org  Sat Oct 23 01:22:19 2010
From: report at bugs.python.org (Simon de Vlieger)
Date: Fri, 22 Oct 2010 23:22:19 +0000
Subject: [issue10174] multiprocessing expects sys.stdout to have a
	fileno/close method.
In-Reply-To: <1287789739.18.0.21420008091.issue10174@psf.upfronthosting.co.za>
Message-ID: <1287789739.18.0.21420008091.issue10174@psf.upfronthosting.co.za>


New submission from Simon de Vlieger <simon at ikanobori.jp>:

When I have replaced sys.stdin with my own file-like object and I try to do a multiprocessing.Pool(processes=x) I get errors about sys.stdin not having a fileno or close method.

For at least fileno it is described in the docs (http://docs.python.org/library/stdtypes.html#file-objects) that if your object is not a real file you should not implement it.

This happens to me on Mac OS X, I will add the traceback a bit later as I am currently not on my Mac.

----------
components: None
messages: 119408
nosy: ikanobori
priority: normal
severity: normal
status: open
title: multiprocessing expects sys.stdout to have a fileno/close method.
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10174>
_______________________________________

From report at bugs.python.org  Sat Oct 23 02:13:55 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Oct 2010 00:13:55 +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: <1287792835.68.0.232151933463.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I?m trying to build py3k on posix in a subdir called
> sep-build-dir-?ric, with locale set to C.

Ah yes, this particular use case doesn't work: r85800 should fix it. Please retry.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Sat Oct 23 02:42:19 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Sat, 23 Oct 2010 00:42:19 +0000
Subject: [issue10174] multiprocessing expects sys.stdout to have a
	fileno/close method.
In-Reply-To: <1287789739.18.0.21420008091.issue10174@psf.upfronthosting.co.za>
Message-ID: <1287794539.81.0.168985537448.issue10174@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/issue10174>
_______________________________________

From report at bugs.python.org  Sat Oct 23 03:02:24 2010
From: report at bugs.python.org (Tom Fogal)
Date: Sat, 23 Oct 2010 01:02:24 +0000
Subject: [issue10175] vs version for win32 compilation of extension modules is
	undocumented.
In-Reply-To: <1287795744.75.0.288699311556.issue10175@psf.upfronthosting.co.za>
Message-ID: <1287795744.75.0.288699311556.issue10175@psf.upfronthosting.co.za>


New submission from Tom Fogal <tfogal at alumni.unh.edu>:

I have recently attempted to install a couple third party packages (zope.interface and dulwech, FWIW) and encountered great difficulties.  In particular, the setup complained that it could not find "vcvarsall.bat".  Even running these setup scripts from a VC++ 2010 Express command shell gave the error.

Through browsing this bug database, specifically bugs 5235, 7511, and 2513, I have determined that the 'official' python.org binary is built with either VS 2008 or VS 2008 Express, I'm not sure which yet, but it does not really matter.

Setting DISTUTILS_USE_SDK and MSSdk to 1 and manually running the script, as suggested in one of the bug reports, does get by the issue of finding "vcvarsall.bat".  As one might guess, this only results in a confusing error message during compilation (c1010070, "Failed to load and parse the manifest"), presumably because vs2008 binaries are not compatible with vs2010 output files.

This bug isn't so much about the incompatibility as to the difficulty in diagnosing the issue.  It seems that trying to figure out which VS was used to compile a particular version of python is stored within a puzzle of bug reports.  Could this be listed on the download page, e.g.:

   http://www.python.org/download/releases/2.6.6/

?  Of course, it would be ideal if multiple binaries existed, so that someone in my position could say, "Oh, I don't even have 2008 installed; I should go with the 2010-compiled version", or vice-versa.  In the absence of that, simply knowing which version I'll need for extension modules is nice.

----------
components: Extension Modules
messages: 119410
nosy: tfogal
priority: normal
severity: normal
status: open
title: vs version for win32 compilation of extension modules is undocumented.
type: compile error
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10175>
_______________________________________

From report at bugs.python.org  Sat Oct 23 03:15:45 2010
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 23 Oct 2010 01:15:45 +0000
Subject: [issue10175] vs version for win32 compilation of extension modules is
	undocumented.
In-Reply-To: <1287795744.75.0.288699311556.issue10175@psf.upfronthosting.co.za>
Message-ID: <1287796545.22.0.92965336685.issue10175@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10175>
_______________________________________

From report at bugs.python.org  Sat Oct 23 04:10:00 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Sat, 23 Oct 2010 02:10:00 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287799800.31.0.075762814459.issue9778@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I maintain gmpy and it needs to calculate hash values for integers, floats, and rationals. I converted my hash calculations to use Py_ssize_t in a 64-bit Windows enviroment. All my tests pass when I build Python with my previous patch.

In hindsight, I think I made a mistake in my previous patch by eliminating Py_hash_t and using Py_ssize_t/size_t. I ended up defining Py_hash_t and Py_uhash_t in gmpy to simplify the code and to easily support older versions of Python.

I will work on a patch that defines Py_hash_t and Py_uhash_t and upload it later this evening.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 04:44:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Oct 2010 02:44:48 +0000
Subject: [issue10175] vs version for win32 compilation of extension modules is
	undocumented.
In-Reply-To: <1287795744.75.0.288699311556.issue10175@psf.upfronthosting.co.za>
Message-ID: <1287801888.05.0.692868695161.issue10175@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

If I understand correctly (I'm not a windows user or developer myself), knowing the bits necessary to compile extension modules is not something very many people need to know.  If an extension module supports Windows, there will generally be an installer package containing the binaries available.  If there isn't, chances are the extension module doesn't support Windows.

That said, improvements in the documentation is rarely a bad idea ;)

----------
assignee:  -> docs at python
components: +Documentation -Extension Modules
nosy: +docs at python, r.david.murray
type: compile error -> feature request
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10175>
_______________________________________

From report at bugs.python.org  Sat Oct 23 05:01:35 2010
From: report at bugs.python.org (Jeremy Kloth)
Date: Sat, 23 Oct 2010 03:01:35 +0000
Subject: [issue10175] vs version for win32 compilation of extension modules is
	undocumented.
In-Reply-To: <1287795744.75.0.288699311556.issue10175@psf.upfronthosting.co.za>
Message-ID: <1287802895.09.0.741994349358.issue10175@psf.upfronthosting.co.za>


Jeremy Kloth <jeremy.kloth at gmail.com> added the comment:

A quick look with Dependency Walker gives me the following:

Python 2.4,2.5 -- MSVC .NET 2003 (7.1)
Python 2.6,2.7,3.0,3.1 -- MSVC 2008 (9.0)

Note these are only for the official python.org builds.  Each version can also be built using other MSVC versions.  To the best of my knowledge Python 3.2 will also be built using MSVC 2008 as 2010 support hasn't been discussed yet.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10175>
_______________________________________

From report at bugs.python.org  Sat Oct 23 05:06:04 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 23 Oct 2010 03:06:04 +0000
Subject: [issue6639] turtle: _tkinter.TclError: invalid command name
	".10170160"
In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za>
Message-ID: <1287803164.24.0.667624457574.issue6639@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I have come across the same bug.  To reproduce, run Demo/turtle/tdemo_round_dance.py and kill the Tk window before the "dance" stops. 

The mysterious command name ".10170160" is simply the generated name for the canvas widget - '.' + repr(id(self)).  See BaseWidget.__init__ in tkinter.

----------
nosy: +belopolsky

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6639>
_______________________________________

From report at bugs.python.org  Sat Oct 23 05:35:40 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Sat, 23 Oct 2010 03:35:40 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287804940.89.0.155001814526.issue9778@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

I've uploaded a patch against the current svn trunk that:

1) Defines a Py_uhash_t as equivalent to size_t.
2) Correctly defines _PyHASH_MODULUS on Win64.
3) Replaces several PyLong_FromLong with PyLong_FromSsize_t.
4) Change typeobject/wrap_hashfunc to use Py_hash_t instead of long.
5) Change tupleobject/tuplehash to use Py_hast_t instead of long.
6) Change long/double/complex hash functions to use Py_uhash_t instead of unsigned long.

----------
Added file: http://bugs.python.org/file19338/Py_uhash_t_patch.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 06:09:07 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Oct 2010 04:09:07 +0000
Subject: [issue10118] Tkinter does not find font
In-Reply-To: <1287192630.89.0.924571330725.issue10118@psf.upfronthosting.co.za>
Message-ID: <1287806947.18.0.623771472262.issue10118@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.7 is in security-fix only mode. I am assuming that this is still a problem in 2.7 (and possibly 3.x). It would be good to confirm this.

----------
nosy: +terry.reedy
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10118>
_______________________________________

From report at bugs.python.org  Sat Oct 23 06:17:41 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Oct 2010 04:17:41 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287807461.6.0.205307870253.issue10160@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

>I am not sure whether I should attach a zip/tar file with both the attachments (the sample benchmark and the diff); so I'll attach the diff in a further comment.

Uploading separate files with .py, .diff extensions that can be viewed in a browser is indeed the right thing to do.\

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Sat Oct 23 06:24:49 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 23 Oct 2010 04:24:49 +0000
Subject: [issue10172] code block has no syntax coloring
In-Reply-To: <1287754685.88.0.964365557653.issue10172@psf.upfronthosting.co.za>
Message-ID: <1287807889.13.0.545935519007.issue10172@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

2.7 only (verified); 3.1 and 3.2 are fine.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10172>
_______________________________________

From report at bugs.python.org  Sat Oct 23 08:41:17 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Sat, 23 Oct 2010 06:41:17 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1287816077.83.0.656699651921.issue10160@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

A newer version of the patch with the following changes:

- single loop in the ag->attr setup phase of attrgetter_new; interning of the stored attribute names
- added two more tests of invalid attrgetter parameters (".attr", "attr.")

----------
Added file: http://bugs.python.org/file19339/issue10160-2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Sat Oct 23 10:30:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 23 Oct 2010 08:30: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: <1287822631.01.0.0388226797093.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Same errors.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Sat Oct 23 10:50:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Oct 2010 08:50:56 +0000
Subject: [issue10077] Python 3.1: site error is not logged
In-Reply-To: <1286923679.0.0.360055889779.issue10077@psf.upfronthosting.co.za>
Message-ID: <1287823856.12.0.945280920581.issue10077@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Commited to Python 3.1 (r85802).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10077>
_______________________________________

From report at bugs.python.org  Sat Oct 23 11:56:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 09:56:14 +0000
Subject: [issue10174] multiprocessing expects sys.stdout to have a
	fileno/close method.
In-Reply-To: <1287789739.18.0.21420008091.issue10174@psf.upfronthosting.co.za>
Message-ID: <1287827774.72.0.0675020077358.issue10174@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
components: +Library (Lib) -None
nosy: +asksol, jnoller
versions: +Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10174>
_______________________________________

From report at bugs.python.org  Sat Oct 23 12:29:54 2010
From: report at bugs.python.org (Ask Solem)
Date: Sat, 23 Oct 2010 10:29:54 +0000
Subject: [issue10174] multiprocessing expects sys.stdout to have a
	fileno/close method.
In-Reply-To: <1287789739.18.0.21420008091.issue10174@psf.upfronthosting.co.za>
Message-ID: <1287829794.43.0.684308368756.issue10174@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Please add the traceback,  I can't seem to find any obvious places where this would happen now.

Also, what version are you currently using?


I agree with the fileno, but I'd say close is a reasonable method to implement, especially for stdin/stdout/stderr

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10174>
_______________________________________

From report at bugs.python.org  Sat Oct 23 12:31:26 2010
From: report at bugs.python.org (ptz)
Date: Sat, 23 Oct 2010 10:31:26 +0000
Subject: [issue10176] telnetlib.Telnet.read_very_eager() performance
In-Reply-To: <1287829886.22.0.155091946841.issue10176@psf.upfronthosting.co.za>
Message-ID: <1287829886.22.0.155091946841.issue10176@psf.upfronthosting.co.za>


New submission from ptz <pptzpp at gmail.com>:

In Python 2.4, Assuming we've imported telnetlib, the following works:

    >>> f = telnetlib.Telnet("some_text_based_server")
    >>> f.read_very_eager()

The last call outputs the text that the server outputs upon connection (e.g. "login: ").

However, if we put this inside a function it does not work:

    >>> def g():
    ...   f = telnetlib.Telnet("server")
    ...   data = f.read_very_eager()
    ...   print data
    ...
    >>> g()

This returns the empty string. I believe this indicates that the data from the server isn't cooked. 

Note that if we use read_until() instead of read_very_eager(), everything works as expected, further supporting the hypothesis that data doesn't cook properly when the functions are called as above.

So why the difference?

----------
components: Library (Lib)
messages: 119423
nosy: ptz
priority: normal
severity: normal
status: open
title: telnetlib.Telnet.read_very_eager() performance
type: behavior
versions: 3rd party

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10176>
_______________________________________

From report at bugs.python.org  Sat Oct 23 14:21:38 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 23 Oct 2010 12:21:38 +0000
Subject: [issue10177] PyUnicode_AsWideCharString and PyMem_Free
In-Reply-To: <1287836498.58.0.900203329868.issue10177@psf.upfronthosting.co.za>
Message-ID: <1287836498.58.0.900203329868.issue10177@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp>:

Hello. I found several codes using PyMem_Free to free
allocated memory via PyUnicode_AsWideCharString.
In PyUnicode_AsWideCharString, memory is allocated
with PyMem_MALLOC. Is it OK to use PyMem_Free
not PyMem_FREE? Thank you.

----------
keywords: easy
messages: 119424
nosy: ocean-city
priority: normal
severity: normal
status: open
title: PyUnicode_AsWideCharString and PyMem_Free
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10177>
_______________________________________

From report at bugs.python.org  Sat Oct 23 14:49:31 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Oct 2010 12:49:31 +0000
Subject: [issue10176] telnetlib.Telnet.read_very_eager() performance
In-Reply-To: <1287829886.22.0.155091946841.issue10176@psf.upfronthosting.co.za>
Message-ID: <1287838171.46.0.776697174055.issue10176@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Presumably the difference is that there is a pause between the two statement executions at the interactive prompt (even if you cut and paste) that does not exist in the function.

----------
nosy: +r.david.murray
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10176>
_______________________________________

From report at bugs.python.org  Sat Oct 23 14:56:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Oct 2010 12:56:42 +0000
Subject: [issue10118] Tkinter does not find font
In-Reply-To: <1287192630.89.0.924571330725.issue10118@psf.upfronthosting.co.za>
Message-ID: <1287838602.68.0.773888432725.issue10118@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Terry meant 2.6 is in security fix only mode.  2.7 will get bug fixes for an extended period.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10118>
_______________________________________

From report at bugs.python.org  Sat Oct 23 16:05:25 2010
From: report at bugs.python.org (samwyse)
Date: Sat, 23 Oct 2010 14:05:25 +0000
Subject: [issue10178] PEP 378 uses replace where translate may work better
In-Reply-To: <1287842725.3.0.632950856337.issue10178@psf.upfronthosting.co.za>
Message-ID: <1287842725.3.0.632950856337.issue10178@psf.upfronthosting.co.za>


New submission from samwyse <samwyse at gmail.com>:

PEP 378 states;

  format(n, "6,f").replace(",", "X").replace(".", ",").replace("X", ".")

This is complex and relatively slow.  A better technique, which IMHO the proposal should high-lighted, would be:

  swap_commas_and_periods = bytes.maketrans(b',.', b'.,')
  format(n, "6,f").translate(swap_commas_and_periods)

While performing the maketrans each time a string is formatted is slower than the triple replace, calling it once and caching the result is faster.  I have tested with with the 3.1 interpreter; example timings follow.

>>> Timer("""
  '1,234,567.89'.replace(',', 'X').replace('.', ',').replace('X', '.')
""").timeit()
3.0645400462908015

>>> Timer("""
  '1,234,567.89'.translate(swap_commas_and_periods)
""", """
  swap_commas_and_periods = bytes.maketrans(b',.', b'.,')
""").timeit()
2.276630409730846


>>> Timer("""
  '1,234,567.89'.translate(bytes.maketrans(b',.', b'.,'))
""").timeit()
3.760715677551161

----------
assignee: docs at python
components: Documentation
messages: 119427
nosy: docs at python, samwyse
priority: normal
severity: normal
status: open
title: PEP 378 uses replace where translate may work better
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10178>
_______________________________________

From report at bugs.python.org  Sat Oct 23 16:16:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Oct 2010 14:16:42 +0000
Subject: [issue7761] telnetlib Telnet.interact fails on Windows but not Linux
In-Reply-To: <1264212900.62.0.226780855818.issue7761@psf.upfronthosting.co.za>
Message-ID: <1287843402.08.0.84875964725.issue7761@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The attached patch should fix the problem.  It replicates the bytes/string changes made for the unix branch in the windows branch.

It would be nice to come up with a unit test for this, but in this case that's a lot more complicated than figuring out the fix :)

----------
keywords: +patch
nosy: +r.david.murray
Added file: http://bugs.python.org/file19340/telnetlib_windows.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7761>
_______________________________________

From report at bugs.python.org  Sat Oct 23 16:30:26 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Oct 2010 14:30:26 +0000
Subject: [issue10178] PEP 378 uses replace where translate may work better
In-Reply-To: <1287842725.3.0.632950856337.issue10178@psf.upfronthosting.co.za>
Message-ID: <1287844226.63.0.798539777719.issue10178@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The text in question is talking about 'replace' as a general mechanism for 'fixing' the separator character, and as such I don't think introducing translate would enhance the exposition.  I suppose it could be added in a footnote.

----------
nosy: +eric.smith, ncoghlan, r.david.murray, rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10178>
_______________________________________

From report at bugs.python.org  Sat Oct 23 16:52:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 14:52:04 +0000
Subject: [issue10179] os.stat fails on mapped network drive
In-Reply-To: <1287845524.9.0.573963701431.issue10179@psf.upfronthosting.co.za>
Message-ID: <1287845524.9.0.573963701431.issue10179@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This network drive is actually mapped through the VirtualBox guest additions. Under Python 2.7 (official 64-bit MSI installer), this works fine:

>>> s = 'Z:\\__svn__\\Lib\\test\\keycert.pem'
>>> os.stat(s)
nt.stat_result(st_mode=33206, st_ino=0L, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=1783L, st_atime=1287771307L, st_mtime=1286578916L, st_ctime=1286578916L)

Under a freshly compiled 32-bit py3k, though, it fails with a rather strange error message:

>>> s = 'Z:\\__svn__\\Lib\\test\\keycert.pem'
>>> os.stat(s)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 1] Incorrect function: 'Z:\\__svn__\\Lib\\test\\keycert.pem'
>>> errno.errorcode[1]
'EPERM'

While a local directory works fine:

>>> os.stat('c:\\Windows')
nt.stat_result(st_mode=16895, st_ino=0, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=16384, st_atime=1287843075, st_mtime=1287843075, st_ctime=1247541608)

----------
components: Extension Modules
messages: 119430
nosy: brian.curtin, ocean-city, pitrou, tim.golden
priority: critical
severity: normal
status: open
title: os.stat fails on mapped network drive
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10179>
_______________________________________

From report at bugs.python.org  Sat Oct 23 16:59:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 14:59:31 +0000
Subject: [issue10179] os.stat fails on mapped network drive
In-Reply-To: <1287845524.9.0.573963701431.issue10179@psf.upfronthosting.co.za>
Message-ID: <1287845971.19.0.759855638866.issue10179@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

And 3.1 works fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10179>
_______________________________________

From report at bugs.python.org  Sat Oct 23 17:09:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 15:09:59 +0000
Subject: [issue10179] os.stat fails on mapped network drive
In-Reply-To: <1287845524.9.0.573963701431.issue10179@psf.upfronthosting.co.za>
Message-ID: <1287846599.01.0.627107716718.issue10179@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hmm, it looks like this is actually VirtualBox-specific.
It works with another network drive mapped on Y:

>>> os.stat(r"y:")
nt.stat_result(st_mode=16895, st_ino=0, st_dev=0, st_nlink=0, st_uid=0, st_gid=0, st_size=0, st_atime=1287784175, st_mtime=1281439296, st_ctime=1281439296)
>>> os.stat(r"z:")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
WindowsError: [Error 1] Incorrect function: 'z:'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10179>
_______________________________________

From report at bugs.python.org  Sat Oct 23 17:27:32 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Oct 2010 15:27:32 +0000
Subject: [issue6668] locale.py: can't parse sr_RS@latin locale
In-Reply-To: <1249655674.35.0.635015975428.issue6668@psf.upfronthosting.co.za>
Message-ID: <1287847652.31.0.933563246569.issue6668@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Python 3.2a3+ (py3k:85670:85675M, Oct 17 2010, 20:27:19) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL)
'LC_CTYPE=sr_RS at latin;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C'


rdmurray at hey:~/maestro/python/release31-maint>LC_ALL="sr_RS at latin" ./python
Python 3.1.2 (release31-maint:85675M, Oct 17 2010, 20:16:54) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL)
'LC_CTYPE=sr_RS at latin;LC_NUMERIC=C;LC_TIME=C;LC_COLLATE=C;LC_MONETARY=C;LC_MESSAGES=C;LC_PAPER=C;LC_NAME=C;LC_ADDRESS=C;LC_TELEPHONE=C;LC_MEASUREMENT=C;LC_IDENTIFICATION=C'


rdmurray at hey:~/maestro/python/release27-maint>LC_ALL="sr_RS at latin" ./python
Python 2.7.0+ (release27-maint:85802, Oct 23 2010, 11:15:26) 
[GCC 4.4.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL)
'C'
>>> locale.setlocale(locale.LC_ALL, 'sr_RS at latin')
'sr_RS at latin'

----------
nosy: +r.david.murray
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6668>
_______________________________________

From report at bugs.python.org  Sat Oct 23 17:39:19 2010
From: report at bugs.python.org (ptz)
Date: Sat, 23 Oct 2010 15:39:19 +0000
Subject: [issue10176] telnetlib.Telnet.read_very_eager() performance
In-Reply-To: <1287829886.22.0.155091946841.issue10176@psf.upfronthosting.co.za>
Message-ID: <1287848359.31.0.474074163769.issue10176@psf.upfronthosting.co.za>


ptz <pptzpp at gmail.com> added the comment:

Strange. I was certain that I tried inserting a time.sleep() in the function and it still didn't work, but I tried it just now and it does work as expected. Sorry, and thanks for your answer, at least I learned something.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10176>
_______________________________________

From report at bugs.python.org  Sat Oct 23 17:41:42 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 23 Oct 2010 15:41:42 +0000
Subject: [issue10157] Refleaks in pythonrun.c
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1287848502.7.0.861468926575.issue10157@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

After taking the scenic route through half of the tree[1], I finally
found another leak in pythonrun.c. I'm closing #10153, merging those
two leaks into the new patch.


Does it look ok?


[1] Valgrind stack traces should be approached with caution.

----------
stage:  -> patch review
title: Memory leak (r70152) -> Refleaks in pythonrun.c
Added file: http://bugs.python.org/file19341/pythonrun3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10157>
_______________________________________

From report at bugs.python.org  Sat Oct 23 17:43:37 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 23 Oct 2010 15:43:37 +0000
Subject: [issue10153] Memory leak in pythonrun.c
In-Reply-To: <1287572976.12.0.192446732245.issue10153@psf.upfronthosting.co.za>
Message-ID: <1287848617.54.0.527019476832.issue10153@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
resolution:  -> duplicate
stage: patch review -> committed/rejected
status: open -> closed
superseder:  -> Refleaks in pythonrun.c

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10153>
_______________________________________

From report at bugs.python.org  Sat Oct 23 17:52:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Oct 2010 15:52:38 +0000
Subject: [issue10176] telnetlib.Telnet.read_very_eager() performance
In-Reply-To: <1287829886.22.0.155091946841.issue10176@psf.upfronthosting.co.za>
Message-ID: <1287849158.37.0.297624931167.issue10176@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, perhaps when you ran the test with the sleep the target server had an unusually long startup delay.  If you are going to use read_very_eager you are going to have to deal with the possibility of not getting back what you expected, so it doesn't really matter what it's "performance" is :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10176>
_______________________________________

From report at bugs.python.org  Sat Oct 23 17:56:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 Oct 2010 15:56:17 +0000
Subject: [issue10179] os.stat fails on mapped network drive
In-Reply-To: <1287845524.9.0.573963701431.issue10179@psf.upfronthosting.co.za>
Message-ID: <1287849377.29.0.945108208436.issue10179@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Let me guess: It's GetFinalPathNameByHandle that is failing. Put some debug output right after the call to verify.

Why is this critical? Not being able to stat VirtualBox folders doesn't sound that critical to me.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10179>
_______________________________________

From report at bugs.python.org  Sat Oct 23 17:58:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 15:58:01 +0000
Subject: [issue10179] os.stat fails on mapped network drive
In-Reply-To: <1287845524.9.0.573963701431.issue10179@psf.upfronthosting.co.za>
Message-ID: <1287849481.76.0.546862903371.issue10179@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Yes, indeed. It was critical before I found out that it's VirtualBox-specific.

----------
priority: critical -> normal

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10179>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:08:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 16:08:56 +0000
Subject: [issue10179] os.stat fails on mapped network drive
In-Reply-To: <1287845524.9.0.573963701431.issue10179@psf.upfronthosting.co.za>
Message-ID: <1287850136.8.0.10683542158.issue10179@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch seems to do the trick, although I'm not sure it warrants including in Python.

----------
keywords: +patch
Added file: http://bugs.python.org/file19342/osstat.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10179>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:10:56 2010
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Sat, 23 Oct 2010 16:10:56 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1287850256.78.0.141134426252.issue6058@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

This problem causes {{{os.getcwdu()}}} to fail when the console code page is set to 65001 (always, I think):
{{{
t:\>ver

Microsoft Windows [Version 6.0.6002]

t:\>chcp
Active code page: 65001

t:\>python -c "import os; print os.getcwdu()"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
LookupError: unknown encoding: cp65001

t:\>chcp 1252
Active code page: 1252

t:\>python -c "import os; print os.getcwdu()"
t:\
}}}

Incidentally, I don't agree that this codepage needs to be distinguished from UTF-8. The deviations in the Microsoft codec are just their bugs. There is only one correct way to encode/decode UTF-8, and cp65001 is supposed to be UTF-8 according to Microsoft (e.g. http://msdn.microsoft.com/en-us/library/86hf4sb8%28en-US,VS.80%29.aspx ).

----------
nosy: +davidsarah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:13:09 2010
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Sat, 23 Oct 2010 16:13:09 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1287850389.05.0.249417140058.issue6058@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

I said: "There is only one correct way to encode/decode UTF-8". This is true modulo differences in the treatment of initial byte order marks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:21:02 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Oct 2010 16:21:02 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287850862.85.0.839565545942.issue9778@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Thank you. Applied in r85803.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:23:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 16:23:35 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287851015.83.0.0947346145268.issue9778@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Case's patch fixes test_builtin and test_complex failures on Windows 7 64-bit. But there's still a failure in test_dictviews:

======================================================================
FAIL: test_items_set_operations (test.test_dictviews.DictSetTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Z:\__svn__\lib\test\test_dictviews.py", line 153, in test_items_set_operations
    {('a', 1), ('b', 2)})
AssertionError: Items in the first set but not the second:
('a', 1)
('b', 2)

----------------------------------------------------------------------

Which boils down to the following issue:

>>> d1 = {'a': 1, 'b': 2}
>>> d1.items()
dict_items([('a', 1), ('b', 2)])
>>> set(d1.items())
{('a', 1), ('b', 2)}
>>> d1.items() | set(d1.items())
{('a', 1), ('a', 1), ('b', 2), ('b', 2)}


There are also a bunch of possibly related failures in test_weakset:

======================================================================
FAIL: test_inplace_on_self (test.test_weakset.TestWeakSet)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_weakset.py", line 293, in test_inplace_on_
self
    self.assertEqual(t, self.s)
AssertionError: <_weakrefset.WeakSet object at 0x000000000283CDC0> != <_weakrefs
et.WeakSet object at 0x000000000283B2C8>

======================================================================
FAIL: test_or (test.test_weakset.TestWeakSet)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_weakset.py", line 72, in test_or
    self.assertEqual(self.s | set(self.items2), i)
AssertionError: <_weakrefset.WeakSet object at 0x000000000285B400> != <_weakrefs
et.WeakSet object at 0x000000000285B260>

======================================================================
FAIL: test_symmetric_difference (test.test_weakset.TestWeakSet)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_weakset.py", line 110, in test_symmetric_d
ifference
    self.assertEqual(c in i, (c in self.d) ^ (c in self.items2))
AssertionError: False != True

======================================================================
FAIL: test_union (test.test_weakset.TestWeakSet)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_weakset.py", line 61, in test_union
    self.assertEqual(c in u, c in self.d or c in self.items2)
AssertionError: False != True

======================================================================
FAIL: test_xor (test.test_weakset.TestWeakSet)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_weakset.py", line 117, in test_xor
    self.assertEqual(self.s ^ set(self.items2), i)
AssertionError: <_weakrefset.WeakSet object at 0x000000000292CA18> != <_weakrefs
et.WeakSet object at 0x000000000292C878>


Another bunch of test_pyclbr failures:

======================================================================
FAIL: test_decorators (test.test_pyclbr.PyclbrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_pyclbr.py", line 152, in test_decorators
    self.checkModule('test.pyclbr_input', ignore=['om'])
  File "Y:\py3k\__svn__\lib\test\test_pyclbr.py", line 101, in checkModule
    self.assertListEq(real_bases, pyclbr_bases, ignore)
  File "Y:\py3k\__svn__\lib\test\test_pyclbr.py", line 28, in assertListEq
    self.fail("%r missing" % missing.pop())
AssertionError: 'object' missing

======================================================================
FAIL: test_easy (test.test_pyclbr.PyclbrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_pyclbr.py", line 142, in test_easy
    self.checkModule('pyclbr')
  File "Y:\py3k\__svn__\lib\test\test_pyclbr.py", line 101, in checkModule
    self.assertListEq(real_bases, pyclbr_bases, ignore)
  File "Y:\py3k\__svn__\lib\test\test_pyclbr.py", line 28, in assertListEq
    self.fail("%r missing" % missing.pop())
AssertionError: 'object' missing

======================================================================
FAIL: test_others (test.test_pyclbr.PyclbrTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_pyclbr.py", line 158, in test_others
    cm('random', ignore=('Random',))  # from _random import Random as CoreGenera
tor
  File "Y:\py3k\__svn__\lib\test\test_pyclbr.py", line 101, in checkModule
    self.assertListEq(real_bases, pyclbr_bases, ignore)
  File "Y:\py3k\__svn__\lib\test\test_pyclbr.py", line 28, in assertListEq
    self.fail("%r missing" % missing.pop())
AssertionError: 'Random' missing


And a test_sys failure which is probably easy to fix:

  File "Z:\__svn__\lib\test\test_sys.py", line 831, in test_objecttypes
    check(s, basicsize)
  File "Z:\__svn__\lib\test\test_sys.py", line 601, in check_sizeof
    self.assertEqual(result, size, msg)
AssertionError: wrong size for <class 'str'>: got 74, expected 66


All these tests pass in 32-bit mode.
Case, you can run the regression test suite with:
  python.exe -m test.regrtest
and invidual tests with e.g.:
  python.exe -m test.regrtest -v test_dictviews

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:23:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 16:23:42 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287851022.01.0.726465355005.issue9778@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:25:11 2010
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Sat, 23 Oct 2010 16:25:11 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1287851111.13.0.00901058697738.issue6058@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

I meant to say that the os.getcwdu() test in msg119440 was done with Windows native Python 2.6.2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:32:44 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 23 Oct 2010 16:32:44 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287851564.63.0.612571355416.issue9778@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:35:50 2010
From: report at bugs.python.org (samwyse)
Date: Sat, 23 Oct 2010 16:35:50 +0000
Subject: [issue10178] PEP 378 uses replace where translate may work better
In-Reply-To: <1287842725.3.0.632950856337.issue10178@psf.upfronthosting.co.za>
Message-ID: <1287851750.42.0.697699051713.issue10178@psf.upfronthosting.co.za>


samwyse <samwyse at gmail.com> added the comment:

The text in question is also talking about the problems with using 'replace' to swap pairs of characters, so a better, alternate, process would be valuable, especially for anyone unaware of the translate method.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10178>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:40:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 16:40:37 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287852037.09.0.400118268354.issue9778@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This patch seems to fix all aforementioned failures.

----------
Added file: http://bugs.python.org/file19343/hashw64.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:40:50 2010
From: report at bugs.python.org (David-Sarah Hopwood)
Date: Sat, 23 Oct 2010 16:40:50 +0000
Subject: [issue6058] Add cp65001 to encodings/aliases.py
In-Reply-To: <1242692494.35.0.391765957832.issue6058@psf.upfronthosting.co.za>
Message-ID: <1287852050.14.0.135475447604.issue6058@psf.upfronthosting.co.za>


David-Sarah Hopwood <david-sarah at jacaranda.org> added the comment:

Oops, false alarm. python -c "import os; print repr(os.getcwdu())" works as expected, so the exception is part of issue 1602.

(My command about there being no need to distinguish this codepage from UTF-8 stands.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6058>
_______________________________________

From report at bugs.python.org  Sat Oct 23 18:51:20 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sat, 23 Oct 2010 16:51:20 +0000
Subject: [issue7761] telnetlib Telnet.interact fails on Windows but not Linux
In-Reply-To: <1264212900.62.0.226780855818.issue7761@psf.upfronthosting.co.za>
Message-ID: <1287852680.78.0.370279201228.issue7761@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

The patch works. I agree that no test is needed, since no one will
attempt to revert this. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7761>
_______________________________________

From report at bugs.python.org  Sat Oct 23 19:04:23 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sat, 23 Oct 2010 17:04:23 +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: <1287853463.44.0.492949143938.issue6011@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> Same errors.

Please describe exactly how you reproduced the error (write each command).

r85805 fixes another bug related to this problem. Is it a better fix than distutils_makefile_encoding.patch: use surrogateescape error handler to decode the Makefile file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Sat Oct 23 19:19:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 17:19:27 +0000
Subject: [issue10180] File objects should not pickleable
In-Reply-To: <1287854367.84.0.526587779087.issue10180@psf.upfronthosting.co.za>
Message-ID: <1287854367.84.0.526587779087.issue10180@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

In Python 3, pickle accepts to serialize a file object, but the result is nonsensical when unpickled. I think we should explicitly forbid pickling of FileIO, Buffered{Reader,Writer} and TextIOWrapper objects.

----------
components: IO, Library (Lib)
messages: 119450
nosy: alexandre.vassalotti, amaury.forgeotdarc, benjamin.peterson, pitrou
priority: normal
severity: normal
status: open
title: File objects should not pickleable
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10180>
_______________________________________

From report at bugs.python.org  Sat Oct 23 19:31:59 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Oct 2010 17:31:59 +0000
Subject: [issue6518] Enable 'with' statement in ossaudiodev module
In-Reply-To: <1247965666.73.0.755368316919.issue6518@psf.upfronthosting.co.za>
Message-ID: <1287855119.47.0.328569696693.issue6518@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied (with new test, and docs) in r85807.  I also removed the AttributeError catch.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6518>
_______________________________________

From report at bugs.python.org  Sat Oct 23 19:33:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Oct 2010 17:33:25 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1287855205.09.0.232404670199.issue5178@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ping... soon it's too late for 3.2 too :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5178>
_______________________________________

From report at bugs.python.org  Sat Oct 23 19:34:12 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 Oct 2010 17:34:12 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287855252.77.0.283414466695.issue9778@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

These changes also look all reasonable to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 19:36:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Oct 2010 17:36:27 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1287855387.62.0.948426079808.issue8777@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ping -- is this something you want in 3.2, Kristjan?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Sat Oct 23 19:38:07 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 Oct 2010 17:38:07 +0000
Subject: [issue10179] os.stat fails on mapped network drive
In-Reply-To: <1287845524.9.0.573963701431.issue10179@psf.upfronthosting.co.za>
Message-ID: <1287855487.57.0.813451628454.issue10179@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think something like this is worth adding. I'd like to see two changes implemented:
- GetLastError should be checked for the "not implemented or some such" error that you got, and the fallback only performed if its this error
- a comment explaining the motivation for this fallback should be added.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10179>
_______________________________________

From report at bugs.python.org  Sat Oct 23 19:38:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 17:38:56 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287855536.13.0.198989981106.issue9778@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, I've committed them in r85808.

----------
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 19:50:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Oct 2010 17:50:27 +0000
Subject: [issue10180] File objects should not pickleable
In-Reply-To: <1287854367.84.0.526587779087.issue10180@psf.upfronthosting.co.za>
Message-ID: <1287856227.25.0.397877918945.issue10180@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sounds like a good idea to me.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10180>
_______________________________________

From report at bugs.python.org  Sat Oct 23 20:07:33 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 23 Oct 2010 18:07:33 +0000
Subject: [issue10179] os.stat fails on mapped network drive
In-Reply-To: <1287845524.9.0.573963701431.issue10179@psf.upfronthosting.co.za>
Message-ID: <1287857253.28.0.199693443808.issue10179@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Can you try my patch in #10027? Does this also fail?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10179>
_______________________________________

From report at bugs.python.org  Sat Oct 23 20:10:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 18:10:52 +0000
Subject: [issue10180] File objects should not pickleable
In-Reply-To: <1287854367.84.0.526587779087.issue10180@psf.upfronthosting.co.za>
Message-ID: <1287857452.64.0.178527972527.issue10180@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a patch, but issue10173 must probably be fixed first.

----------
dependencies: +Don't pickle TestCase instances in test_multiprocessing
keywords: +patch
Added file: http://bugs.python.org/file19344/pickleio.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10180>
_______________________________________

From report at bugs.python.org  Sat Oct 23 20:22:39 2010
From: report at bugs.python.org (Roger Upole)
Date: Sat, 23 Oct 2010 18:22:39 +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: <1287858158.95.0.0752296181045.issue10181@psf.upfronthosting.co.za>


New submission from Roger Upole <rupole at hotmail.com>:

There are a number of places in memoryobject.c where get_shape0 is used without the return value being checked.  If it fails, this leads to hanging exceptions and crashes.

----------
components: Interpreter Core
messages: 119460
nosy: rupole
priority: normal
severity: normal
status: open
title: get_shape0 in memoryobject.c not checked for error return
type: crash
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10181>
_______________________________________

From report at bugs.python.org  Sat Oct 23 20:22:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 18:22:53 +0000
Subject: [issue10179] os.stat fails on mapped network drive
In-Reply-To: <1287857253.28.0.199693443808.issue10179@psf.upfronthosting.co.za>
Message-ID: <1287858169.3611.10.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Can you try my patch in #10027? Does this also fail?

No, your patch seems to fix the issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10179>
_______________________________________

From report at bugs.python.org  Sat Oct 23 20:37:51 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 Oct 2010 18:37:51 +0000
Subject: [issue10182] match_start truncates large values
In-Reply-To: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za>
Message-ID: <1287859071.54.0.617398147143.issue10182@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

_sre.c:match_start currently uses Py_BuildValue("i") to return the start index, which itself is of type Py_ssize_t. This will get truncated on x64 Windows if the start is > 2**31. PyInt_FromSsize_t should be used instead. Other usages of Py_BuildValue should be reviewed as well.

----------
messages: 119462
nosy: loewis
priority: normal
severity: normal
status: open
title: match_start truncates large values
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10182>
_______________________________________

From report at bugs.python.org  Sat Oct 23 20:41:08 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 23 Oct 2010 18:41:08 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1287859268.03.0.797078375005.issue5178@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Personally I would like to have a unique tempfile.mkdtemp which can be used as both a function and a context manager, as it happens for open() and others.
Not sure how to do that though, unless tempfile.mkdtemp gets turned into a class.
There would be objections against doing that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5178>
_______________________________________

From report at bugs.python.org  Sat Oct 23 20:41:39 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Sat, 23 Oct 2010 18:41:39 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287859299.74.0.444787776557.issue9778@psf.upfronthosting.co.za>


Case Van Horsen <casevh at gmail.com> added the comment:

On Win64, I get two unexpected failures:

I terminated test_capi after a Windows exception box popped up.

[ 37/349] test_capi
test test_capi failed -- Traceback (most recent call last):
  File "C:\svn\py3k\lib\test\test_capi.py", line 50, in test_no_FatalError_infinite_loop
    b'Fatal Python error:'
AssertionError: b"Fatal Python error: PyThreadState_Get: no current thread\r\n\r\nThis application has requested the Runtime to term
inate it in an unusual way.\nPlease contact the application's support team for more information." != b'Fatal Python error: PyThreadS
tate_Get: no current thread'

[ 67/349] test_concurrent_futures
test test_concurrent_futures failed -- Traceback (most recent call last):
  File "C:\svn\py3k\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 0x5510fd0 state=finished raised AssertionError>

The dictviews test passes successfully.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 20:44:00 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 23 Oct 2010 18:44:00 +0000
Subject: [issue10169] socket.sendto raises incorrect exception when passed
	incorrect types
In-Reply-To: <1287681728.0.0.651147678785.issue10169@psf.upfronthosting.co.za>
Message-ID: <1287859440.49.0.17219194727.issue10169@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/issue10169>
_______________________________________

From report at bugs.python.org  Sat Oct 23 20:52:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 18:52:35 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287859955.92.0.964446842818.issue9778@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The test_capi problem is not 64-bit-specific (see issue9116).

As for test_concurrent_futures, I also have a failure (not the same one) in both 32-bit and 64-bit builds here. I'm gonna open a separate issue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 20:54:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 18:54:11 +0000
Subject: [issue10183] test_concurrent_futures failure on Windows
In-Reply-To: <1287860051.06.0.49357269827.issue10183@psf.upfronthosting.co.za>
Message-ID: <1287860051.06.0.49357269827.issue10183@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

I get this failure quite reliably on a Windows 7 VM, in both 32-bit and 64-bit builds:

======================================================================
FAIL: test_map_timeout (test.test_concurrent_futures.ProcessPoolExecutorTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Y:\py3k\__svn__\lib\test\test_concurrent_futures.py", line 572, in test_map_timeout
    self.assertEquals([42, 42], results)
AssertionError: Lists differ: [42, 42] != []

First list contains 2 additional elements.
First extra element 0:
42

- [42, 42]
+ []

----------
assignee: bquinlan
components: Library (Lib)
messages: 119466
nosy: bquinlan, pitrou
priority: normal
severity: normal
status: open
title: test_concurrent_futures failure on Windows
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10183>
_______________________________________

From report at bugs.python.org  Sat Oct 23 21:06:40 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 Oct 2010 19:06:40 +0000
Subject: [issue10184] tarfile touches directories twice
In-Reply-To: <1287860800.8.0.977653393639.issue10184@psf.upfronthosting.co.za>
Message-ID: <1287860800.8.0.977653393639.issue10184@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

When extracting, the time stamps of directories are modified twice: once when creating the directories, and then once in reverse order when done.
The first utimes call is redundant; it also causes issues with a buggy NFS server, see

http://www.python.org/dev/buildbot/3.1/builders/AMD64%20debian%20parallel%203.1/builds/147/steps/test/logs/stdio

(specifically, touching a file twice with the same second-resolution time stamp will increase the microsecond counter).

The attached patch works around the issue; regardless of the NFS bug, I think that the redundant call should be eliminated.

----------
assignee: ghaering
files: tarfile.diff
keywords: patch
messages: 119467
nosy: ghaering, loewis
priority: normal
severity: normal
status: open
title: tarfile touches directories twice
Added file: http://bugs.python.org/file19345/tarfile.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10184>
_______________________________________

From report at bugs.python.org  Sat Oct 23 21:09:17 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 23 Oct 2010 19:09:17 +0000
Subject: [issue9778] Make hash values the same width as a pointer (or
	Py_ssize_t)
In-Reply-To: <1283638291.76.0.407786717056.issue9778@psf.upfronthosting.co.za>
Message-ID: <1287860957.22.0.635448731962.issue9778@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I recommend to declare this issue closed, and keep it closed unless somebody wants to propose to revert the change (widening the hash type) completely. Any remaining issues that people want to attribute to this change (correctly or incorrectly) should be reported as separate issues.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9778>
_______________________________________

From report at bugs.python.org  Sat Oct 23 21:32:15 2010
From: report at bugs.python.org (Case Van Horsen)
Date: Sat, 23 Oct 2010 19:32:15 +0000
Subject: [issue10185] Py_hash_t declaration needed in _testcapimodule
In-Reply-To: <1287862335.94.0.457424318631.issue10185@psf.upfronthosting.co.za>
Message-ID: <1287862335.94.0.457424318631.issue10185@psf.upfronthosting.co.za>


New submission from Case Van Horsen <casevh at gmail.com>:

While researching errors in issue 9778, I found a variable in _testcapimodule.c that should be declared Py_hash_t instead of long.

Patch is attached.

----------
components: Interpreter Core
files: py_hash_t_testcapimodule.diff
keywords: patch
messages: 119469
nosy: casevh
priority: normal
severity: normal
status: open
title: Py_hash_t declaration needed in _testcapimodule
versions: Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19346/py_hash_t_testcapimodule.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10185>
_______________________________________

From report at bugs.python.org  Sat Oct 23 21:37:39 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 23 Oct 2010 19:37:39 +0000
Subject: [issue10180] File objects should not pickleable
In-Reply-To: <1287854367.84.0.526587779087.issue10180@psf.upfronthosting.co.za>
Message-ID: <1287862659.1.0.918949222312.issue10180@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch modifies _io.TextIOWrapper, but not _pyio.TextIOWrapper. Is there a reason?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10180>
_______________________________________

From report at bugs.python.org  Sat Oct 23 21:41:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 19:41:47 +0000
Subject: [issue10180] File objects should not pickleable
In-Reply-To: <1287854367.84.0.526587779087.issue10180@psf.upfronthosting.co.za>
Message-ID: <1287862907.08.0.418441727031.issue10180@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The patch modifies _io.TextIOWrapper, but not _pyio.TextIOWrapper. Is
> there a reason?

Yes, two of them:
- modifying _pyio.Buffered* is enough to trigger the TypeError
- _pyio.StringIO inherits from TextIOWrapper, and it must be pickleable

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10180>
_______________________________________

From report at bugs.python.org  Sat Oct 23 21:43:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 19:43:14 +0000
Subject: [issue10185] Py_hash_t declaration needed in _testcapimodule
In-Reply-To: <1287862335.94.0.457424318631.issue10185@psf.upfronthosting.co.za>
Message-ID: <1287862994.63.0.0540156149765.issue10185@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85810, thank you.

----------
nosy: +pitrou
resolution:  -> fixed
status: open -> closed
versions:  -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10185>
_______________________________________

From report at bugs.python.org  Sat Oct 23 22:39:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Oct 2010 20:39:21 +0000
Subject: [issue9967] encoded_word regular expression in
	email.header.decode_header()
In-Reply-To: <1285639066.52.0.877288279278.issue9967@psf.upfronthosting.co.za>
Message-ID: <1287866361.72.0.988126697775.issue9967@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/issue9967>
_______________________________________

From report at bugs.python.org  Sat Oct 23 22:58:32 2010
From: report at bugs.python.org (Alex)
Date: Sat, 23 Oct 2010 20:58:32 +0000
Subject: [issue10180] File objects should not pickleable
In-Reply-To: <1287854367.84.0.526587779087.issue10180@psf.upfronthosting.co.za>
Message-ID: <1287867512.63.0.820204442525.issue10180@psf.upfronthosting.co.za>


Alex <alex.gaynor at gmail.com> added the comment:

I don't see why Buffered or TextIO's shouldn't be pickleable, ISTM their pickleability should be based on what the underlying file obj is.

----------
nosy: +alex

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10180>
_______________________________________

From report at bugs.python.org  Sat Oct 23 23:09:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Oct 2010 21:09:06 +0000
Subject: [issue10180] File objects should not pickleable
In-Reply-To: <1287854367.84.0.526587779087.issue10180@psf.upfronthosting.co.za>
Message-ID: <1287868146.93.0.358488222134.issue10180@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

What would be the use case for that?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10180>
_______________________________________

From report at bugs.python.org  Sat Oct 23 23:11:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Oct 2010 21:11:23 +0000
Subject: [issue10180] File objects should not pickleable
In-Reply-To: <1287867512.63.0.820204442525.issue10180@psf.upfronthosting.co.za>
Message-ID: <1287868278.3611.14.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I don't see why Buffered or TextIO's shouldn't be pickleable, ISTM
> their pickleability should be based on what the underlying file obj
> is.

That could be. Right now, though, pickling them gives nonsensical
results and I think it would be better to give an explicit error
message.

(a problem with making them pickleable is that, by exposing details of
the internal structure in the pickle, you're limiting what
implementation changes you can do in the future)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10180>
_______________________________________

From report at bugs.python.org  Sat Oct 23 23:22:11 2010
From: report at bugs.python.org (Shashank)
Date: Sat, 23 Oct 2010 21:22:11 +0000
Subject: [issue10030] Patch for zip decryption speedup
In-Reply-To: <1286309331.81.0.797536492786.issue10030@psf.upfronthosting.co.za>
Message-ID: <1287868931.75.0.801766819192.issue10030@psf.upfronthosting.co.za>


Shashank <shashank.sunny.singh at gmail.com> added the comment:

>the C module should be private and therefore called _zipdecrypt
done

>if you want to avoid API mismatch, you could give a tp_call to your C >decrypter object, rather than a "decrypt" method
done

>- you can put all initialization code in zipdecrypt_new and avoid the >need for zipdecrypt_init
keeping this similar to the existing _ZipDecrypter class in ZipFile (all initialization in init rather than new), which was probably to allow re-init and re-use of one instance

>it's better to use the "y*" code in PyArg_ParseTuple, rather than "s#"
y* does not seem to be available in 2.7, using s* instead

>you should define your module as PY_SSIZE_T_CLEAN and use Py_ssize_t >as length variables (rather than int)
done

>you *mustn't* change the contents of the buffer which is given you by >"s#" or "y*", since that buffer is read-only (it can be a bytes >object); instead, create a new bytes object using >PyBytes_FromStringAndSize(NULL, length) and write into that; or, if >you want a read-write buffer, use the "w*" code
corrected, not altering the input buffer, reading input buffer as s*

----------
Added file: http://bugs.python.org/file19347/zipdecrypt.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10030>
_______________________________________

From report at bugs.python.org  Sat Oct 23 23:55:10 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Oct 2010 21:55:10 +0000
Subject: [issue10178] PEP 378 uses replace where translate may work better
In-Reply-To: <1287842725.3.0.632950856337.issue10178@psf.upfronthosting.co.za>
Message-ID: <1287870910.6.0.995110762573.issue10178@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Sorry, the text needs to stand as-is.
It is supposed to be a hint of what can be done,
nothing more.

The technique of t=x; x=y; y=t is somewhat basic
and has general applicability -- there's nothing
"complex" about it.   Also, for short strings 
such as the one in the example, the translate 
approach is slower unless the used in a loop
where the translation table is already built.

BTW, the PEP itself is not primary documentation
for users.  It is meant to document the design
discussion only.  

Feel free to post your recipe on ASPN or on
the newsgroup.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10178>
_______________________________________

From report at bugs.python.org  Sun Oct 24 00:22:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 23 Oct 2010 22:22:48 +0000
Subject: [issue1349106] email.Generator does not separate headers with "\r\n"
Message-ID: <1287872568.74.0.527070419621.issue1349106@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed in r85811.

----------
resolution:  -> accepted
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1349106>
_______________________________________

From report at bugs.python.org  Sun Oct 24 01:42:05 2010
From: report at bugs.python.org (Alex)
Date: Sat, 23 Oct 2010 23:42:05 +0000
Subject: [issue10186] Invalid SyntaxError pointer offset
In-Reply-To: <1287877325.31.0.208364473897.issue10186@psf.upfronthosting.co.za>
Message-ID: <1287877325.31.0.208364473897.issue10186@psf.upfronthosting.co.za>


New submission from Alex <malicious.wizard at gmail.com>:

Builtin SyntaxError formatter does never point to char before last in wrong source line. traceback.format_exception() is not affected.

*** Example:
>>> raise SyntaxError('', ('', 0, 3, 'hello'))
...
    hello
      ^
SyntaxError: test
>>> raise SyntaxError('', ('', 0, 4, 'hello'))
...
    hello
       ^
SyntaxError: test
>>> raise SyntaxError('', ('', 0, 5, 'hello'))
...
    hello   # <-- note that it's not "o"
       ^
SyntaxError: test
>>> raise SyntaxError('', ('', 0, 6, 'hello'))
...
    hello
         ^
SyntaxError: test

----------
components: Interpreter Core
messages: 119479
nosy: mwizard
priority: normal
severity: normal
status: open
title: Invalid SyntaxError pointer offset
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10186>
_______________________________________

From report at bugs.python.org  Sun Oct 24 01:48:22 2010
From: report at bugs.python.org (And Clover)
Date: Sat, 23 Oct 2010 23:48:22 +0000
Subject: [issue10155] Add fixups for encoding problems to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1287877702.55.0.861641527937.issue10155@psf.upfronthosting.co.za>


Changes by And Clover <and at doxdesk.com>:


Removed file: http://bugs.python.org/file19303/wsgiref-patches-3.2a3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10155>
_______________________________________

From report at bugs.python.org  Sun Oct 24 01:55:24 2010
From: report at bugs.python.org (Alex)
Date: Sat, 23 Oct 2010 23:55:24 +0000
Subject: [issue10186] Invalid SyntaxError pointer offset
In-Reply-To: <1287877325.31.0.208364473897.issue10186@psf.upfronthosting.co.za>
Message-ID: <1287878124.59.0.562156715752.issue10186@psf.upfronthosting.co.za>


Changes by Alex <malicious.wizard at gmail.com>:


----------
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10186>
_______________________________________

From report at bugs.python.org  Sun Oct 24 02:06:50 2010
From: report at bugs.python.org (And Clover)
Date: Sun, 24 Oct 2010 00:06:50 +0000
Subject: [issue10155] Add fixups for encoding problems to wsgiref
In-Reply-To: <1287591822.31.0.50492787235.issue10155@psf.upfronthosting.co.za>
Message-ID: <1287878810.41.0.153465992171.issue10155@psf.upfronthosting.co.za>


And Clover <and at doxdesk.com> added the comment:

Ah, sorry, submitted wrong patch against 3.2, disregard. Here's the 'proper' version (the functionality isn't changed, just the former patch had an unused and-Falsed out clause for reading environb, which in the end I decided not to use as the surrogateescape approach already covers it just as well for values).

@?ric: yes. Actually the whole patch is pretty much new functionality, which should not be considered for a 2.7.x bugfix release. I've submitted a patch against 2.7 for completeness and for the use of a separately-maintained post-2.7 wsgiref, but unless there is ever a Python 2.8 it should never hit stdlib.

The status quo wrt Unicode in environ is broken and inconsistent, which an accepted PEP 3333 would finally clear up. But there may be webapps deployed that rely on their particular server's current inconsistent environ, and those shouldn't be broken by a bugfix 2.7 or 3.1 release.

----------
versions:  -Python 3.1
Added file: http://bugs.python.org/file19348/wsgiref-patches-3.2a3.proper.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10155>
_______________________________________

From report at bugs.python.org  Sun Oct 24 04:52:57 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Oct 2010 02:52:57 +0000
Subject: [issue10186] Invalid SyntaxError pointer offset
In-Reply-To: <1287877325.31.0.208364473897.issue10186@psf.upfronthosting.co.za>
Message-ID: <1287888777.77.0.445254357509.issue10186@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85814

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10186>
_______________________________________

From report at bugs.python.org  Sun Oct 24 05:04:46 2010
From: report at bugs.python.org (wjm251)
Date: Sun, 24 Oct 2010 03:04:46 +0000
Subject: [issue10187] exec encode unicode to utf-8 str automatically in GBK
	environment
In-Reply-To: <1287889486.79.0.122222504002.issue10187@psf.upfronthosting.co.za>
Message-ID: <1287889486.79.0.122222504002.issue10187@psf.upfronthosting.co.za>


New submission from wjm251 <wjm251 at gmail.com>:

windows Xp chinese version

see the attached file, the header was set to GBK,and the file is GBK encoded, but why the output was '\xe5\xa4\xa7'(it is utf-8 encoded of Chinese character "?")

----------
components: Library (Lib)
files: test.py
messages: 119482
nosy: wjm251
priority: normal
severity: normal
status: open
title: exec encode unicode to utf-8 str automatically in GBK environment
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19349/test.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10187>
_______________________________________

From report at bugs.python.org  Sun Oct 24 05:24:25 2010
From: report at bugs.python.org (wjm251)
Date: Sun, 24 Oct 2010 03:24:25 +0000
Subject: [issue10187] exec encode unicode to utf-8 str automatically in GBK
	environment
In-Reply-To: <1287889486.79.0.122222504002.issue10187@psf.upfronthosting.co.za>
Message-ID: <1287890665.91.0.309175606068.issue10187@psf.upfronthosting.co.za>


wjm251 <wjm251 at gmail.com> added the comment:

in windows English Version and ubuntu 10.04(locale is utf-8)
all have the same the behavior,

am I wrong?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10187>
_______________________________________

From report at bugs.python.org  Sun Oct 24 06:57:23 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Oct 2010 04:57:23 +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: <1287896243.28.0.213028533072.issue10164@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My best guess currently is that the failing test is a bug in difflib, but I haven't dug into that code yet to prove it.  It's still possible it's something stupid in my code, but as far as I can see there's no character over where that - is in the difflib output (that is, the two lines that it says are different appear identical when viewed with cat -A).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10164>
_______________________________________

From report at bugs.python.org  Sun Oct 24 07:14:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Oct 2010 05:14:20 +0000
Subject: [issue9228] Make changes in the path and pathext on installation
In-Reply-To: <1278892287.6.0.671523214632.issue9228@psf.upfronthosting.co.za>
Message-ID: <1287897260.84.0.272531871664.issue9228@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Modifying the path has be definitely rejected by python-dev.  I don't know enough about windows to comment on the other two, but I suspect that everything that it is reasonable to do automatically is already being done.

----------
nosy: +loewis, r.david.murray
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9228>
_______________________________________

From report at bugs.python.org  Sun Oct 24 07:17:41 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Oct 2010 05:17:41 +0000
Subject: [issue7696] Improve Memoryview/Buffer documentation
In-Reply-To: <1263418431.81.0.407262013758.issue7696@psf.upfronthosting.co.za>
Message-ID: <1287897461.89.0.826117073463.issue7696@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Antoine, is there more that remains to be done on this, or can it be closed?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7696>
_______________________________________

From report at bugs.python.org  Sun Oct 24 08:38:43 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 Oct 2010 06:38:43 +0000
Subject: [issue10187] exec encode unicode to utf-8 str automatically in GBK
	environment
In-Reply-To: <1287889486.79.0.122222504002.issue10187@psf.upfronthosting.co.za>
Message-ID: <1287902323.29.0.362505859757.issue10187@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a bug, but intentional.

a is a Unicode string; it does not have an encoding internally (not GBK, not UTF-8). Then, the string being exec'ed also becomes a Unicode string. exec'ing Unicode strings is confusing; try to avoid this. The semantics of exec'ing a Unicode string is that all str (but not unicode) literals get encoded as UTF-8.

To see the result you expect, write

a = "??"

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10187>
_______________________________________

From report at bugs.python.org  Sun Oct 24 08:42:42 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 Oct 2010 06:42:42 +0000
Subject: [issue10187] exec encode unicode to utf-8 str automatically in GBK
	environment
In-Reply-To: <1287889486.79.0.122222504002.issue10187@psf.upfronthosting.co.za>
Message-ID: <1287902562.92.0.242904384423.issue10187@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Oops, I meant

a = "?"

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10187>
_______________________________________

From report at bugs.python.org  Sun Oct 24 08:44:52 2010
From: report at bugs.python.org (wjm251)
Date: Sun, 24 Oct 2010 06:44:52 +0000
Subject: [issue10187] exec encode unicode to utf-8 str automatically in GBK
	environment
In-Reply-To: <1287889486.79.0.122222504002.issue10187@psf.upfronthosting.co.za>
Message-ID: <1287902692.07.0.436732869163.issue10187@psf.upfronthosting.co.za>


wjm251 <wjm251 at gmail.com> added the comment:

but why it is forced to encoded to utf-8,
I think it should be encoded by the locale related encodings,not always utf-8,
for example,in GBK locale,it should use GBK to encode the unicode object,right?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10187>
_______________________________________

From report at bugs.python.org  Sun Oct 24 08:55:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 Oct 2010 06:55:56 +0000
Subject: [issue10187] exec encode unicode to utf-8 str automatically in
	GBK	environment
In-Reply-To: <1287902692.07.0.436732869163.issue10187@psf.upfronthosting.co.za>
Message-ID: <4CC3D879.5070503@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> but why it is forced to encoded to utf-8,
> I think it should be encoded by the locale related encodings,not always utf-8,
> for example,in GBK locale,it should use GBK to encode the unicode object,right?

Wrong. Exec'ing Unicode strings has been specified to encode all strings
as UTF-8. This cannot be changed anymore.

Even if this was possible to change, it should *not* use the locale
encoding. The source encoding and the locale encoding are independent;
the source encoding is normally determined from PEP 263 declarations.
So if anything, exec'ing Unicode strings should use an encoding
declaration that you have in that string. However, you don't have one,
and they are unsupported for Unicode strings, anyway.

----------
title: exec encode unicode to utf-8 str automatically in GBK environment -> exec encode unicode to utf-8 str automatically in GBK	environment

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10187>
_______________________________________

From report at bugs.python.org  Sun Oct 24 09:01:55 2010
From: report at bugs.python.org (wjm251)
Date: Sun, 24 Oct 2010 07:01:55 +0000
Subject: [issue10187] exec encode unicode to utf-8 str automatically in
	GBK	environment
In-Reply-To: <1287889486.79.0.122222504002.issue10187@psf.upfronthosting.co.za>
Message-ID: <1287903715.2.0.324412665877.issue10187@psf.upfronthosting.co.za>


wjm251 <wjm251 at gmail.com> added the comment:

oh,you mentioned the PEP 263
but I already set a header like this,you can see the attached test.py
#coding=GBK

why exec choose to use utf-8 not GBK?
GBK is a valid Chinese character  set in python26

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10187>
_______________________________________

From report at bugs.python.org  Sun Oct 24 09:15:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 Oct 2010 07:15:05 +0000
Subject: [issue10187] exec encode unicode to utf-8 str automatically in
	GBK	environment
In-Reply-To: <1287903715.2.0.324412665877.issue10187@psf.upfronthosting.co.za>
Message-ID: <4CC3DCF6.6080107@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> oh,you mentioned the PEP 263
> but I already set a header like this,you can see the attached test.py
> #coding=GBK

You have that in test.py, but not in the string you are giving to exec.
This is really a separate source code.

So you could have written

exec '''#coding:GBK
print hi('%s')
''' % a

You didn't, hence the code you pass to exec has no declared source encoding.

> why exec choose to use utf-8 not GBK?

exec always choses UTF-8 when exec'ing Unicode strings. The source
encoding of the file that has the exec statement must be irrelevant:
the string being exec'ed may have been received from a different source
file.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10187>
_______________________________________

From report at bugs.python.org  Sun Oct 24 09:38:37 2010
From: report at bugs.python.org (wjm251)
Date: Sun, 24 Oct 2010 07:38:37 +0000
Subject: [issue10187] exec encode unicode to utf-8 str automatically in
	GBK	environment
In-Reply-To: <1287889486.79.0.122222504002.issue10187@psf.upfronthosting.co.za>
Message-ID: <1287905917.98.0.273289902713.issue10187@psf.upfronthosting.co.za>


wjm251 <wjm251 at gmail.com> added the comment:

Got that ,
thank you

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10187>
_______________________________________

From report at bugs.python.org  Sun Oct 24 09:47:48 2010
From: report at bugs.python.org (Ask Solem)
Date: Sun, 24 Oct 2010 07:47:48 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1287906468.53.0.521702488263.issue4999@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Updated doc patch

----------
nosy: +asksol
Added file: http://bugs.python.org/file19350/issue-4999.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Sun Oct 24 10:19:04 2010
From: report at bugs.python.org (Ask Solem)
Date: Sun, 24 Oct 2010 08:19:04 +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: <1287908344.92.0.408100644547.issue8037@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

AFAICS the object will be pickled twice with this patch.
See Modules/_multiprocessing/connection.h: connection_send_obj.

----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Sun Oct 24 10:22:07 2010
From: report at bugs.python.org (Ask Solem)
Date: Sun, 24 Oct 2010 08:22:07 +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: <1287908527.59.0.913345726536.issue8037@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

aha, no. I see now you use connection.send_bytes instead.
Then I can't think of any issues with this patch, but I don't know why
it was done this way in the first place.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Sun Oct 24 10:22:58 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Oct 2010 08:22:58 +0000
Subject: [issue4999] multiprocessing.Queue does not order objects
In-Reply-To: <1232369845.16.0.0391307501892.issue4999@psf.upfronthosting.co.za>
Message-ID: <1287908578.38.0.616935685119.issue4999@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Are you sure this needs to be a warning?  We try to use them very sparingly.

(Also note the 3-space indent for reStructuredText markup.)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4999>
_______________________________________

From report at bugs.python.org  Sun Oct 24 10:29:49 2010
From: report at bugs.python.org (Ask Solem)
Date: Sun, 24 Oct 2010 08:29:49 +0000
Subject: [issue7200] multiprocessing deadlock on Mac OS X when queue collected
	before process terminates
In-Reply-To: <1256425837.07.0.628633816678.issue7200@psf.upfronthosting.co.za>
Message-ID: <1287908989.37.0.125196922629.issue7200@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Queue uses multiprocessing.util.Finalize, which uses weakrefs to track when the object is out of scope, so this is actually expected behavior.

IMHO it is not a very good approach, but changing the API to use explicit close methods is a little late at this point, I guess.

----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7200>
_______________________________________

From report at bugs.python.org  Sun Oct 24 10:44:41 2010
From: report at bugs.python.org (Ask Solem)
Date: Sun, 24 Oct 2010 08:44:41 +0000
Subject: [issue6407] multiprocessing Pool should allow custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1287909881.34.0.465162541642.issue6407@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

Matthew, would you be willing to write tests + documentation for this?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6407>
_______________________________________

From report at bugs.python.org  Sun Oct 24 10:58:26 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 24 Oct 2010 08:58:26 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1287910706.4.0.14018811361.issue8777@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Hi, I had forgotten about this.
I went back to the drawing board and had almost completed a new version.  Looking at the Java barrier shows how one can go overboard with stuff.  My though with the barrier is to provide a simple synchronization primitive that works well for example in the unittests, without trying too hard to over design it in terms of failure modes.

Anyway, I?ll get my act together.  Same with RWLock, that is almost ready

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Sun Oct 24 10:59:50 2010
From: report at bugs.python.org (Ask Solem)
Date: Sun, 24 Oct 2010 08:59:50 +0000
Subject: [issue7474] multiprocessing.managers.SyncManager managed object
	creation fails when started outside of invoked file
In-Reply-To: <1260477184.12.0.729093197155.issue7474@psf.upfronthosting.co.za>
Message-ID: <1287910790.12.0.539820746271.issue7474@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

I can't seem to reproduce this on trunk...

----------
nosy: +asksol

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7474>
_______________________________________

From report at bugs.python.org  Sun Oct 24 11:09:44 2010
From: report at bugs.python.org (Ask Solem)
Date: Sun, 24 Oct 2010 09:09:44 +0000
Subject: [issue5573] multiprocessing Pipe poll() and recv() semantics.
In-Reply-To: <1238096312.97.0.564685442594.issue5573@psf.upfronthosting.co.za>
Message-ID: <1287911384.76.0.504487345043.issue5573@psf.upfronthosting.co.za>


Ask Solem <askh at opera.com> added the comment:

I don't know about the socket internals, but I find the behavior 
acceptable. It may not be feasible to change it now anyway, as there may be people already depending on it (e.g. not handling errors occurring at poll)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5573>
_______________________________________

From report at bugs.python.org  Sun Oct 24 11:21:11 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 09:21:11 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1287912071.66.0.601078651518.issue5178@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5178>
_______________________________________

From report at bugs.python.org  Sun Oct 24 11:22:15 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 09:22:15 +0000
Subject: [issue8202] sys.argv[0] and python -m package
In-Reply-To: <1269289306.17.0.0782561601798.issue8202@psf.upfronthosting.co.za>
Message-ID: <1287912135.28.0.292173134079.issue8202@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8202>
_______________________________________

From report at bugs.python.org  Sun Oct 24 12:21:45 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 24 Oct 2010 10:21:45 +0000
Subject: [issue10156] Initialization of globals in unicodeobject.c
In-Reply-To: <1287595627.82.0.548953621137.issue10156@psf.upfronthosting.co.za>
Message-ID: <1287915705.68.0.697586370956.issue10156@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

> why should _PyUnicode_Init() try to call _PyUnicode_InitGlobals() again?


For the embedding scenario (when only Py_Initialize() is called) I wanted
to preserve the old behavior of _PyUnicode_Init().

But this is not really enough. I wrote a new patch that also calls 
_PyUnicode_InitGlobals() at the beginning of Py_Initialize().


I don't like the fact that even more clutter is added to Py_Main(). Perhaps
Py_Initialize() could be moved up or the Unicode functions could be moved
down.

----------
Added file: http://bugs.python.org/file19351/unicode_init_globals2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10156>
_______________________________________

From report at bugs.python.org  Sun Oct 24 12:38:15 2010
From: report at bugs.python.org (Vilnis Termanis)
Date: Sun, 24 Oct 2010 10:38:15 +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: <1287916695.01.0.382628641553.issue8037@psf.upfronthosting.co.za>


Vilnis Termanis <vilnis.termanis at googlemail.com> added the comment:

The idea is to pickle the object immediately (i.e. when added) instead of when requested (dequeued). This means that any operations (even deletion) performed on the original object do not make changes to the item in the queue, before it has been dequeued.
Whether this is an acceptable solution I don't know.. it's just my proposal. The attached queue_example.py script illustrates what I mean.

Regards,
VT

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8037>
_______________________________________

From report at bugs.python.org  Sun Oct 24 12:53:00 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 10:53:00 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

During interpreter shutdown, modules can become unusable as module globals are set to None. This is a problem for tempfile.TemporaryDirectory, as it needs working os, os.path and stat modules in order to clean up the filesystem.

The class makes a valiant attempt at reducing the frequency of these errors, but it is ultimately useless, since the three modules internally rely on their various globals remaining valid.

Issue #812369 may be a possible solution to this problem, or perhaps even an explicit list of essential modules that are nulled out only after all other modules have been destroyed.

----------
messages: 119505
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: tempfile.TemporaryDirectory may throw errors at shutdown

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Sun Oct 24 13:10:33 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 24 Oct 2010 11:10:33 +0000
Subject: [issue9408] curses: Link against libncursesw instead of libncurses
In-Reply-To: <1280360992.02.0.384889308435.issue9408@psf.upfronthosting.co.za>
Message-ID: <1287918633.02.0.471002345837.issue9408@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

There are two issues here:

(1) If libreadline is already linked against ncurses, there is no way that
    the readline module should be linked against ncursesw. This was the
    direct cause of the FreeBSD segfault, so this configuration is also
    prohibited in 2.6/3.1.

(2) Interaction between the readline and curses modules: 2.6/3.1 still
    allow readline+ncurses with curses+ncursesw. To be on the safe side,
    2.7/3.2 enforce all ncurses or all ncursesw.


(1) implies that if your readline module is linked against ncurses in 3.1,
you should find that libreadline is also linked against ncurses.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9408>
_______________________________________

From report at bugs.python.org  Sun Oct 24 13:15:01 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 11:15:01 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1287918901.21.0.835897486457.issue10188@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Cleanup of sys and __builtin__ is already delayed - this particular issue could be fixed by delaying cleanup of a few more modules, along with the proposed change to GC invocation in issue #1545463.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Sun Oct 24 13:16:49 2010
From: report at bugs.python.org (Stefan Krah)
Date: Sun, 24 Oct 2010 11:16:49 +0000
Subject: [issue9408] curses: Link against libncursesw instead of libncurses
In-Reply-To: <1280360992.02.0.384889308435.issue9408@psf.upfronthosting.co.za>
Message-ID: <1287919009.07.0.117427537019.issue9408@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Hmm, I understood that your ldd lines implied that things don't work as
intended in 3.1, hence the explanation. Perhaps this wasn't the case. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9408>
_______________________________________

From report at bugs.python.org  Sun Oct 24 13:23:57 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 11:23:57 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1287919437.69.0.197907076599.issue5178@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Committed (with enhanced tests and a few fixes) in r85818

And credit where it's due to test___all__ for picking up a typo in my adjustment to tempfile.__all__ :)

I created issue #10188 to track the shutdown problem. I'm considering taking out the code that attempts to allow the __del__ method to work at shutdown though, since it isn't actually achieving anything (I wanted a record of it in the main repository, which is why I kept it for the initial checkin).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5178>
_______________________________________

From report at bugs.python.org  Sun Oct 24 13:24:09 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 11:24:09 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1287919449.6.0.685508092612.issue5178@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5178>
_______________________________________

From report at bugs.python.org  Sun Oct 24 14:32:09 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 24 Oct 2010 12:32:09 +0000
Subject: [issue10184] tarfile touches directories twice
In-Reply-To: <1287860800.8.0.977653393639.issue10184@psf.upfronthosting.co.za>
Message-ID: <1287923529.43.0.218246124269.issue10184@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

The patch goes a bit too far. Though it solves this particular problem with the way TarFile.extractall() works, it breaks TarFile.extract(). Running the testsuite does not expose this, simply because there's no testcase :-(

Please see the attached testcase I just wrote which illustrates the problem.

----------
nosy: +lars.gustaebel
Added file: http://bugs.python.org/file19352/tarfile-extract-directory-test.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10184>
_______________________________________

From report at bugs.python.org  Sun Oct 24 15:09:56 2010
From: report at bugs.python.org (Matthew Leon Grinshpun)
Date: Sun, 24 Oct 2010 13:09:56 +0000
Subject: [issue6407] multiprocessing Pool should allow custom task queue
In-Reply-To: <1246627398.56.0.0568609724018.issue6407@psf.upfronthosting.co.za>
Message-ID: <1287925796.41.0.538284367747.issue6407@psf.upfronthosting.co.za>


Matthew Leon Grinshpun <vertespain at gmail.com> added the comment:

I should be able to do this in November. For the moment I'm a bit busy.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6407>
_______________________________________

From report at bugs.python.org  Sun Oct 24 15:42:52 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 13:42:52 +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: <1287927772.79.0.561294114733.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Attached a second version of the patch. Notable features:
- uses a coercion-to-str-and-back strategy (using ascii-strict)
- a significantly more comprehensive pass through the urlparse test suite. I'm happy that the test suite mods are complete with this pass.

The actual coercion-to-str technique I used standardises the type consistency check for the attributes and also returns a callable that handles the necessary coercion of any results. The parsed/split result objects gain encode/decode methods to allow that all to be handled polymorphically (although I think the decode methods may actually be redundant in practice).

There's a deliberate loophole in the type consistency checking to allow the empty string to be type-neutral. Without that, the scheme='' default argument to urlsplit and urlparse becomes painful (as do the urljoin shortcuts for base or url being the empty string).

Implementing this was night and day when compared to the initial attempt that tried to actually manipulate bytes input as bytes. With that patch, it took me multiple runs of the test suite to get everything working. This time, the only things I had to fix were typos and bugs in the additional test suite enhancements. The actual code logic for the type coercions worked first time.

----------
Added file: http://bugs.python.org/file19353/issue9873_coercion_to_str.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Sun Oct 24 15:48:02 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 13:48:02 +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: <1287928082.39.0.533597243986.issue9873@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Unless I hear some reasonable objections within the next week or so, I'm going to document and commit the ascii-strict coercion approach for beta 1.

The difference in code clarity is such that I'm not even going to try to benchmark the two approaches against each other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9873>
_______________________________________

From report at bugs.python.org  Sun Oct 24 15:52:36 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 13:52:36 +0000
Subject: [issue10049] Add a "no-op" (null) context manager to contextlib
In-Reply-To: <1286536426.03.0.247784217987.issue10049@psf.upfronthosting.co.za>
Message-ID: <1287928356.64.0.0706920190396.issue10049@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I find Raymond's perspective persuasive in this case. Feel free to post either the original idea or my later variant as an ASPN cookbook recipe. (you could actually combine the two, and use NullContext as an implementation detail of an optional_cm() function)

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10049>
_______________________________________

From report at bugs.python.org  Sun Oct 24 15:57:47 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 13:57:47 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1287928667.56.0.934451381614.issue2690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I'd still like to have another look at this before beta 1, but can't promise I'll get to it. Unassigning in case someone else has some roundtuits to spare over the next few weeks.

----------
assignee: ncoghlan -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
_______________________________________

From report at bugs.python.org  Sun Oct 24 16:01:26 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 14:01:26 +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: <1287928886.75.0.529851134015.issue5251@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

R.I.P contextlib.nested (it is gone in 3.2 following the deprecation in 3.1). The issue is obscure enough that I don't see much value in updating the documentation for the versions that still contain it in deprecated form.

----------
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5251>
_______________________________________

From report at bugs.python.org  Sun Oct 24 16:05:05 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Oct 2010 14:05:05 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
	and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1287929105.93.0.866361036776.issue9517@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I still think this is a good idea, I'm just not actively working on it. It might make a good project for someone wanting to get to know the process of working on CPython without having to deal with anything that is particularly tricky to understand.

----------
assignee: ncoghlan -> 
keywords: +easy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Sun Oct 24 17:23:48 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 24 Oct 2010 15:23:48 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1280591712.46.0.151463924195.issue9437@psf.upfronthosting.co.za>
Message-ID: <1287933828.66.0.733230699912.issue9437@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

These changes cause some regressions:
- distutils builds third-party extensions with LDFLAGS, which were used to build CPython. (This is more important regression.)
  This problem concerns Python 2.7 and 3.2.
- distutils builds third-party extensions with LDFLAGS environment variable passed twice to compiler (distutils uses LDSHARED, which now contains $(LDFLAGS), and uses LDFLAGS).
  This problem concerns Python 3.2.

Example for 3.2:
x86_64-pc-linux-gnu-gcc -pthread -shared ${LDFLAGS_from_CPython} ${LDFLAGS_from_current_environment} ${LDFLAGS_from_current_environment}  ${CFLAGS} ${object_files} -L/usr/lib64 -lpython3.2mu -o ${extension_module}

----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Sun Oct 24 17:42:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Oct 2010 15:42:57 +0000
Subject: [issue9437] can't build extensions with non-default ldflags (e.g.
	-m32)
In-Reply-To: <1287933828.66.0.733230699912.issue9437@psf.upfronthosting.co.za>
Message-ID: <1287934972.3587.4.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> These changes cause some regressions:
> - distutils builds third-party extensions with LDFLAGS, which were
> used to build CPython. (This is more important regression.)
>   This problem concerns Python 2.7 and 3.2.

Well, is this a problem? This sounds like the expected behaviour to me.
Especially if Python was packaged was someone else and you don't want
the user to manually set LDFLAGS each time they run a setup.py.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9437>
_______________________________________

From report at bugs.python.org  Sun Oct 24 17:44:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Oct 2010 15:44:14 +0000
Subject: [issue7696] Improve Memoryview/Buffer documentation
In-Reply-To: <1287897461.89.0.826117073463.issue7696@psf.upfronthosting.co.za>
Message-ID: <1287935050.3587.5.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Antoine, is there more that remains to be done on this, or can it be closed?

I don't know really. I have done what I thought necessary on
memoryview/buffer maintenance, and I don't really want to go any
further.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7696>
_______________________________________

From report at bugs.python.org  Sun Oct 24 17:57:59 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 24 Oct 2010 15:57:59 +0000
Subject: [issue7696] Improve Memoryview/Buffer documentation
In-Reply-To: <1263418431.81.0.407262013758.issue7696@psf.upfronthosting.co.za>
Message-ID: <1287935879.42.0.984651013636.issue7696@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Let's close then.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7696>
_______________________________________

From report at bugs.python.org  Sun Oct 24 19:30:32 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Oct 2010 17:30:32 +0000
Subject: [issue10000] mark more tests as CPython specific
In-Reply-To: <1285861695.5.0.301447830736.issue10000@psf.upfronthosting.co.za>
Message-ID: <1287941432.14.0.453142867204.issue10000@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Tests
nosy: +eric.araujo
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/issue10000>
_______________________________________

From report at bugs.python.org  Sun Oct 24 19:32:26 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Oct 2010 17:32:26 +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: <1287941546.12.0.807161335083.issue10002@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/issue10002>
_______________________________________

From report at bugs.python.org  Sun Oct 24 19:34:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Oct 2010 17:34:12 +0000
Subject: [issue10006] non-Pythonic fate of __abstractmethods__
In-Reply-To: <1285940853.14.0.546762707016.issue10006@psf.upfronthosting.co.za>
Message-ID: <1287941652.91.0.178861192313.issue10006@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10006>
_______________________________________

From report at bugs.python.org  Sun Oct 24 19:35:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Oct 2010 17:35:15 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1287941715.88.0.349030841045.issue10188@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Sun Oct 24 19:37:06 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 24 Oct 2010 17:37:06 +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: <1287941826.63.0.897963232225.issue10002@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10002>
_______________________________________

From report at bugs.python.org  Sun Oct 24 19:50:23 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Oct 2010 17:50:23 +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: <1287942623.21.0.536109730255.issue10171@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

In my GTK desktop environment, your two examples produce windows that don?t respect my theme.  Can you give me an example that uses correct buttons for you so that I can see what I should expect?

I?m not sure this is a bug or a feature request.

----------
components:  -Windows
nosy: +eric.araujo
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10171>
_______________________________________

From report at bugs.python.org  Sun Oct 24 20:23:03 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Sun, 24 Oct 2010 18:23:03 +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: <1287944583.4.0.410193027434.issue10171@psf.upfronthosting.co.za>


Rafe Kettler <rafe.kettler at gmail.com> added the comment:

If you were to create a FileDialog, you should see proper buttons (at least I do in Windows):

import tkFileDialog
tkFileDialog.askopenfile()

I think that this goes more along the lines of a bug, because I know that Tkinter has the ability to properly show buttons. So, it would seem to be a bug that for two types of dialogs, the buttons aren't displayed correctly and rather reflect an old-style button.

I'm not sure if this is on the Python or Tcl side of the problem, but I really have no way of testing the Tcl/Tk implementation of these dialogs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10171>
_______________________________________

From report at bugs.python.org  Sun Oct 24 20:25:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Oct 2010 18:25:13 +0000
Subject: [issue10019] json.dumps with indent = 0 not adding newlines
In-Reply-To: <1286122957.24.0.240376565719.issue10019@psf.upfronthosting.co.za>
Message-ID: <1287944713.64.0.687492127236.issue10019@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/issue10019>
_______________________________________

From report at bugs.python.org  Sun Oct 24 20:41:36 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Oct 2010 18:41:36 +0000
Subject: =?utf-8?q?=5Bissue10013=5D_fix_=60=2E/libpython2=2E6=2Eso=3A_undefined_re?=
	=?utf-8?q?ference_to_=60=5FPyParser=5FGrammar=C2=B4=60_in_parallel_builds?=
In-Reply-To: <1286018023.44.0.511102577172.issue10013@psf.upfronthosting.co.za>
Message-ID: <1287945696.14.0.175407800969.issue10013@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10013>
_______________________________________

From report at bugs.python.org  Sun Oct 24 20:45:40 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 24 Oct 2010 18:45:40 +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: <1287945940.2.0.779621914502.issue10002@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy:  -r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10002>
_______________________________________

From report at bugs.python.org  Sun Oct 24 21:11:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 24 Oct 2010 19:11:33 +0000
Subject: [issue10184] tarfile touches directories twice
In-Reply-To: <1287860800.8.0.977653393639.issue10184@psf.upfronthosting.co.za>
Message-ID: <1287947493.05.0.297005115059.issue10184@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I see. Here is an updated version that makes the touch operations optional.

----------
assignee: ghaering -> lars.gustaebel
nosy:  -ghaering
Added file: http://bugs.python.org/file19354/tarfile2.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10184>
_______________________________________

From report at bugs.python.org  Sun Oct 24 21:16:15 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Oct 2010 19:16:15 +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: <1287947775.33.0.641607207612.issue10171@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks, I tested the file dialog example and it does not respect my theme either.  Re-adding the Windows component.

I suspect the bug is in Python.  Like you said, Tcl/Tk and Tkinter do have the ability to use new shiny buttons, it?s just two modules that are not consistent with the rest.  If you could look into the Python code and make suggestions or maybe a patch, it would help gpolo fix this.

----------
components: +Windows

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10171>
_______________________________________

From report at bugs.python.org  Sun Oct 24 21:22:07 2010
From: report at bugs.python.org (Alex)
Date: Sun, 24 Oct 2010 19:22:07 +0000
Subject: [issue10189] SyntaxError: no binding for nonlocal doesn't contain a
	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>


New submission from Alex <alex.gaynor at gmail.com>:

Given the code:

def f():
    def g():
        nonlocal a
        a = 3

Running it produces:

alex at alex-laptop:/tmp$ python3.1 test.py 
SyntaxError: no binding for nonlocal 'a' found

Compared to a different SyntaxError:

alex at alex-laptop:/tmp$ python3.1 test.py 
  File "test.py", line 1
    print a
          ^
SyntaxError: invalid syntax

----------
components: Interpreter Core
messages: 119527
nosy: alex
priority: normal
severity: normal
status: open
title: SyntaxError: no binding for nonlocal doesn't contain a useful traceback
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10189>
_______________________________________

From report at bugs.python.org  Sun Oct 24 22:36:45 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Oct 2010 20:36:45 +0000
Subject: [issue8776] Bytes version of sys.argv
In-Reply-To: <1274357456.02.0.0768864678422.issue8776@psf.upfronthosting.co.za>
Message-ID: <1287952605.11.0.511011044974.issue8776@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Prototype (in Python) of argvb.py. Try it with: ./python -i argvb.py.

It's not possible to create sys.argvb in Python in a module loaded by Py_Initialize(), because sys.argv is created after Py_Initialize().

----------
Added file: http://bugs.python.org/file19355/argvb.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8776>
_______________________________________

From report at bugs.python.org  Sun Oct 24 22:39:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Oct 2010 20:39:06 +0000
Subject: [issue8761] PyUnicode_CompareWithASCIIString name is not mangled
	(UCS2, UCS4)
In-Reply-To: <1274226622.99.0.33307621938.issue8761@psf.upfronthosting.co.za>
Message-ID: <1287952746.12.0.333646115491.issue8761@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r85827.

----------
resolution: accepted -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8761>
_______________________________________

From report at bugs.python.org  Sun Oct 24 22:53:32 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Sun, 24 Oct 2010 20:53:32 +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: <1287953612.17.0.0100653900591.issue10171@psf.upfronthosting.co.za>


Rafe Kettler <rafe.kettler at gmail.com> added the comment:

I haven't had a chance to look too deeply into the source, but it appears (at least in Python 2.7) that the problem has something to do with the commands that the classes in tkMessageBox and tkColorChooser pass to tk.call().

The Message class in tkMessageBox, the Chooser class in tkColorChooser, and the various dialog classes in tkFileDialog all subclass Dialog, which is defined in tkCommonDialog.

Since the dialogs in tkFileDialog have the right buttons, there's probably nothing wrong with the Dialog superclass. However, Chooser and Message both define their own command variables (tk_chooseColor and tk_messageBox, respectively) that are then passed to a Frame's tk.call method.

So, when I get an extra minute I'll go in and see what might be going on with tk_chooseColor and tk_messageBox.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10171>
_______________________________________

From report at bugs.python.org  Sun Oct 24 23:05:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Sun, 24 Oct 2010 21:05:51 +0000
Subject: [issue10161] unittest: use ascii() instead of repr() to display
	values on error
In-Reply-To: <1287620045.08.0.616475344874.issue10161@psf.upfronthosting.co.za>
Message-ID: <1287954351.35.0.237649020249.issue10161@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Closed with r85829: patch test_pep277 instead of unittest.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10161>
_______________________________________

From report at bugs.python.org  Mon Oct 25 00:52:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sun, 24 Oct 2010 22:52:22 +0000
Subject: [issue1542677] compile(): IDLE shell gives different len() of unicode
	strings compared to Python shell
Message-ID: <1287960742.61.0.0906169371087.issue1542677@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Unicode
nosy: +eric.araujo, lemburg, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1542677>
_______________________________________

From report at bugs.python.org  Mon Oct 25 03:11:35 2010
From: report at bugs.python.org (Michael Foord)
Date: Mon, 25 Oct 2010 01:11:35 +0000
Subject: [issue10161] unittest: use ascii() instead of repr() to display
	values on error
In-Reply-To: <1287620045.08.0.616475344874.issue10161@psf.upfronthosting.co.za>
Message-ID: <1287969095.87.0.732297624055.issue10161@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

Although this is still a real issue for other users of unittest. If I get time to think about it properly I may reopen.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10161>
_______________________________________

From report at bugs.python.org  Mon Oct 25 04:01:56 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Oct 2010 02:01:56 +0000
Subject: [issue10189] SyntaxError: no binding for nonlocal doesn't contain a
	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1287972116.99.0.832503237323.issue10189@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

There are a number of such symbol resolution error messages for nonlocal that don't provide location information in symtable.c.  I'm not very experienced with hacking the C code, but a naive addition of location information based on similar calls that do provide it results in error messages that point to the "wrong" line(*).  So my guess is that the person who implemented this code just didn't get around to dealing with that localization issue.

It would appear from svn log like the person in question is Jeremy Hylton, so I'm adding him as nosy.

(*) I put wrong in quotes because it's not wrong from the point of view of the code generating the error, because that code is looking at blocks, not lines.  But it's wrong from the point of view of the user reading the message....

----------
nosy: +jhylton, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10189>
_______________________________________

From report at bugs.python.org  Mon Oct 25 04:09:20 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Oct 2010 02:09:20 +0000
Subject: [issue10189] SyntaxError: no binding for nonlocal doesn't contain a
	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1287972560.98.0.189210391403.issue10189@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Hmm.  Just to clarify, the commit message on the code in question specifically said that the implementation of nonlocal was not complete with that commit, and Jeremy wasn't the only one working on it.  So this detail may have simply been overlooked.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10189>
_______________________________________

From report at bugs.python.org  Mon Oct 25 04:24:48 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Oct 2010 02:24:48 +0000
Subject: [issue1610654] cgi.py multipart/form-data
Message-ID: <1287973488.37.0.241838755116.issue1610654@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I don't think it was appropriate to close this issue.

----------
nosy: +r.david.murray -BreamoreBoy
resolution: wont fix -> 
stage: unit test needed -> 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/issue1610654>
_______________________________________

From report at bugs.python.org  Mon Oct 25 04:35:59 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Oct 2010 02:35:59 +0000
Subject: [issue10189] SyntaxError: no binding for nonlocal doesn't contain a
	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1287974159.81.0.571438026754.issue10189@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Technically, it's because the syntax errors come from a latter part of the compiling phase when the origin of names isn't known. Fixing this would involve attaching line numbers and offsets to names somehow.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10189>
_______________________________________

From report at bugs.python.org  Mon Oct 25 04:36:21 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Oct 2010 02:36:21 +0000
Subject: [issue3196] Option in pydoc to show docs from private methods
In-Reply-To: <1214386355.64.0.670337337662.issue3196@psf.upfronthosting.co.za>
Message-ID: <1287974181.18.0.0301300003652.issue3196@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
status: open -> languishing

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3196>
_______________________________________

From report at bugs.python.org  Mon Oct 25 04:47:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Oct 2010 02:47:07 +0000
Subject: [issue10189] SyntaxError: no binding for nonlocal doesn't contain a
	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1287974827.83.0.361741262682.issue10189@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I figured it was something like that, from looking at the code.

I wonder if it would be worthwhile to return the line info that is known (which I think is the start of the block containing the problematic symbol).  In a complex program that would at least get one close to the problem code.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10189>
_______________________________________

From report at bugs.python.org  Mon Oct 25 05:27:51 2010
From: report at bugs.python.org (Jack Diederich)
Date: Mon, 25 Oct 2010 03:27:51 +0000
Subject: [issue7761] telnetlib Telnet.interact fails on Windows but not Linux
In-Reply-To: <1264212900.62.0.226780855818.issue7761@psf.upfronthosting.co.za>
Message-ID: <1287977271.82.0.257386107765.issue7761@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

Thanks David, do you want to apply?  Looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7761>
_______________________________________

From report at bugs.python.org  Mon Oct 25 06:44:48 2010
From: report at bugs.python.org (Dariusz Suchojad)
Date: Mon, 25 Oct 2010 04:44:48 +0000
Subject: [issue10190] Can argparse._AttributeHolder._get_kwargs become a
	public API?
In-Reply-To: <1287981887.42.0.335099838745.issue10190@psf.upfronthosting.co.za>
Message-ID: <1287981887.42.0.335099838745.issue10190@psf.upfronthosting.co.za>


New submission from Dariusz Suchojad <dsuch at gefira.pl>:

Hello,

I was wondering if it were possible for the argparse._AttributeHolder._get_kwargs to become a part of the public API.

Using this method is a very convenient way to get a hold of the arguments provided by the user and it would be shame to keep it private, I for one use it in several places even though I clearly know the name starts with an underscore, it's just that reimplementing it in my code seems counter-productive, would be very nice if '_get_kwargs' became 'get_kwargs' in some future release.

Thanks for considering it!

----------
assignee: docs at python
components: Documentation, Library (Lib)
messages: 119539
nosy: bethard, docs at python, dsuch
priority: normal
severity: normal
status: open
title: Can argparse._AttributeHolder._get_kwargs become a public API?
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10190>
_______________________________________

From report at bugs.python.org  Mon Oct 25 08:29:18 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 25 Oct 2010 06:29:18 +0000
Subject: [issue1542677] compile(): IDLE shell gives different len() of unicode
	strings compared to Python shell
Message-ID: <1287988158.56.0.50382887459.issue1542677@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As indicated in msg59954, it works fine on 3.x, so removing these versions.

----------
versions:  -Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1542677>
_______________________________________

From report at bugs.python.org  Mon Oct 25 08:48:58 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 25 Oct 2010 06:48:58 +0000
Subject: [issue1542677] IDLE shell gives different len() of unicode strings
	compared to Python shell
Message-ID: <1287989338.05.0.315536342922.issue1542677@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

For 2.7, I don't think it's possible to really fix this. I see the following options:

A. current status. Byte strings are compiled correctly, Unicode strings are not.
B. compile source as a Unicode string, as proposed in msg85886. Unicode strings are compiled propertly, byte strings are not (they get compiled as UTF-8, when they should get compiled in the locale encoding)
C. prefix source with encoding declaration, as proposed in msg85882. Both Unicode strings and byte strings get compiled correctly, but line numbers in tracebacks are wrong.

Given that it's not possible to fix this without breaking something else, and given that it's fixed in Python 3, I propose to declare this as "won't fix" for Python 2.7.

In any case, the bug is certainly not in compile(), which is behaving exactly as specified, so I revert the title change.

----------
title: compile(): IDLE shell gives different len() of unicode strings compared to Python shell -> IDLE shell gives different len() of unicode strings compared to Python shell

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1542677>
_______________________________________

From report at bugs.python.org  Mon Oct 25 09:34:53 2010
From: report at bugs.python.org (Steven Bethard)
Date: Mon, 25 Oct 2010 07:34:53 +0000
Subject: [issue10190] Can argparse._AttributeHolder._get_kwargs become a
	public API?
In-Reply-To: <1287981887.42.0.335099838745.issue10190@psf.upfronthosting.co.za>
Message-ID: <1287992093.19.0.318259102545.issue10190@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Could you elaborate a little on what you use it for? The argparse module only uses this for pretty __repr__ on the various objects. (And in fact, it looks like it's gotten a little out of sync - "required" is missing from Action, and a number of things are missing from ArgumentParser.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10190>
_______________________________________

From report at bugs.python.org  Mon Oct 25 11:30:15 2010
From: report at bugs.python.org (Dariusz Suchojad)
Date: Mon, 25 Oct 2010 09:30:15 +0000
Subject: [issue10190] Can argparse._AttributeHolder._get_kwargs become a
	public API?
In-Reply-To: <1287981887.42.0.335099838745.issue10190@psf.upfronthosting.co.za>
Message-ID: <1287999015.89.0.172516432177.issue10190@psf.upfronthosting.co.za>


Dariusz Suchojad <dsuch at gefira.pl> added the comment:

I find that _AttributeHolder is a handy way for passing the command line options around the application. What is lacks though is a documented API for actually fetching the attributes in batches, like .items() or something similar that could be used for iterating over all command line arguments. That's why I thought '_get_kwargs' would be a good candidate particularly because it does exactly what I need in my code, returns a sorted list of key/value parameters.

But I'm not really saying that it must be '_get_kwargs', could as well be _AttributeHolder's __dict__ attribute as long as the docs say that it's a part of the public API so that I'm sure I'm not using something that may silently break between releases.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10190>
_______________________________________

From report at bugs.python.org  Mon Oct 25 11:34:52 2010
From: report at bugs.python.org (Tim Golden)
Date: Mon, 25 Oct 2010 09:34:52 +0000
Subject: [issue10190] Can argparse._AttributeHolder._get_kwargs become a
	public API?
In-Reply-To: <1287981887.42.0.335099838745.issue10190@psf.upfronthosting.co.za>
Message-ID: <1287999292.31.0.607014972003.issue10190@psf.upfronthosting.co.za>


Tim Golden <mail at timgolden.me.uk> added the comment:

Removing docs unless this actually becomes a doc issue

----------
nosy: +tim.golden -docs at python

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10190>
_______________________________________

From report at bugs.python.org  Mon Oct 25 11:34:57 2010
From: report at bugs.python.org (Tim Golden)
Date: Mon, 25 Oct 2010 09:34:57 +0000
Subject: [issue10190] Can argparse._AttributeHolder._get_kwargs become a
	public API?
In-Reply-To: <1287981887.42.0.335099838745.issue10190@psf.upfronthosting.co.za>
Message-ID: <1287999297.9.0.497288732013.issue10190@psf.upfronthosting.co.za>


Changes by Tim Golden <mail at timgolden.me.uk>:


----------
assignee: docs at python -> bethard

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10190>
_______________________________________

From report at bugs.python.org  Mon Oct 25 11:38:33 2010
From: report at bugs.python.org (=?utf-8?q?Andreas_St=C3=BChrk?=)
Date: Mon, 25 Oct 2010 09:38:33 +0000
Subject: [issue1542677] IDLE shell gives different len() of unicode strings
	compared to Python shell
Message-ID: <1287999513.77.0.237596690691.issue1542677@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/issue1542677>
_______________________________________

From report at bugs.python.org  Mon Oct 25 13:05:38 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 25 Oct 2010 11:05:38 +0000
Subject: [issue10184] tarfile touches directories twice
In-Reply-To: <1287860800.8.0.977653393639.issue10184@psf.upfronthosting.co.za>
Message-ID: <1288004738.16.0.171824581032.issue10184@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I'm not entirely happy with the name of the "touch" argument. Apart from it being nice and short, I think it's a little too unix-y and might be misleading because it is not only about setting the modification time as the name implies, but also owner and mode. My proposal would be "restore_attrs" or "set_attrs" which isn't half as nice as "touch", but sums up better what's actually done. I leave this up to you.

I think the testcase wouldn't work on Windows the way it is now, would it?

Apart from these minor issues the patch gets my blessing, go ahead ;-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10184>
_______________________________________

From report at bugs.python.org  Mon Oct 25 14:34:47 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Oct 2010 12:34:47 +0000
Subject: [issue10190] Can argparse._AttributeHolder._get_kwargs become a
	public API?
In-Reply-To: <1287981887.42.0.335099838745.issue10190@psf.upfronthosting.co.za>
Message-ID: <1288010087.64.0.169613840644.issue10190@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components:  -Documentation
nosy: +eric.araujo
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10190>
_______________________________________

From report at bugs.python.org  Mon Oct 25 14:52:22 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 25 Oct 2010 12:52:22 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1288011142.15.0.680861881172.issue5178@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

Nick, could you comment about my last proposal?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5178>
_______________________________________

From report at bugs.python.org  Mon Oct 25 15:00:07 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 25 Oct 2010 13:00:07 +0000
Subject: [issue10157] Refleaks in pythonrun.c
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1288011607.21.0.167890673776.issue10157@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

I think your patch looks good.

----------
assignee:  -> ocean-city

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10157>
_______________________________________

From report at bugs.python.org  Mon Oct 25 15:05:56 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Oct 2010 13:05:56 +0000
Subject: [issue10143] Update "os.pathconf" values
In-Reply-To: <1287459031.95.0.424598520823.issue10143@psf.upfronthosting.co.za>
Message-ID: <1288011956.33.0.700027142698.issue10143@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Committed in r85834. Solaris 10 now shows 25 names available, instead of 14.

----------
resolution:  -> accepted
stage: needs patch -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10143>
_______________________________________

From report at bugs.python.org  Mon Oct 25 15:06:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Oct 2010 13:06:31 +0000
Subject: [issue1054967] bdist_deb - Debian packager
Message-ID: <1288011991.69.0.679407316831.issue1054967@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
resolution:  -> rejected
stage:  -> committed/rejected
versions: +3rd party -Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1054967>
_______________________________________

From report at bugs.python.org  Mon Oct 25 15:54:32 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Oct 2010 13:54:32 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1288014872.5.0.496411911686.issue10142@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I attach patch. I have reviewed the IO module and I think we don't need to do any change there, since values over 2 are not touched.

The patch is trivial. My plan was to leave this patch for a novice :-).

Please, review. But let me do the final commit (I have commit privileges).

----------
stage: needs patch -> commit review
Added 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  Mon Oct 25 15:55:47 2010
From: report at bugs.python.org (Atsushi Odagiri)
Date: Mon, 25 Oct 2010 13:55:47 +0000
Subject: [issue10191] scripts files are not RECORDed.
In-Reply-To: <1288014947.33.0.874343051999.issue10191@psf.upfronthosting.co.za>
Message-ID: <1288014947.33.0.874343051999.issue10191@psf.upfronthosting.co.za>


New submission from Atsushi Odagiri <aodagx at gmail.com>:

I wrote setup.py includes scripts with distutils2, and ran `setup.py install`.
scripts were installed in scripts directory, but not recorded in .dist-info/RECORD.


I think that `distutils2._backport.shutil:copytree` should return copied filenames.

----------
assignee: tarek
components: Distutils2
files: hello.zip
messages: 119550
nosy: Atsushi.Odagiri, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: scripts files are not RECORDed.
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19357/hello.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10191>
_______________________________________

From report at bugs.python.org  Mon Oct 25 15:57:49 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Oct 2010 13:57:49 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1288015069.81.0.114793808368.issue10142@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

[jcea at babylon5 py3k]$ ./python
Python 3.2a3+ (py3k:85834M, Oct 25 2010, 15:37:04)
[GCC 4.5.1] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.SEEK_DATA
3
>>> os.SEEK_HOLE
4
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Mon Oct 25 16:08:18 2010
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 25 Oct 2010 14:08:18 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1288015698.27.0.923928255792.issue9935@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

I doubt I, or Ask will have the time to rewrite the entire multiprocessing test suite right now to work around the change Antoine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9935>
_______________________________________

From report at bugs.python.org  Mon Oct 25 16:17:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Oct 2010 14:17:24 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1285290424.33.0.0824621979691.issue9935@psf.upfronthosting.co.za>
Message-ID: <1288016244.42.0.748446045905.issue9935@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I doubt I, or Ask will have the time to rewrite the entire
> multiprocessing test suite right now to work around the change
> Antoine.

Well, I'm not asking anyone to rewrite the entire multiprocessing test suite; and, besides, I've provided a patch myself to improve it in that respect ;) (in issue10173)

Of course, it also means the present pickle patch is imperfect, though the result of __reduce__ in this case looks more like a side-effect of an implementation detail than documented behaviour (since the result isn't usable anyway). I may try to come up with a better patch before the 3.2 beta but it's not sure I will find enough time/motivation.

----------
resolution: fixed -> 
stage: committed/rejected -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9935>
_______________________________________

From report at bugs.python.org  Mon Oct 25 16:18:42 2010
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 25 Oct 2010 14:18:42 +0000
Subject: [issue6645] multiprocessing build fails on AIX - /dev/urandom (or
	equivalent) not found
In-Reply-To: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
Message-ID: <1288016322.82.0.259154688958.issue6645@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Sridhar can you confirm if this is still a problem on 3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6645>
_______________________________________

From report at bugs.python.org  Mon Oct 25 16:20:42 2010
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 25 Oct 2010 14:20:42 +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: <1288016442.16.0.547580881382.issue6269@psf.upfronthosting.co.za>


Changes by Jesse Noller <jnoller at gmail.com>:


----------
assignee: jnoller -> nobody
keywords: +easy
nosy: +nobody
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6269>
_______________________________________

From report at bugs.python.org  Mon Oct 25 16:23:39 2010
From: report at bugs.python.org (Jesse Noller)
Date: Mon, 25 Oct 2010 14:23:39 +0000
Subject: [issue9935] Faster pickling of instances
In-Reply-To: <1288016244.42.0.748446045905.issue9935@psf.upfronthosting.co.za>
Message-ID: <AANLkTikKfgM4BvqgN7G-NXQUg1hPg-1c_gnf=jUe5EyV@mail.gmail.com>


Jesse Noller <jnoller at gmail.com> added the comment:

On Mon, Oct 25, 2010 at 10:17 AM, Antoine Pitrou <report at bugs.python.org> wrote:

> Well, I'm not asking anyone to rewrite the entire multiprocessing test suite; and, besides, I've provided a patch myself to improve it in that respect ;) (in issue10173)

I just saw that one - I'll poke at that next

> Of course, it also means the present pickle patch is imperfect, though the result of __reduce__ in this case looks more like a side-effect of an implementation detail than documented behaviour (since the result isn't usable anyway). I may try to come up with a better patch before the 3.2 beta but it's not sure I will find enough time/motivation.

Okie doke.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9935>
_______________________________________

From report at bugs.python.org  Mon Oct 25 16:36:48 2010
From: report at bugs.python.org (Andrew Boettcher)
Date: Mon, 25 Oct 2010 14:36:48 +0000
Subject: [issue1191964] asynchronous Subprocess
Message-ID: <1288017408.21.0.561221797233.issue1191964@psf.upfronthosting.co.za>


Changes by Andrew Boettcher <a.boettcher at gmail.com>:


----------
nosy: +Andrew.Boettcher

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1191964>
_______________________________________

From report at bugs.python.org  Mon Oct 25 18:03:06 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Oct 2010 16:03:06 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288022586.34.0.216868175839.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I am trying to review this for 3.2, but I am having some issues. For instance, "include/pydtrace.d" is not present in the last patch.

Please, post a patch with all the required changes in the same (patch) file. Hurry, we are still on track for 3.2. :-).

Another question: I am not able to decide between Sun/Apple style, or breaking dtrace scripts compatibility completely. Anybody has an opinion about this?. Is this actually important?. Are there so many legacy dtrace scripts out there?.

----------
assignee:  -> dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 18:15:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Oct 2010 16:15:52 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1288022586.34.0.216868175839.issue4111@psf.upfronthosting.co.za>
Message-ID: <AANLkTim8uyP8mM6ph=N94-4iQBOp10L6TAiz1wm=Foe8@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

2010/10/25 Jes?s Cea Avi?n <report at bugs.python.org>:
..
> Another question: I am not able to decide between Sun/Apple style, or breaking dtrace scripts
> compatibility completely. Anybody has an opinion about this?. Is this actually important?. Are
> there so many legacy dtrace scripts out there?.
>

I would say compatibility with Sun/Apple probes should not stand in
the way of implementing this in cpython.  Of course familiarity to
existing users is a consideration, but in cases where self-consistency
can be improved, I don't think we should be overly concerned about
legacy scripts.  I would estimate that 90% of future users will never
have used either Sun or Apple probes, 9% will have used Apple and 1%
Sun. (This is completely unscientific guess, of course.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 18:26:19 2010
From: report at bugs.python.org (hhas)
Date: Mon, 25 Oct 2010 16:26:19 +0000
Subject: [issue10192] 'from urllib.parse import *' does not import urlencode
	function
In-Reply-To: <1288023979.78.0.403326103088.issue10192@psf.upfronthosting.co.za>
Message-ID: <1288023979.78.0.403326103088.issue10192@psf.upfronthosting.co.za>


New submission from hhas <hhas at users.sourceforge.net>:

Problem:

The following statement fails to import the public urlencode function into the current namespace:

    from urllib.parse import *

Solution:

Add 'urlencode' to urllib.parse.__all__.

----------
components: Library (Lib)
messages: 119558
nosy: hhas
priority: normal
severity: normal
status: open
title: 'from urllib.parse import *' does not import urlencode function
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10192>
_______________________________________

From report at bugs.python.org  Mon Oct 25 18:27:58 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 25 Oct 2010 16:27:58 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288024078.65.0.619239571319.issue4111@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Updated version of the patch; this ought to contain Include/pydtrace.d:

$ diffstat /tmp/py3k-add-systemtap-2010-10-25.patch
 Include/pydtrace.d         |   10 
 Lib/test/test_systemtap.py |   89 ++++++
 Makefile.pre.in            |   10 
 Python/ceval.c             |   75 +++++
 configure                  |  576 +++++++++++++++++++++++----------------------
 configure.in               |   34 ++
 pyconfig.h.in              |    3 
 7 files changed, 522 insertions(+), 275 deletions(-)

Patch contains FIXMEs (sorry), which clearly need addressing.

As for the objectives, do folks here agree with the "Performance" notes in http://bugs.python.org/issue4111#msg100173 ?

----------
Added file: http://bugs.python.org/file19358/py3k-add-systemtap-2010-10-25.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 18:37:01 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Mon, 25 Oct 2010 16:37:01 +0000
Subject: [issue10192] 'from urllib.parse import *' does not import urlencode
	function
In-Reply-To: <1288023979.78.0.403326103088.issue10192@psf.upfronthosting.co.za>
Message-ID: <1288024621.87.0.993051345139.issue10192@psf.upfronthosting.co.za>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

Fixed in revision 85837.

----------
assignee:  -> orsenthil
nosy: +orsenthil
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10192>
_______________________________________

From report at bugs.python.org  Mon Oct 25 18:54:11 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Oct 2010 16:54:11 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288025651.75.0.376071418714.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Malcolm, does your last patch address the performance issue?. Ideally, dtrace support should be compiled in by default, so performance issues are important.

Idealy, performance difference between compiling dtrace or not should be negligible. Until you actually use it, of course.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 18:54:57 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 25 Oct 2010 16:54:57 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288025697.23.0.13748675867.issue4111@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/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 19:00:09 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Oct 2010 17:00:09 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288026009.12.0.722333495684.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

We need some documentation, too.

Maybe a new chapter, or a new section in the debug chapter. Better the first, since this is not only for debugging, but for performance study too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 19:02:08 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Oct 2010 17:02:08 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288026128.99.0.0222834439127.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Compiling the code WITHOUT dtrace support gives an error:

"""
Undefined                       first referenced
 symbol                             in file
__dtrace_python___function__entry   ./libpython3.2m.so
__dtraceenabled_python___function__return ./libpython3.2m.so
__dtrace_python___function__return  ./libpython3.2m.so
__dtraceenabled_python___function__entry ./libpython3.2m.so
ld: fatal: Symbol referencing errors. No output written to python
collect2: ld returned 1 exit status
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 19:12:20 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Oct 2010 17:12:20 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288026740.13.0.0319015307415.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Compiling WITH dtrace... shows the same error :-????

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 19:17:18 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 25 Oct 2010 17:17:18 +0000
Subject: [issue10189] SyntaxError: no binding for nonlocal doesn't contain a
	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1288027038.44.0.852341595489.issue10189@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1 for adding at least the info the symtable knows (this is already done in one of the branches in that function that raises a SyntaxError).

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10189>
_______________________________________

From report at bugs.python.org  Mon Oct 25 19:27:05 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Oct 2010 17:27:05 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288027625.31.0.820491272764.issue4111@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I am using Solaris 10, but the configure script detects "apple" implementation.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 19:30:25 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Oct 2010 17:30:25 +0000
Subject: [issue10189] SyntaxError: no binding for nonlocal doesn't contain a
	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1288027825.47.0.465421996189.issue10189@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <benjamin at python.org>:


----------
assignee:  -> benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10189>
_______________________________________

From report at bugs.python.org  Mon Oct 25 19:37:05 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Mon, 25 Oct 2010 17:37:05 +0000
Subject: [issue10184] tarfile touches directories twice
In-Reply-To: <1287860800.8.0.977653393639.issue10184@psf.upfronthosting.co.za>
Message-ID: <1288028225.67.0.481153754187.issue10184@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 tracker <report at bugs.python.org>
<http://bugs.python.org/issue10184>
_______________________________________

From report at bugs.python.org  Mon Oct 25 19:50:34 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 25 Oct 2010 17:50:34 +0000
Subject: [issue3018] tkinter demos fixed
In-Reply-To: <1212241760.64.0.0978196091903.issue3018@psf.upfronthosting.co.za>
Message-ID: <1288029034.03.0.353991658429.issue3018@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed remaining changes from patch in r85840.  Thanks!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3018>
_______________________________________

From report at bugs.python.org  Mon Oct 25 19:56:06 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 25 Oct 2010 17:56:06 +0000
Subject: [issue1772788] chr(128) in u'only ascii' -> TypeError with misleading
	msg
Message-ID: <1288029366.46.0.00126277492295.issue1772788@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't think we'll do anything about this message in 2.x -- in 3.x you get a clear TypeError anyway if you mix str and bytes.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772788>
_______________________________________

From report at bugs.python.org  Mon Oct 25 19:56:39 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 25 Oct 2010 17:56:39 +0000
Subject: [issue4402] os.getenv('PATH') return different result between 2.5 and
	3.0rc3
In-Reply-To: <1227493261.31.0.743303269102.issue4402@psf.upfronthosting.co.za>
Message-ID: <1288029399.84.0.390410845393.issue4402@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
Removed message: http://bugs.python.org/msg76444

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4402>
_______________________________________

From report at bugs.python.org  Mon Oct 25 20:48:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Oct 2010 18:48:47 +0000
Subject: [issue10193] Simplify instrospection used by turtle module
In-Reply-To: <1288032526.99.0.352179918003.issue10193@psf.upfronthosting.co.za>
Message-ID: <1288032526.99.0.352179918003.issue10193@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The turtle module uses introspection in order to generate module level functions.  Attached patch streamlines the introspection code by using inspect module function instead of direct access to cod object attributes.

----------
components: Library (Lib)
files: turtle-inspect.diff
keywords: patch
messages: 119569
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Simplify instrospection used by turtle module
versions: Python 3.2
Added file: http://bugs.python.org/file19359/turtle-inspect.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10193>
_______________________________________

From report at bugs.python.org  Mon Oct 25 21:16:42 2010
From: report at bugs.python.org (R. David Murray)
Date: Mon, 25 Oct 2010 19:16:42 +0000
Subject: [issue1772788] chr(128) in u'only ascii' -> TypeError with misleading
	msg
Message-ID: <1288034202.36.0.422349174341.issue1772788@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I'm not sure that I'd consider:

>>> 'abc' in b'abcde'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: Type str doesn't support the buffer API

a clear error message :)  It certainly isn't as bad as the 2.x message, though.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772788>
_______________________________________

From report at bugs.python.org  Mon Oct 25 21:30:07 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 25 Oct 2010 19:30:07 +0000
Subject: [issue10094] test_urllib.py fails in py3k r85440 with RuntimeError
In-Reply-To: <1287009982.88.0.0149254747743.issue10094@psf.upfronthosting.co.za>
Message-ID: <1288035007.57.0.587628195052.issue10094@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

This was already backported but the issue wasn't closed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10094>
_______________________________________

From report at bugs.python.org  Mon Oct 25 21:33:28 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 25 Oct 2010 19:33:28 +0000
Subject: [issue9762] PEP 3149 related build failures
In-Reply-To: <1283542817.2.0.95523590272.issue9762@psf.upfronthosting.co.za>
Message-ID: <1288035208.7.0.0298441386285.issue9762@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Closing this because I can't think of anything better than your workaround (plus, I was apparently unable to reproduce it).

----------
resolution:  -> fixed
status: open -> closed
title: build failures -> PEP 3149 related build failures

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9762>
_______________________________________

From report at bugs.python.org  Mon Oct 25 21:34:20 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 25 Oct 2010 19:34:20 +0000
Subject: [issue1288056] pygettext: extract translators comments
Message-ID: <1288035260.04.0.925659995697.issue1288056@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/issue1288056>
_______________________________________

From report at bugs.python.org  Mon Oct 25 21:34:57 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 25 Oct 2010 19:34:57 +0000
Subject: [issue8409] gettext should honor $LOCPATH environment variable
In-Reply-To: <1271341694.43.0.480005164083.issue8409@psf.upfronthosting.co.za>
Message-ID: <1288035297.82.0.963583667017.issue8409@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/issue8409>
_______________________________________

From report at bugs.python.org  Mon Oct 25 21:35:22 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 25 Oct 2010 19:35:22 +0000
Subject: [issue8769] Straightforward usage of email package fails to round-trip
In-Reply-To: <1274302519.83.0.146401120937.issue8769@psf.upfronthosting.co.za>
Message-ID: <1288035322.57.0.797837579307.issue8769@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
assignee: barry -> r.david.murray
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8769>
_______________________________________

From report at bugs.python.org  Mon Oct 25 21:49:33 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 25 Oct 2010 19:49:33 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1288036173.97.0.0461014998192.issue10142@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The patch lacks a documentation change. Otherwise, it looks fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Mon Oct 25 21:53:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Oct 2010 19:53:57 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1288036437.32.0.698065017705.issue10142@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think the docs should also make it clear that these flags are only supported by os.lseek() (unless you have tested the IO lib to work properly, that is, but in this case it would be nice to add unit tests).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Mon Oct 25 22:10:34 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Mon, 25 Oct 2010 20:10:34 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1287458119.59.0.0883351132174.issue10142@psf.upfronthosting.co.za>
Message-ID: <1288037434.81.0.213177498037.issue10142@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

I will update documentation.

Antoine, it is difficult to write a testcase when I can only test under a system with ZFS. I don't think we have a buildbot with Solaris/*BSD and ZFS.

Any suggestion?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Mon Oct 25 22:23:39 2010
From: report at bugs.python.org (Danek Duvall)
Date: Mon, 25 Oct 2010 20:23:39 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288038219.31.0.814276822812.issue4111@psf.upfronthosting.co.za>


Changes by Danek Duvall <duvall at comfychair.org>:


----------
nosy: +dhduvall

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 22:25:02 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Oct 2010 20:25:02 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1288037434.81.0.213177498037.issue10142@psf.upfronthosting.co.za>
Message-ID: <1288038298.3589.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I will update documentation.
> 
> Antoine, it is difficult to write a testcase when I can only test
> under a system with ZFS. I don't think we have a buildbot with
> Solaris/*BSD and ZFS.

If you ascertain yourself that the test works under ZFS then I think it
is enough. Of course, it would be better if a buildbot ran that test,
but we can live without it (IMHO).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Mon Oct 25 22:33:52 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Mon, 25 Oct 2010 20:33:52 +0000
Subject: [issue10142] Support for SEEK_HOLE/SEEK_DATA
In-Reply-To: <1288038298.3589.11.camel@localhost.localdomain>
Message-ID: <4CC5E9AD.2060907@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> If you ascertain yourself that the test works under ZFS then I think it
> is enough. Of course, it would be better if a buildbot ran that test,
> but we can live without it (IMHO).

I agree. I trust that the patch is correct, and we really don't need to
test whether ZFS works correctly (but trust that Oracle will).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10142>
_______________________________________

From report at bugs.python.org  Mon Oct 25 22:39:40 2010
From: report at bugs.python.org (Frank Ch. Eigler)
Date: Mon, 25 Oct 2010 20:39:40 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288039180.5.0.252399168468.issue4111@psf.upfronthosting.co.za>


Frank Ch. Eigler <fche at elastic.org> added the comment:

I believe the problem jcea is experiencing is with the
solaris (/linux?) branch of the configure.in:

    if dtrace -G -o /dev/null -s $srcdir/Include/pydtrace.d 2>/dev/null

It seems solaris doesn't like the -o /dev/null part.  Try
specifying some real temporary file name instead.

----------
nosy: +fche

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 23:20:53 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 25 Oct 2010 21:20:53 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288041653.29.0.548287791975.issue4111@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Updated patch, removing the FIXMEs, and slightly reworking the test code.

I've wrapped the whole of get_frame_marker_info with a PyErr_Fetch/PyErr_Restore pair: the PyUnicode_AsUTF8String calls could fail with a MemoryError, and we don't want to confuse the regular exception handling within ceval.

I'm not sure how to write a unit test to test for this: perhaps we could corrupt the __code__ instance so that co_filename is not a PyUnicodeObject, leading to a TypeError within the function, but that's a readonly attribute.  Any ideas?

I've also added a unit test for a non-ASCII script (Lib/test/systemtap_sample_?.py), containing a non-ASCII identifier (????).

The non-ASCII script name (Lib/test/systemtap_sample_?.py) may be controversial: do we have anything like that in the source tree yet?  Is there any risk of messing up the build across platforms, or of impacting the Hg migration?

Still to-do:
  - address the "Undefined symbol" issues seen by jcea.
  - documentation
  - doublecheck performance

----------
Added file: http://bugs.python.org/file19360/py3k-add-systemtap-2010-10-25-002.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 23:42:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Oct 2010 21:42:35 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1288041653.29.0.548287791975.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288042950.3589.18.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I've wrapped the whole of get_frame_marker_info with a
> PyErr_Fetch/PyErr_Restore pair: the PyUnicode_AsUTF8String calls could
> fail with a MemoryError, and we don't want to confuse the regular
> exception handling within ceval.

If PyUnicode_AsUTF8String() is meant to encode a filename, you should
use PyUnicode_EncodeFSDefault() instead.

> The non-ASCII script name (Lib/test/systemtap_sample_?.py) may be
> controversial: do we have anything like that in the source tree yet?
> Is there any risk of messing up the build across platforms, or of
> impacting the Hg migration?

It would be better to generate the sample dynamically, so that users
with an incompatible locale or filesystem aren't prevented from checking
out the source.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Mon Oct 25 23:45:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 25 Oct 2010 21:45:25 +0000
Subject: [issue1772788] chr(128) in u'only ascii' -> TypeError with misleading
	msg
Message-ID: <1288043125.57.0.518125505714.issue1772788@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ah. I tried the other combination :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772788>
_______________________________________

From report at bugs.python.org  Mon Oct 25 23:48:14 2010
From: report at bugs.python.org (Peter Ingebretson)
Date: Mon, 25 Oct 2010 21:48:14 +0000
Subject: [issue10194] Add gc.remap() function to the gc module.
In-Reply-To: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>
Message-ID: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>


New submission from Peter Ingebretson <pingebre at yahoo.com>:

This patch implements the gc.remap() function as described in the following document:

http://doublestar.org/in-place-python-reloading/

The intended use is an enhanced module reloading mechanism, a prototype of which is described here:

http://doublestar.org/python-hot-loading-prototype/

The patch includes unit tests for gc.remap as well as documentation.  The NEWS has a TODO where the issue number would be, which needs to be updated.  The unit test suite has been run on Ubuntu 10.10 and Windows XP.

----------
components: Extension Modules
files: python_remap.diff
keywords: patch
messages: 119582
nosy: pingebretson
priority: normal
severity: normal
status: open
title: Add gc.remap() function to the gc module.
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19361/python_remap.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10194>
_______________________________________

From report at bugs.python.org  Mon Oct 25 23:56:57 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 25 Oct 2010 21:56:57 +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: <1288043817.65.0.125905157317.issue9807@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/issue9807>
_______________________________________

From report at bugs.python.org  Tue Oct 26 00:13:41 2010
From: report at bugs.python.org (Peter Ingebretson)
Date: Mon, 25 Oct 2010 22:13:41 +0000
Subject: [issue10194] Add gc.remap() function to the gc module.
In-Reply-To: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>
Message-ID: <1288044821.45.0.980007677963.issue10194@psf.upfronthosting.co.za>


Changes by Peter Ingebretson <pingebre at yahoo.com>:


Added file: http://bugs.python.org/file19362/issue10194_gc_remap.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10194>
_______________________________________

From report at bugs.python.org  Tue Oct 26 00:14:06 2010
From: report at bugs.python.org (Peter Ingebretson)
Date: Mon, 25 Oct 2010 22:14:06 +0000
Subject: [issue10194] Add gc.remap() function to the gc module.
In-Reply-To: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>
Message-ID: <1288044846.29.0.845538835119.issue10194@psf.upfronthosting.co.za>


Changes by Peter Ingebretson <pingebre at yahoo.com>:


Removed file: http://bugs.python.org/file19361/python_remap.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10194>
_______________________________________

From report at bugs.python.org  Tue Oct 26 00:52:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Oct 2010 22:52:01 +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: <1288047121.21.0.239070577343.issue6269@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee: nobody -> docs at python
nosy: +docs at python
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6269>
_______________________________________

From report at bugs.python.org  Tue Oct 26 00:52:37 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 25 Oct 2010 22:52:37 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288047157.06.0.8904525696.issue4111@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

> It would be better to generate the sample dynamically, so that users
> with an incompatible locale or filesystem aren't prevented from checking
> out the source.
Thanks: am attaching updated patch: I've removed Lib/test/systemtap_sample_?.py, and now generate a similarly-named file during the test, using test.support.TEST_FN and unlink

Still TODO:
  - address pitrou's concerns about PyUnicode_AsUTF8String from msg119580
  - address the "Undefined symbol" issues seen by jcea (msg119563 onwards)
  - documentation
  - doublecheck performance
  - perhaps add a systemtap "tapset", and demo code using it (like I did in Fedora's python3 RPMs)
  - anything else I've missed :)

----------
Added file: http://bugs.python.org/file19363/py3k-add-systemtap-2010-10-25-003.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Oct 26 01:05:46 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Mon, 25 Oct 2010 23:05:46 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288047946.76.0.604930549263.issue4111@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

I should note that I've only ever been testing this with SystemTap, on Linux.  I don't have a box with DTrace, and I've never directly used it.  I wouldn't today be able to diagnose a buildbot failure related to DTrace (I believe I would with systemtap, fwiw).

Are there any DTrace experts around who would be willing to handle the DTrace side of this?  If not, would it be reasonable to make this issue be only explicitly about "systemtap"?  (e.g. perhaps change the "configure" argument accordingly?)  Alternatively, given that this bug originally started as an RFE about DTrace, should we split out systemtap as a separate RFE?

I'm sorry if I've "muddied the waters" by doing this.

For example, the only test coverage I've written (test_systemtap.py) checks for the presence of a "stap" executable, and skips the tests if it's not found.  I'm not familiar enough with DTrace to create the same for DTrace.

FWIW (in response to IRC question): "thread_indent" is documented here:
http://sourceware.org/systemtap/SystemTap_Beginners_Guide/systemtapscript-handler.html#thread_indent

It looks like it may be systemtap-specific; however the only usage is within test_systemtap.py, guarded by the presence of a "stap" binary, skipping the tests if it is not found.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Oct 26 01:45:58 2010
From: report at bugs.python.org (Bobby Impollonia)
Date: Mon, 25 Oct 2010 23:45:58 +0000
Subject: [issue775964] fix test_grp failing when NIS entries present
Message-ID: <1288050358.52.0.539210558191.issue775964@psf.upfronthosting.co.za>


Bobby Impollonia <bobbyi at gmail.com> added the comment:

I am encountering this issue with py3k on a Debian machine. test_grp consistently fails due to a line with a plus sign in /etc/group

I believe that the previous patch attached to this bug is not correct due to the issues others have raised: It only handles lines with a plus sign as the name (not any name starting with '+' or '-') and it breaks out of the loop when it finds one, silently discarding any remaining lines.

I've attached a new patch which preserves the functionality of getgrall but updates its docstring to document that any group names starting with '+' or '-' represent NIS-related entries. The patch fixes the test itself so that it skips over NIS-related entries rather than attempting to look them up with grp.getgrnam.

With this patch applied (to the py3k branch HEAD), all regression tests pass on my machine.

----------
nosy: +bobbyi
title: fix test_grp failing on RedHat 6.2 -> fix test_grp failing when NIS entries present
versions: +Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19364/test_grp.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775964>
_______________________________________

From report at bugs.python.org  Tue Oct 26 02:23:49 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 26 Oct 2010 00:23:49 +0000
Subject: [issue10195] Memory allocation fault-injection?
In-Reply-To: <1288052629.43.0.603183515135.issue10195@psf.upfronthosting.co.za>
Message-ID: <1288052629.43.0.603183515135.issue10195@psf.upfronthosting.co.za>


New submission from Dave Malcolm <dmalcolm at redhat.com>:

We were chatting on #python-dev on possible ways of testing the correct handling of "MemoryError".

Attached is one idea: adding a sys._inject_malloc_failure() hook, letting you inject a memory-allocation (or reallocation) failure some number of allocations in the future:

>>> import sys
[52733 refs]
>>> 2 + 2
4
[52733 refs]
>>> sys._inject_malloc_failure(50)
[52733 refs]
>>> 2 + 2
MemoryError
[52747 refs]
>>> 2 + 2
4
[52747 refs]

I'm not sure how to make this useful; perhaps it could instead compare with the "serialno" in Objects/obmalloc.c so that you could set up a specific numbered allocation and have it fail (or perhaps a range of serial numbers, and expose "serialno" within the "sys" module?)

Another idea might be to randomly have some proportion of allocations fail.  Perhaps the test suite could have an option where it runs each set of tests in a separate subprocess, and sets a command-line switch to inject "random" malloc failures? (storing the seed, so that they're reproducible, on one machine at least).

----------
components: Tests
files: py3k-inject-malloc-failure.txt
messages: 119586
nosy: dmalcolm, pitrou
priority: normal
severity: normal
status: open
title: Memory allocation fault-injection?
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19365/py3k-inject-malloc-failure.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10195>
_______________________________________

From report at bugs.python.org  Tue Oct 26 04:40:29 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Oct 2010 02:40:29 +0000
Subject: [issue10194] Add gc.remap() function to the gc module.
In-Reply-To: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>
Message-ID: <1288060829.77.0.636655786318.issue10194@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +pitrou
stage:  -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10194>
_______________________________________

From report at bugs.python.org  Tue Oct 26 05:30:48 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Oct 2010 03:30:48 +0000
Subject: [issue10194] Add gc.remap() function to the gc module.
In-Reply-To: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>
Message-ID: <1288063848.95.0.254157055554.issue10194@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

I think you need to bring this up on python-ideas/python-dev.

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10194>
_______________________________________

From report at bugs.python.org  Tue Oct 26 05:42:50 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Oct 2010 03:42:50 +0000
Subject: [issue10195] Memory allocation fault-injection?
In-Reply-To: <1288052629.43.0.603183515135.issue10195@psf.upfronthosting.co.za>
Message-ID: <1288064570.92.0.467473396723.issue10195@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

We should do something like SQLite: http://sqlite.org/testing.html

----------
nosy: +benjamin.peterson

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10195>
_______________________________________

From report at bugs.python.org  Tue Oct 26 06:37:13 2010
From: report at bugs.python.org (Jack Diederich)
Date: Tue, 26 Oct 2010 04:37:13 +0000
Subject: [issue10176] telnetlib.Telnet.read_very_eager() performance
In-Reply-To: <1287829886.22.0.155091946841.issue10176@psf.upfronthosting.co.za>
Message-ID: <1288067833.3.0.781874256259.issue10176@psf.upfronthosting.co.za>


Jack Diederich <jackdied at gmail.com> added the comment:

There was no test suite for telnetlib prior to 2.7/3.1 so it is easily possible that this is a regression.  If you can post a test case that fails or - even better - a patch that passes where the current code fails I'd be very appreciative.

----------
nosy: +jackdied

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10176>
_______________________________________

From report at bugs.python.org  Tue Oct 26 07:33:18 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Tue, 26 Oct 2010 05:33:18 +0000
Subject: [issue10196] distutils.get_python_lib() returns
	/usr/local/python3/dist-packages on Ubuntu 10.10
In-Reply-To: <1288071198.84.0.0625228182395.issue10196@psf.upfronthosting.co.za>
Message-ID: <1288071198.84.0.0625228182395.issue10196@psf.upfronthosting.co.za>


New submission from Bruce Sherwood <bruce.sherwood at gmail.com>:

Using Python 3.1 installed on Ubuntu 10.10 from the package manager, distutils.get_python_lib() returns the nonexistent location /usr/local/python3/dist-packages instead of the correct location /usr/local/python3.1/dist-packages. This subversion bug is not present in distutils.get_python_inc(), which correctly returns /usr/include/python3.1.

----------
assignee: tarek
components: Distutils
messages: 119590
nosy: Bruce.Sherwood, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: distutils.get_python_lib() returns /usr/local/python3/dist-packages on Ubuntu 10.10
type: behavior
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10196>
_______________________________________

From report at bugs.python.org  Tue Oct 26 07:35:13 2010
From: report at bugs.python.org (Jon Parise)
Date: Tue, 26 Oct 2010 05:35:13 +0000
Subject: [issue10194] Add gc.remap() function to the gc module.
In-Reply-To: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>
Message-ID: <1288071313.51.0.204850890288.issue10194@psf.upfronthosting.co.za>


Changes by Jon Parise <jon at indelible.org>:


----------
nosy: +jon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10194>
_______________________________________

From report at bugs.python.org  Tue Oct 26 07:44:03 2010
From: report at bugs.python.org (Andrew Svetlov)
Date: Tue, 26 Oct 2010 05:44:03 +0000
Subject: [issue10194] Add gc.remap() function to the gc module.
In-Reply-To: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>
Message-ID: <1288071843.26.0.915320000842.issue10194@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/issue10194>
_______________________________________

From report at bugs.python.org  Tue Oct 26 08:11:23 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Oct 2010 06:11:23 +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: <1288073483.15.0.183098322325.issue10107@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

The attached patches implement an "exit" callback for IDLE on OS X that ensures IDLE will not terminate from an application Quit command without giving the opportunity to save files.

----------
assignee: ned.deily -> ronaldoussoren
components: +Macintosh
keywords: +patch
priority: normal -> high
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19366/issue10107-py3k-31.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Tue Oct 26 08:12:09 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Oct 2010 06:12:09 +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: <1288073529.7.0.61371412558.issue10107@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


Added file: http://bugs.python.org/file19367/issue10107-27.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Tue Oct 26 08:21:26 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Oct 2010 06:21:26 +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: <1288074086.58.0.995248642829.issue10107@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

BTW, the patched IDLEs were tested on 2.7 and py3k (3.2a3+) on 10.4, 10.5, and 10.6 with the Apple-supplied Tk 8.4 (all), the Apple-supplied Tk 8.5 (available only in 10.6), ActiveState Tk 8.4 (all), and ActiveState 8.5 (all).  And the patches have no affect nor are needed when linked with an X11-based Tk on OS X.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10107>
_______________________________________

From report at bugs.python.org  Tue Oct 26 10:39:54 2010
From: report at bugs.python.org (ptz)
Date: Tue, 26 Oct 2010 08:39:54 +0000
Subject: [issue10176] telnetlib.Telnet.read_very_eager() performance
In-Reply-To: <1287829886.22.0.155091946841.issue10176@psf.upfronthosting.co.za>
Message-ID: <1288082394.63.0.829203242338.issue10176@psf.upfronthosting.co.za>


ptz <pptzpp at gmail.com> added the comment:

As David suggested, it indeed seems to be a case of timing. When telnetlib.Telnet(...) returns, the server still doesn't have the data cooked, and read_very_eager() fetches nothing. So nothing here fails as such, it's just that my 0 experience in network programming showed.

Either way, some things you could do to get the function g() above to fetch the data the server usually returns upon connection are:

a) insert a time.sleep(t) line after creating the socket. But I don't think there is one answer as to what the value of t should be.
b) if one knows the format of the data that will be received, one could use read_until("expected string")
c) one could write something like

    >>> def g():
    ...   f = telnetlib.Telnet("chessclub.com")
    ...   data = ''
    ...   while not data:
    ...     data = f.read_some()
    ...   print data,f.read_very_eager()
    ...
    >>>

This simply loops until the server has some cooked data available, then fetches it. Tested, works, and is probably the way to do it.

Either way, like David wisely said, this isn't an issue with either Python or telnetlib. However, it may be a good idea to add a warning to the documentation to the effect that by the time the Telnet constructor returns cooked data is typically not yet available from the server. To a beginner network programmer, this is far from obvious.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10176>
_______________________________________

From report at bugs.python.org  Tue Oct 26 10:46:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 08:46:31 +0000
Subject: [issue10194] Add gc.remap() function to the gc module.
In-Reply-To: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>
Message-ID: <1288082791.75.0.429029370788.issue10194@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Agreed with Benjamin. There is already a visible issue with the patch: it breaks compatibility because the Py_VISIT() argument must now be an lvalue.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10194>
_______________________________________

From report at bugs.python.org  Tue Oct 26 10:47:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 08:47:46 +0000
Subject: [issue10195] Memory allocation fault-injection?
In-Reply-To: <1288052629.43.0.603183515135.issue10195@psf.upfronthosting.co.za>
Message-ID: <1288082866.21.0.962593822107.issue10195@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Unless we want to test manually each memory allocation in the interpreter, the only reasonable way seems to be some kind of fuzzing (perhaps using a reproducible random seed).

----------
nosy: +haypo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10195>
_______________________________________

From report at bugs.python.org  Tue Oct 26 11:12:21 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 26 Oct 2010 09:12:21 +0000
Subject: [issue5178] Add context manager for temporary directory
In-Reply-To: <1234029261.42.0.975383428204.issue5178@psf.upfronthosting.co.za>
Message-ID: <1288084341.57.0.191339927906.issue5178@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Merging the interfaces for mkdtemp and TemporaryDirectory isn't going to happen.

mkstemp/mkdtemp are for when the user wants to control the lifecycle of the filesystem entries themselves. (Note that context management on a regular file-like object only closes the file, it doesn't delete it from the filesystem). They're also intended as relatively thin wrappers around the corresponding C standard library functionality.

The other objects in tempfile (TemporaryFile, TemporaryDirectory, etc) are for when the user wants the lifecycle of the Python object to correspond with the lifecycle of the underlying filesystem element.

That said, TD itself can be used to create the temporary directory without having to use it as a context manager (the underlying directory is created in __init__, not __enter__).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5178>
_______________________________________

From report at bugs.python.org  Tue Oct 26 12:06:18 2010
From: report at bugs.python.org (Ray.Allen)
Date: Tue, 26 Oct 2010 10:06:18 +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: <1288087578.97.0.525331191674.issue6269@psf.upfronthosting.co.za>


Ray.Allen <ysj.ray at gmail.com> added the comment:

Agree with Jesse, the description in the patch is not quite correct. I think detailed description of the GIL has been given in C API documentation: http://docs.python.org/c-api/init.html#thread-state-and-the-global-interpreter-lock. How about just give this link in threading module documentation?

----------
nosy: +ysj.ray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6269>
_______________________________________

From report at bugs.python.org  Tue Oct 26 12:43:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 10:43:54 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1288089834.54.0.216157360492.issue2775@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Shouldn't this be closed? Most of this has been done and we can't do the rest anyway, without breaking backwards compatibility.

----------
nosy: +pitrou
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Tue Oct 26 12:44:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 10:44:57 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1288089897.54.0.6699523057.issue3362@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is it still reproduceable with 2.7, 3.1 or 3.2?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Tue Oct 26 13:50:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Oct 2010 11:50:15 +0000
Subject: [issue10195] Memory allocation fault-injection?
In-Reply-To: <1288052629.43.0.603183515135.issue10195@psf.upfronthosting.co.za>
Message-ID: <1288093815.97.0.183694833086.issue10195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Don't you know http://www.nongnu.org/failmalloc/?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10195>
_______________________________________

From report at bugs.python.org  Tue Oct 26 13:53:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 11:53:14 +0000
Subject: [issue10189] SyntaxError: no binding for nonlocal doesn't contain a
	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1288093994.9.0.41522480052.issue10189@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, but in that particular case the exact line referenced is involved in the error, since it that error is that the symbol is both nonlocal and an argument, and the error points to the head of the block which is the 'def' statement.

Attached is a patch that adds the available line number info to all of the error messages except the one for nonlocal at the global level.  In that case the line number will always be zero, so that does not

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10189>
_______________________________________

From report at bugs.python.org  Tue Oct 26 13:53:24 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 11:53:24 +0000
Subject: [issue10189] SyntaxError: no binding for nonlocal doesn't contain a
	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1288094004.06.0.27220845376.issue10189@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
Removed message: http://bugs.python.org/msg119601

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10189>
_______________________________________

From report at bugs.python.org  Tue Oct 26 13:58:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 11:58:51 +0000
Subject: [issue10195] Memory allocation fault-injection?
In-Reply-To: <1288052629.43.0.603183515135.issue10195@psf.upfronthosting.co.za>
Message-ID: <1288094331.68.0.957152652093.issue10195@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Don't you know http://www.nongnu.org/failmalloc/?

This doesn't answer the question of what and how to test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10195>
_______________________________________

From report at bugs.python.org  Tue Oct 26 14:00:07 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 12:00:07 +0000
Subject: [issue10189] SyntaxError: no binding for nonlocal doesn't contain a
	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1288094407.14.0.650582015449.issue10189@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes, but in that particular case the exact line referenced is involved in the error, since it that error is that the symbol is both nonlocal and an argument, and the error points to the head of the block which is the 'def' statement.

Attached is a patch that adds the available line info, and also modifies the 'nonlocal at global level' message to include the symbol name.

I think this change is a good idea because without the patch this code:

>cat temp
import foo
>cat foo.py
def f():
    def g():
        nonlocal a

gives this:

>./python temp
Traceback (most recent call last):
  File "temp", line 1, in <module>
    import foo
SyntaxError: no binding for nonlocal 'a' found

which is even more confusing that not having any traceback at all.

After the patch it will look like this:

Traceback (most recent call last):
  File "temp", line 1, in <module>
    import foo
  File "/home/rdmurray/python/py3k/foo.py", line 2
    def g():
SyntaxError: no binding for nonlocal 'a' found

----------
keywords: +patch
Added file: http://bugs.python.org/file19368/nonlocal-traceback.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10189>
_______________________________________

From report at bugs.python.org  Tue Oct 26 14:07:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 12:07:59 +0000
Subject: [issue10189] SyntaxError: no binding for nonlocal doesn't contain a
	useful traceback
In-Reply-To: <1287948127.54.0.779100996642.issue10189@psf.upfronthosting.co.za>
Message-ID: <1288094879.13.0.795394543535.issue10189@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Ah, I hadn't noticed Benjamin assigned this to himself when I submitted that patch.  Well, maybe it will be marginally useful anyway :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10189>
_______________________________________

From report at bugs.python.org  Tue Oct 26 14:19:02 2010
From: report at bugs.python.org (jldm)
Date: Tue, 26 Oct 2010 12:19:02 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>


New submission from jldm <j_l_domenech at yahoo.com>:

Hi, first of all sorry for my English.

On windows XP SP3, the following code:

import subprocess
subprocess.getoutput("dir")

returns
    '"{" is not recognized as an internal or external command,\noperable program or batch file.'

I made a workaround by changing in the file Lib/subprocess.py the line 574 (I thin in 3.2a3 is 584) (in the getstatusoutput(cmd) function definition) from:
pipe = os.popen('{ ' + cmd + '; } 2>&1', 'r')

to:
pipe = os.popen('( ' + cmd + '; ) 2>&1', 'r')

I have tested it with:

ActivePython 3.1.2.3 (ActiveState Software Inc.) based on
Python 3.1.2 (r312:79147, Mar 22 2010, 12:20:29) [MSC v.1500 32 bit (Intel)] on win32

and

Python 3.2a3 (r32a3:85355, Oct 10 2010, 17:11:45) [MSC v.1500 32 bit (Intel)] on win32


Regards from Spain.
Jos? Luis Domenech

----------
messages: 119605
nosy: jldm
priority: normal
severity: normal
status: open
title: subprocess.getoutput fails on win32
type: behavior
versions: Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Tue Oct 26 14:48:05 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 12:48:05 +0000
Subject: [issue7761] telnetlib Telnet.interact fails on Windows but not Linux
In-Reply-To: <1264212900.62.0.226780855818.issue7761@psf.upfronthosting.co.za>
Message-ID: <1288097285.97.0.353952935174.issue7761@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Committed to py3k in r85846, 3.1 in r85847.

----------
resolution:  -> fixed
stage: unit test needed -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7761>
_______________________________________

From report at bugs.python.org  Tue Oct 26 15:29:17 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 13:29:17 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1288099757.6.0.0611339323837.issue10197@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Oddly, the test suite skips getoutput and getstatusoutput on windows with the comment that the source says it is relevant only for posix, but the documentation does not have 'availability: unix' tags.  (It is also odd that getoutput isn't documented, but that's a different issue.)

Your workaround can't be used as a fix, since the semantics of {}s in the shell are different from those of ()s.

It's not clear to me what the point of the {}s is, but I have a fear that eliminating them would introduce subtle changes in the behavior of getoutput calls.  Perhaps not, though.

It looks like this issue amounts to an RFE for support of getoutput/getstatusoutput on Windows, though the fact that it is not documented as unix-only may make it a bug instead :)

The appropriate fix is probably to conditionalize the code based on platform.  A complete patch will require unit test changes and documentation changes (since the docs currently mention the braces).

All of that said, it also appears that the new check_output should be preferred to either getoutput or getstatusoutput.  Perhaps those functions could be re-implemented in terms of check_output.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Tue Oct 26 16:06:10 2010
From: report at bugs.python.org (Brian Curtin)
Date: Tue, 26 Oct 2010 14:06:10 +0000
Subject: [issue10197] subprocess.getoutput fails on win32
In-Reply-To: <1288095541.88.0.426506052882.issue10197@psf.upfronthosting.co.za>
Message-ID: <1288101970.11.0.272470327543.issue10197@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
components: +Windows
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10197>
_______________________________________

From report at bugs.python.org  Tue Oct 26 17:27:01 2010
From: report at bugs.python.org (Peter Ingebretson)
Date: Tue, 26 Oct 2010 15:27:01 +0000
Subject: [issue10194] Add gc.remap() function to the gc module.
In-Reply-To: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>
Message-ID: <1288106821.99.0.974959269099.issue10194@psf.upfronthosting.co.za>


Peter Ingebretson <pingebre at yahoo.com> added the comment:

Thanks, I've started a thread on python-dev to discuss the patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10194>
_______________________________________

From report at bugs.python.org  Tue Oct 26 17:35:37 2010
From: report at bugs.python.org (David Barnett)
Date: Tue, 26 Oct 2010 15:35:37 +0000
Subject: [issue10198] wave module writes corrupt wav file for zero-length
	writeframes
In-Reply-To: <1288107337.09.0.986719080657.issue10198@psf.upfronthosting.co.za>
Message-ID: <1288107337.09.0.986719080657.issue10198@psf.upfronthosting.co.za>


New submission from David Barnett <davidbarnett2 at gmail.com>:

If the first call to writeframes happens to take an empty string as the data to write, then the next call to writeframes writes a 2nd header into the file, and forever after fails to patch the data length correctly.

----------
components: Library (Lib)
messages: 119609
nosy: mu_mind
priority: normal
severity: normal
status: open
title: wave module writes corrupt wav file for zero-length writeframes
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10198>
_______________________________________

From report at bugs.python.org  Tue Oct 26 17:38:32 2010
From: report at bugs.python.org (David Barnett)
Date: Tue, 26 Oct 2010 15:38:32 +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: <1288107512.69.0.115547041522.issue10198@psf.upfronthosting.co.za>


David Barnett <davidbarnett2 at gmail.com> added the comment:

This patch against the python 2.6 version fixes the problem for me.

----------
keywords: +patch
Added file: http://bugs.python.org/file19369/fix_double_header.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10198>
_______________________________________

From report at bugs.python.org  Tue Oct 26 17:47:12 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Tue, 26 Oct 2010 15:47:12 +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: <1288108032.78.0.359565137699.issue10196@psf.upfronthosting.co.za>


Bruce Sherwood <bruce.sherwood at gmail.com> added the comment:

Correction: distutils.get_python_lib() returns /usr/lib/python3/dist-packages (which does exist), while distutils.get_python_inc() returns /usr/include/python3.1. I don't understand the shadowy existence of some python3 files that are parallel to python3.1 files. But in any case, get_python_lib() and get_python_inc() are inconsistent with each other.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10196>
_______________________________________

From report at bugs.python.org  Tue Oct 26 17:48:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Oct 2010 15:48:56 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

On Tue, Oct 26, 2010 at 11:18 AM, Guido van Rossum <guido at python.org> wrote:
> On Tue, Oct 26, 2010 at 8:13 AM, Alexander Belopolsky
> <alexander.belopolsky at gmail.com> wrote:
>> The one demo that I want to find a better place for is Demo/turtle.
>
> Sure, go for it. It is a special case because the turtle module is
> also in the stdlib and these are intended for a particular novice
> audience. Anything we can do to make things easier for those people to
> get start with is probably worth it. Ideally they could just double
> click some file and the demo would fire up, with a command-line
> alternative (for the geeks among them) e.g. "python -m turtledemo" .
>
> --
> --Guido van Rossum (python.org/~guido)
>
-- "Move Demo scripts under Lib"
http://mail.python.org/pipermail/python-ideas/2010-October/008397.html

Before I prepare a patch, I would like to get an agreement on the location of the demo package.  In the order of my preference:

1. turtle.demo Pro: obvious relationship to turtle.  Cons: require converting turtle.py to a package.

2. turtledemo  Pro: BDFL's suggestion; "Flat is better than nested".  Cons: relationship to turtle module is less obvious than in #1; stdlib namespace pollution. (Turtle invasion! :-)

3. demo.turtle - probably not a good idea if not as a part of a general Demo reorganization.

Note that while I listed conversion of turtle.py to a package as a cons, it may not be a bad idea on its own.  For example, toolkit abstraction naturally belongs to submodules and procedural interface belongs to package level while OOP classes may be separated into submodules.  While I am not proposing any such changes as a part of this ticket, it may not be a bad idea to take the first step and rename turtle.py to turtle/__init__.py.

----------
assignee: belopolsky
components: Demos and Tools
messages: 119612
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Move Demo/turtle under Lib/
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 18:00:14 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 26 Oct 2010 16:00:14 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288108814.85.0.487929496399.issue10199@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

IMO converting turtle.py into a package, unless that's already planned anyway, is not a good project to undertake right now.  (OTOH the demo itself already is a package, less an __init__.py file.)  Note that the turtle module already runs some demo when invoked as a script -- maybe this can be made to fire up the demo viewer instead?

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 18:21:31 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Oct 2010 16:21:31 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>


New submission from Bo??tjan Mejak <bostjan.mejak at gmail.com>:

There's a bug in the docs at
http://docs.python.org/library/locale.html#access-to-message-catalogs in a
statement before the last. "A known exception to this rule are applications
that >>link use<< additional C libraries which internally invoke gettext()
 or dcgettext(). "

Either use the word "link" or "use" in that statement.

----------
files: unnamed
messages: 119614
nosy: Retro
priority: normal
severity: normal
status: open
title: Documentation: "link use"?
Added file: http://bugs.python.org/file19370/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________
-------------- next part --------------
There&#39;s a bug in the docs at??<a href="http://docs.python.org/library/locale.html#access-to-message-catalogs">http://docs.python.org/library/locale.html#access-to-message-catalogs</a>??in a statement before the last. &quot;<span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 20px; ">A known exception to this rule are applications that &gt;&gt;link use&lt;&lt; additional C libraries which internally invoke??<tt class="xref docutils literal" style="background-color: transparent; padding-top: 0px; padding-right: 1px; padding-bottom: 0px; padding-left: 1px; font-size: 0.95em; font-weight: bold; "><span class="pre">gettext()</span></tt>??or??<tt class="xref docutils literal" style="background-color: transparent; padding-top: 0px; padding-right: 1px; padding-bottom: 0px; padding-left: 1px; font-size: 0.95em; font-weight: bold; "><span class="pre">dcgettext()</span></tt>.??</span>&quot;<div>
<br></div><div>Either use the word &quot;link&quot; or &quot;use&quot; in that statement.</div>

From report at bugs.python.org  Tue Oct 26 18:22:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 16:22:49 +0000
Subject: [issue10201] Fix building of socket module under Solaris
In-Reply-To: <1288110169.62.0.573070204064.issue10201@psf.upfronthosting.co.za>
Message-ID: <1288110169.62.0.573070204064.issue10201@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Sun/Oracle uses the following patch to fix building of the socket module, since on Solaris "netpacket/packet.h" is incompatible with its Linux counterpart. Otherwise, it fails with the following messages:

/home/antoine/py3k/gcc/Modules/socketmodule.c: In function ?makesockaddr?:
/home/antoine/py3k/gcc/Modules/socketmodule.c:1150: error: ?struct ifreq? has no member named ?ifr_ifindex?
/home/antoine/py3k/gcc/Modules/socketmodule.c:1151: error: ?SIOCGIFNAME? undeclared (first use in this function)
/home/antoine/py3k/gcc/Modules/socketmodule.c:1151: error: (Each undeclared identifier is reported only once
/home/antoine/py3k/gcc/Modules/socketmodule.c:1151: error: for each function it appears in.)
/home/antoine/py3k/gcc/Modules/socketmodule.c: In function ?getsockaddrarg?:
/home/antoine/py3k/gcc/Modules/socketmodule.c:1484: error: ?SIOCGIFINDEX? undeclared (first use in this function)
/home/antoine/py3k/gcc/Modules/socketmodule.c:1502: error: ?struct ifreq? has no member named ?ifr_ifindex?
/home/antoine/py3k/gcc/Modules/socketmodule.c: In function ?PyInit__socket?:
/home/antoine/py3k/gcc/Modules/socketmodule.c:4580: error: ?PACKET_LOOPBACK? undeclared (first use in this function)
/home/antoine/py3k/gcc/Modules/socketmodule.c:4581: error: ?PACKET_FASTROUTE? undeclared (first use in this function)



$ cat ~/spec-files/patches/Python26-17-netpacket-packet-h.diff 
--- Python-2.6.2/Modules/socketmodule.c.packet	2009-04-01 07:20:48.000000000 +1300
+++ Python-2.6.2/Modules/socketmodule.c	2009-12-01 21:25:04.133257645 +1300
@@ -81,6 +81,14 @@
 
 */
 
+#ifdef HAVE_NETPACKET_PACKET_H
+#ifdef sun
+#define USE_NETPACKET_PACKET_H 0
+#else
+#define USE_NETPACKET_PACKET_H 1
+#endif
+#endif
+
 #ifdef __APPLE__
   /*
    * inet_aton is not available on OSX 10.3, yet we want to use a binary
@@ -1092,7 +1100,7 @@
 		}
 #endif
 
-#ifdef HAVE_NETPACKET_PACKET_H
+#if USE_NETPACKET_PACKET_H
 	case AF_PACKET:
 	{
 		struct sockaddr_ll *a = (struct sockaddr_ll *)addr;
@@ -1382,7 +1390,7 @@
 	}
 #endif
 
-#ifdef HAVE_NETPACKET_PACKET_H
+#if USE_NETPACKET_PACKET_H
 	case AF_PACKET:
 	{
 		struct sockaddr_ll* addr;
@@ -1559,7 +1567,7 @@
 	}
 #endif
 
-#ifdef HAVE_NETPACKET_PACKET_H
+#if USE_NETPACKET_PACKET_H
 	case AF_PACKET:
 	{
 		*len_ret = sizeof (struct sockaddr_ll);
@@ -4575,7 +4583,7 @@
 	PyModule_AddStringConstant(m, "BDADDR_LOCAL", "00:00:00:FF:FF:FF");
 #endif
 
-#ifdef HAVE_NETPACKET_PACKET_H
+#if USE_NETPACKET_PACKET_H
 	PyModule_AddIntConstant(m, "AF_PACKET", AF_PACKET);
 	PyModule_AddIntConstant(m, "PF_PACKET", PF_PACKET);
 	PyModule_AddIntConstant(m, "PACKET_HOST", PACKET_HOST);

----------
components: Build
messages: 119615
nosy: jcea, loewis, movement, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: Fix building of socket module under Solaris
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10201>
_______________________________________

From report at bugs.python.org  Tue Oct 26 18:25:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Oct 2010 16:25:59 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108814.85.0.487929496399.issue10199@psf.upfronthosting.co.za>
Message-ID: <AANLkTik=yZta+Kz_PDJpFco4K8fL1HLDPhRBg=retH8C@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Oct 26, 2010 at 12:00 PM, Guido van Rossum
<report at bugs.python.org> wrote:
..
> IMO converting turtle.py into a package, unless that's already planned anyway, is not a good project
> to undertake right now.

What are your reasons? I don't necessarily disagree, but want to
weight pros and cons.  It does not seem like a hard thing to do:
rename turtle.py to turtle/__init__.py and add __main__.py.   As I
said, I don't intend to anything more than that in the first step.

> ?(OTOH the demo itself already is a package, less an __init__.py file.)

Unfortunately it also relies on being run from directory containing
the main script, so converting it into a proper package is a bit more
involved than renaming the directory and adding an empty __init__.py
file.  Still it is not that hard.

> ?Note that the turtle module already runs some demo when invoked as a script
> -- maybe this can be made to fire up the demo viewer instead?

Yes, I wanted to do that as well.  Note that in this case, it would be
natural to move turtleDemo.py code into turtle/__main__.py.   I would
also like to be able to run individual tdemo_* scripts without the
demo viewer or with an alternative viewer.  Some naming decisions have
to be made for that as well:

$ python -m turtle.tdemo_chaos
$ python -m turtle.demo.chaos
$ python -m turtledemo.tdemo_chaos
...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 18:31:32 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 26 Oct 2010 16:31:32 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288110692.31.0.0560369831336.issue10199@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I would like Gregor Lingl's approval of turning turtle.py into a package.  It might make some things harder for novices, e.g. trackebacks and just browsing the source code.

Also many people don't expect to find any code in a file named __init__.py (and most of the time I agree with this).  But the alternative isn't so great either, assuming we'll want strict backwards compatibility (I wouldn't want the instructions in Gregor's or anyone's book to start failing because of this).  You can't rename turtle to turtle/turtle.py either, because then there'd be horrible confusion between turtle/ and turtle.py.

IOW, yes, flat still seems better than nested here!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 18:31:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Oct 2010 16:31:58 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288110718.86.0.050619824565.issue10199@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/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 18:32:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Oct 2010 16:32:25 +0000
Subject: [issue10193] Simplify instrospection used by turtle module
In-Reply-To: <1288032526.99.0.352179918003.issue10193@psf.upfronthosting.co.za>
Message-ID: <1288110745.88.0.0288161902663.issue10193@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> belopolsky
resolution:  -> accepted
stage:  -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10193>
_______________________________________

From report at bugs.python.org  Tue Oct 26 18:38:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Oct 2010 16:38:32 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288111112.43.0.88436077025.issue10199@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +glingl, gregorlingl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 18:46:58 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 16:46:58 +0000
Subject: [issue10201] Fix building of socket module under Solaris
In-Reply-To: <1288110169.62.0.573070204064.issue10201@psf.upfronthosting.co.za>
Message-ID: <1288111618.59.0.45904346243.issue10201@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is a working patch for py3k. Tested under OpenSolaris with both gcc and Sun C.

----------
keywords: +patch
nosy: +laca
Added file: http://bugs.python.org/file19371/buildsocket.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10201>
_______________________________________

From report at bugs.python.org  Tue Oct 26 19:05:54 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Oct 2010 17:05:54 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288110692.31.0.0560369831336.issue10199@psf.upfronthosting.co.za>
Message-ID: <AANLkTinqKt1DkZ-c0ZVYAZDxmwYaJ+L4pvw852R0X_y=@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Oct 26, 2010 at 12:31 PM, Guido van Rossum
<report at bugs.python.org> wrote:
..
> I would like Gregor Lingl's approval of turning turtle.py into a package.

Me too. :-)  I added him to the "nosy list".

> ?It might make some things harder for novices, e.g. trackebacks and just browsing the source code.

If better tracebacks were the goal, I would start with removing
eval-generated module level functions:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 1, in forward
..
TypeError: can't multiply sequence by non-int of type 'float'

Browsing source code may indeed be complicated by the package
structure.  For example, I often find it difficult to navigate
unittest code once it became a package in the recent versions.
However, simple renaming of turtle.py to turtle/__init__.py is
probably a non-event since novice-oriented environments such as IDEs
are likely to take the user directly to turtle/__init__.py when he or
she clicks on "turtle".

> Also many people don't expect to find any code in a file named __init__.py (and most of the time I
> agree with this).

Well, logging, tkinter, and ctypes are clearly counterexamples to this rule.

> ?But the alternative isn't so great either, assuming we'll want strict backwards compatibility (I
> wouldn't want the instructions in Gregor's or anyone's book to start failing because of this).

Backwards compatibility can be restored by use of relative imports as
necessary.  This is the unittest approach where backward compatibility
is paramount.

> You can't rename turtle to turtle/turtle.py either, because then there'd be horrible confusion
> between turtle/ and turtle.py.

Agree.  We have too many turtles already. :-)  On the other hand,
moving turtle object definitions into turtle/pen.py in some distant
future may not be a horrible idea.  (Note that "pen" end "turtle" are
already mostly synonymous.)

> IOW, yes, flat still seems better than nested here!

For a six year old, turtledemo is still nested - just without a dot. :-)

PS: My six year old loves the turtle!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 19:12:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Oct 2010 17:12:41 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288113161.14.0.708708590581.issue10199@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I thought this email-to-roundup bug was fixed some time ago.  The mangled sample session was:

>>> turtle.forward('5 miles')
Traceback (most recent call last):
 File "<stdin>", line 1, in <module>
 File "<string>", line 1, in forward
..
TypeError: can't multiply sequence by non-int of type 'float'

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 19:29:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 17:29:13 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288114153.06.0.281556269601.issue4111@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

For the record, replacing /dev/null with conftest.out in the configure test solves the detection problem (and allows Python to build cleanly). However, there is then a problem in test_systemtap (even when replacing "stap" with "dtrace") since the syntax for scripts doesn't seem compatible.

In any case, the trivial fix for configure:

diff -r 777b171a63ae -r 1784ac25b52e configure
--- a/configure Tue Oct 26 18:50:46 2010 +0200
+++ b/configure Tue Oct 26 18:54:09 2010 +0200
@@ -9178,7 +9178,7 @@
 $as_echo "$with_dtrace" >&6; }
 if test ! -z "$with_dtrace"
 then
-    if dtrace -G -o /dev/null -s $srcdir/Include/pydtrace.d 2>/dev/null
+    if dtrace -G -o conftest.out -s $srcdir/Include/pydtrace.d 2>/dev/null
     then
 
 $as_echo "#define WITH_DTRACE 1" >>confdefs.h
diff -r 777b171a63ae -r 1784ac25b52e configure.in
--- a/configure.in      Tue Oct 26 18:50:46 2010 +0200
+++ b/configure.in      Tue Oct 26 18:54:09 2010 +0200
@@ -2466,7 +2466,7 @@
 AC_MSG_RESULT([$with_dtrace])
 if test ! -z "$with_dtrace"
 then
-    if dtrace -G -o /dev/null -s $srcdir/Include/pydtrace.d 2>/dev/null
+    if dtrace -G -o conftest.out -s $srcdir/Include/pydtrace.d 2>/dev/null
     then
        AC_DEFINE(WITH_DTRACE, 1, 
         [Define if you want to compile in Dtrace support])

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Oct 26 19:29:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 17:29:56 +0000
Subject: [issue4111] Add Systemtap/DTrace probes
In-Reply-To: <1223827695.04.0.0893695004368.issue4111@psf.upfronthosting.co.za>
Message-ID: <1288114196.36.0.02522781043.issue4111@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

(my last message was about building on OpenSolaris)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4111>
_______________________________________

From report at bugs.python.org  Tue Oct 26 19:31:49 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Oct 2010 17:31:49 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288114309.92.0.831668257833.issue10199@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Just an FYI: the python.org installers for Mac OS X install the demos including the turtle demo (which is probably the most useful of the bunch these days) in /Applications/Python m.n/Extras/Demo.  Depending on the default application association for ".py" files (something the user can change using the OS X Finder), double-clicking on the demo files will generally launch them in IDLE.app or with Python Launcher.app.

----------
nosy: +ned.deily

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 19:48:42 2010
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Oct 2010 17:48:42 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1288115322.34.0.554856846755.issue2775@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

profile and cProfile could still conceivably be merged, even if it is under a new name if someone found the time to do the compatibility work.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Tue Oct 26 19:50:52 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Tue, 26 Oct 2010 17:50:52 +0000
Subject: [issue10195] Memory allocation fault-injection?
In-Reply-To: <1288052629.43.0.603183515135.issue10195@psf.upfronthosting.co.za>
Message-ID: <1288115452.7.0.29693282788.issue10195@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

Attached is a new approach to doing this, based on "Out-Of-Memory Testing" within http://sqlite.org/testing.html

This reads environment variables, and injects a fault at the given value of "serialno", and (optionally) ongoing failures afterwards.

I used this to find a specific bug in Python/pythonrun.c (fix is the first hunk of the patch): if moduleName is NULL, then Py_DECREF will read through NULL.

Potentially this gives the low-level machinery to support adding SQLite's approach to be added to regrtest.  Doing so would imply running each test many tens of thousands of times, so perhaps we could run "-c pass" to establish at what serialno the interpreter has fully started up, then use that as a starting point when testing other scripts/modules.

I implemented a toy version of this as Lib/test/test_malloc_fault.py, which sits in an infinite loop injecting individual allocation failures when starting up sys.executable as a subprocess.

For low numbers, this throws up segfaults within _Py_ReadyTypes' call to PyType_Ready(&PyType_Type), where PyExc_MemoryError is set but has not yet been initialized (its ob_type is NULL):
        /* this will probably fail since there's no memory and hee,
           hee, we have to instantiate this class
        */

Running this interactively with a large value for PYTHONMALLOCINJECTFAULTSAT leads to an interesting failure mode within PyRun_InteractiveLoopFlags(): every call to PyRun_InteractiveOneFlags immediately returns (the PyUnicode_FromString("stdin") in within PySys_GetObject() fails to allocate memory); this leads to a tight loop sending the total refcount to stderr:
[52812 refs]
[52812 refs]
[52812 refs]
(etc)

----------
Added file: http://bugs.python.org/file19372/py3k-inject-malloc-failure-002.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10195>
_______________________________________

From report at bugs.python.org  Tue Oct 26 19:58:46 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Oct 2010 17:58:46 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <1288115926.82.0.731263120655.issue10200@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file19370/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________

From report at bugs.python.org  Tue Oct 26 19:59:20 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Oct 2010 17:59:20 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <1288115960.54.0.618358649062.issue10200@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


----------
assignee:  -> docs at python
components: +Documentation
nosy: +docs at python
versions: +3rd party, Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________

From report at bugs.python.org  Tue Oct 26 20:12:41 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Oct 2010 18:12:41 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <1288116761.07.0.737233123128.issue10200@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

...Also, please fix a typo here: http://docs.python.org/library/string.html#string.Formatter.parse

"This is used by vformat() to break the string >>in to<< either literal text, or replacement fields."

Please fix "in to" to "into".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________

From report at bugs.python.org  Tue Oct 26 20:16:59 2010
From: report at bugs.python.org (Ned Deily)
Date: Tue, 26 Oct 2010 18:16:59 +0000
Subject: [issue3362] locale.getpreferredencoding() gives bus error on Mac OS X
	10.4.11 PPC
In-Reply-To: <1216131750.8.0.934284197866.issue3362@psf.upfronthosting.co.za>
Message-ID: <1288117019.79.0.245627728668.issue3362@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

This was fixed by the changes for Issue6202: 2.7 (r73270) and 3.1 (r73268).  They removed the use of the obsolete MacOS encoding APIs and now use standard POSIX detection.

----------
nosy: +ned.deily
resolution:  -> duplicate
status: open -> closed
superseder:  -> Obsolete default file encoding "mac-roman" on OS X, not influenced by locale env variables

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue3362>
_______________________________________

From report at bugs.python.org  Tue Oct 26 20:17:08 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 26 Oct 2010 18:17:08 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288117028.77.0.612635498933.issue10199@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Various comments:

I usually expect things in stdlib to be usefully importable. Idlelib is clearly an exception.

>> Also many people don't expect to find any code in a file named
>> __init__.py (and most of the time I agree with this).

> Well, logging, tkinter, and ctypes are clearly counterexamples
> to this rule.

I think it a mistake that tkinter.__init__ is huge, about as big as the other 13 modules added together. It makes it really hard to dive into the code.

I think turtledemo would be fine, separate from turtle, if one could import and run things (one at a time) from within the interactive interpreter.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 20:18:52 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Oct 2010 18:18:52 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288117132.35.0.473899563652.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch, issue7061.diff, drops "for Tk" from turtle module title and move its doc section under frameworks.  I also fixed a couple of markup issues that affected TOC rendering.

----------
keywords: +patch
stage:  -> commit review
Added file: http://bugs.python.org/file19373/issue7061.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Oct 26 20:25:22 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Oct 2010 18:25:22 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <1288117522.99.0.73885238479.issue10200@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

There's also a possible typo here: http://docs.python.org/library/string.html#format-specification-mini-language

format_spec ::=  >>>[<<<[fill>>>]<<<align][sign][#][0][width][,][.precision][type]

Don't you mean  [fill>>>|<<<align][sign][#][0][width][,][.precision][type]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________

From report at bugs.python.org  Tue Oct 26 20:25:47 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Oct 2010 18:25:47 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <1288117547.85.0.409242359878.issue10200@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Please fix all of those things. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________

From report at bugs.python.org  Tue Oct 26 20:28:40 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Oct 2010 18:28:40 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288117720.17.0.767820923646.issue7061@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Looks good.  Remember to adjust the number of signs making the reST title markup.

Nice that you?re fixing the ToC; I noticed a handful of issues some days ago and thought about making a patch in a week or two.  I?d open another report for them and backport the fixes to 2.7 too.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From raymond.hettinger at gmail.com  Tue Oct 26 19:48:01 2010
From: raymond.hettinger at gmail.com (Raymond Hettinger)
Date: Tue, 26 Oct 2010 10:48:01 -0700
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <AANLkTinqKt1DkZ-c0ZVYAZDxmwYaJ+L4pvw852R0X_y=@mail.gmail.com>
References: <AANLkTinqKt1DkZ-c0ZVYAZDxmwYaJ+L4pvw852R0X_y=@mail.gmail.com>
Message-ID: <F9E0F42C-D934-4403-8366-D1A48DB5D9D0@gmail.com>


On Oct 26, 2010, at 10:05 AM, Alexander Belopolsky wrote:

> 
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> On Tue, Oct 26, 2010 at 12:31 PM, Guido van Rossum
>> Also many people don't expect to find any code in a file named __init__.py (and most of the time I
>> agree with this).
> 
> Well, logging, tkinter, and ctypes are clearly counterexamples to this rule.

Those are not in the same league. 

Guido's point is that there are some disadvantages to making
a package (i.e. the __init__.py files are an acquired taste), so
we typically only do it when there are significant offsetting advantages.
Just because a successful case for packaging was made for tkinter, 
doesn't mean that it is the right thing to do for the turtle module.
As a general rule, *most* of the time a package is not the preferred
solution.


Raymond


From report at bugs.python.org  Tue Oct 26 20:35:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Tue, 26 Oct 2010 18:35:49 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <1288118149.34.0.520002114721.issue10200@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hi Bo?tjan, thanks for the reports and suggestions.

A tip about versions.  This field is used to mark the versions in which the bug will be fixed, not all versions where the bug is found.  2.5 and 2.6 only get security fixes; 2.7 and 3.1, the current stable versions, also get bug (including doc) fixes; 3.2, the next stable version, also gets new features; 3.3 is used to mean ?won?t happen in 3.2, remind us later?; 3rd party means, well, third-party, for example distutils2 which is managed outside of the standard library and thus does not affect the status of Python releases.

Finally, you can send email to docs at python.org for such small typos instead of opening bug reports, as you please.

(Another tip: ?please fix? messages don?t really add to the discussion and don?t make the developers have more time.  Don?t worry, someone will get to your reports in time.)

----------
keywords: +patch
nosy: +eric.araujo
versions:  -3rd party, Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________

From report at bugs.python.org  Tue Oct 26 20:42:46 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Oct 2010 18:42:46 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <1288118566.6.0.28087203317.issue10200@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I am terribly sorry for the red alarm. I didn't mean to. But since the typos are all listed here, I don't want to copy&paste the reports to docs at python.org. Just please fix them. Thanks.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________

From report at bugs.python.org  Tue Oct 26 20:46:25 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 18:46:25 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288118785.71.0.107855272409.issue10199@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yeah, I wish unittest hadn't been split up, and I really dislike the organization of the email package, though I think I understand how it came about historically.  So I vote for flat :)

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 20:49:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 18:49:56 +0000
Subject: [issue10195] Memory allocation fault-injection?
In-Reply-To: <1288115452.7.0.29693282788.issue10195@psf.upfronthosting.co.za>
Message-ID: <1288118991.3547.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Doing so would imply running each test many tens of thousands of
> times, so perhaps we could run "-c pass" to establish at what serialno
> the interpreter has fully started up, then use that as a starting
> point when testing other scripts/modules.

Well, this seems to suggest it's not an optimal approach. IMHO, your
sys._inject_malloc_failure() proposal sounded better.

(I don't think running "-c pass" is an appropriate solution; it's not
obvious that the number of memory allocations at startup is totally
deterministic - it could depend on e.g. I/O conditions -, and I don't
think we want to ensure it is)

> Running this interactively with a large value for
> PYTHONMALLOCINJECTFAULTSAT

I don't think an env variable is useful for this, since you probably
don't want to set it permanently or even semi-permanently (and
"PYTHONLONGUNAMBIGUOUSVARIABLENAME"s are always painful :-)). The new -X
option support could be used instead, if a sys function isn't enough.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10195>
_______________________________________

From report at bugs.python.org  Tue Oct 26 20:50:58 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Oct 2010 18:50:58 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288119058.38.0.859072462269.issue10199@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> I think it a mistake that tkinter.__init__ is huge,
> about as big as the other 13 modules added together. 
> It makes it really hard to dive into the code

That is certainly *not* a best practice.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 21:04:50 2010
From: report at bugs.python.org (John Nagle)
Date: Tue, 26 Oct 2010 19:04:50 +0000
Subject: [issue10202] ftplib doesn't check close status after sending file
In-Reply-To: <1288119890.05.0.476969255522.issue10202@psf.upfronthosting.co.za>
Message-ID: <1288119890.05.0.476969255522.issue10202@psf.upfronthosting.co.za>


New submission from John Nagle <nagle at users.sourceforge.net>:

"ftplib" doesn't check the status on socket close after writing.  This can lead to silently truncated files when sending files with "ftplib".

A report of truncated files on comp.lang.python led me to check the source code. 

The "ftplib" module does sending by calling sock_sendall in "socketmodule.c". That does an OS-level "send", and once everything has been sent, returns.

But an OS-level socket send returns when the data is queued for sending, not when it is delivered.  Only when the socket is closed, and the close status checked, do you know if the data was delivered. There's a final TCP close handshake that occurs when close has been called at both ends, and only when it completes successfully do you know that the data has been delivered.

At the socket level, this is performed by "shutdown" (which closes the connection and returns the proper network status information), or by "close".

Look at sock_close in "socketmodule.c".  Note that it ignores the return status on close, always returns None, and never raises an exception.  As the Linux manual page for "close" says:
"Not checking the return value of close() is a common but nevertheless serious programming error. It is quite possible that errors on a previous write(2) operation are first reported at the final close(). Not checking the return value when closing the file may lead to silent loss of data."

"ftplib", in "storlines" and "storbinary", calls "close" without checking the status or calling "shutdown" first.  So if the other end disconnects after all data has been queued locally but not sent, received and acknowledged, the sender will never know.

----------
components: Library (Lib)
messages: 119638
nosy: nagle
priority: normal
severity: normal
status: open
title: ftplib doesn't check close status after sending file
type: behavior
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10202>
_______________________________________

From report at bugs.python.org  Tue Oct 26 21:11:34 2010
From: report at bugs.python.org (Paul Sokolovsky)
Date: Tue, 26 Oct 2010 19:11:34 +0000
Subject: [issue10203] sqlite3.Row doesn't support sequence protocol
In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>
Message-ID: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>


New submission from Paul Sokolovsky <pfalcon at users.sourceforge.net>:

sqlite.Row class doesn't implement sequence protocol, which is rather unfortunate, because it is described and expected to work like a tuple, with extra mapping-like functionality.

Specific issue I hit:

Adding rows to PyGTK ListStore,

        model = gtk.ListStore(*db.getSchema())
        for r in listGen():
            model.append(r)

I get:

TypeError: expecting a sequence

Looking at PyGTK sources, append() method uses PySequence Check() on the argument. Looking at Python 2.6.5 abstract.c:

int
PySequence_Check(PyObject *s)
{
        if (s && PyInstance_Check(s))
                return PyObject_HasAttrString(s, "__getitem__");
        if (PyObject_IsInstance(s, (PyObject *)&PyDict_Type))
                return 0;
        return s != NULL && s->ob_type->tp_as_sequence &&
                s->ob_type->tp_as_sequence->sq_item != NULL;
}

And sqlite3.Row doesn't set ob_type->tp_as_sequence as of Py 2.6.5 or 2.7.

----------
components: Library (Lib)
messages: 119639
nosy: pfalcon
priority: normal
severity: normal
status: open
title: sqlite3.Row doesn't support sequence protocol
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10203>
_______________________________________

From report at bugs.python.org  Tue Oct 26 21:16:05 2010
From: report at bugs.python.org (Paul Sokolovsky)
Date: Tue, 26 Oct 2010 19:16:05 +0000
Subject: [issue10203] sqlite3.Row doesn't support sequence protocol
In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>
Message-ID: <1288120565.4.0.00893646023715.issue10203@psf.upfronthosting.co.za>


Changes by Paul Sokolovsky <pfalcon at users.sourceforge.net>:


----------
versions: +Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10203>
_______________________________________

From report at bugs.python.org  Tue Oct 26 21:21:19 2010
From: report at bugs.python.org (Eric Promislow)
Date: Tue, 26 Oct 2010 19:21:19 +0000
Subject: [issue10204] exec string fails with trailing whitespace
In-Reply-To: <1288120878.97.0.786929493479.issue10204@psf.upfronthosting.co.za>
Message-ID: <1288120878.97.0.786929493479.issue10204@psf.upfronthosting.co.za>


New submission from Eric Promislow <ericp at activestate.com>:

The following code throws an exception in Python 3.1 (and 3.2 alpha),
but runs with 2.x:

>>> exec('if True:\n    print("Hello")\n    \n    ')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 4

SyntaxError: invalid syntax
>>>

This is with Python 3.1.1.2, but I can repro it with a 3.2 alpha
as well.

Ref Komodo bug http://bugs.activestate.com/show_bug.cgi?id=88566

----------
components: Interpreter Core
messages: 119640
nosy: ericp
priority: normal
severity: normal
status: open
title: exec string fails with trailing whitespace
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10204>
_______________________________________

From report at bugs.python.org  Tue Oct 26 21:27:21 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Oct 2010 19:27:21 +0000
Subject: [issue2775] Implement PEP 3108
In-Reply-To: <1210097469.77.0.880435072777.issue2775@psf.upfronthosting.co.za>
Message-ID: <1288121241.77.0.526978697408.issue2775@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I will have a go at the profiler situation.

I imagine the following: deprecate the cProfile module, and provide both profiler classes from the profile module -- e.g. as PythonProfile and CProfile, and provide Profile = PythonProfile.  (From cProfile.py, obviously Profile = CProfile).  A lot of the interface (module-level helpers and script entry) are near duplicated anyway.

In 3.3, the default Profile could then be reassigned to CProfile.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2775>
_______________________________________

From report at bugs.python.org  Tue Oct 26 21:29:43 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Oct 2010 19:29:43 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <1288121383.09.0.0220596856805.issue10200@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________

From report at bugs.python.org  Tue Oct 26 21:32:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Oct 2010 19:32:48 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288121568.1.0.392879967985.issue7061@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

LGTM, if you verified that the label "debugger" is not in use at the moment.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Tue Oct 26 21:40:49 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89tienne_BERSAC?=)
Date: Tue, 26 Oct 2010 19:40:49 +0000
Subject: [issue10205] Can't have two tags with the same QName
In-Reply-To: <1288122049.66.0.916624044666.issue10205@psf.upfronthosting.co.za>
Message-ID: <1288122049.66.0.916624044666.issue10205@psf.upfronthosting.co.za>


New submission from ?tienne BERSAC <bersace03 at gmail.com>:

Hi,

Here is the code to reproduce and the unexcpected behaviour?:

21:37:41 bersace at st-francois-de-sales:~/Bureau/$ cat bug.py 
from xml.etree.ElementTree import QName, ElementTree, Element, SubElement
import sys

head = Element(QName('http://www.w3.org/1999/xhtml', 'html'))
SubElement(head, QName('http://www.w3.org/1999/xhtml', 'meta'))
SubElement(head, QName('http://www.w3.org/1999/xhtml', 'meta'))

tree = ElementTree(head)
tree.write(sys.stdout, encoding="utf-8", xml_declaration=True,
           default_namespace='http://www.w3.org/1999/xhtml')
21:38:00 bersace at st-francois-de-sales:~/Bureau/$ python2.7 bug.py 
<?xml version='1.0' encoding='utf-8'?>
Traceback (most recent call last):
  File "bug.py", line 10, in <module>
    default_namespace='http://www.w3.org/1999/xhtml')
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 812, in write
    self._root, encoding, default_namespace
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 880, in _namespaces
    _raise_serialization_error(tag)
  File "/usr/lib/python2.7/xml/etree/ElementTree.py", line 1046, in _raise_serialization_error
    "cannot serialize %r (type %s)" % (text, type(text).__name__)
TypeError: cannot serialize <xml.etree.ElementTree.QName object at 0xb76aa60c> (type QName)
21:38:01 bersace at st-francois-de-sales:~/Bureau/$ 

Patch is attached.

Regards,
?tienne

----------
components: XML
files: python2.7-fix-qname-already-registered.patch
keywords: patch
messages: 119643
nosy: bersace
priority: normal
severity: normal
status: open
title: Can't have two tags with the same QName
versions: Python 2.7
Added file: http://bugs.python.org/file19374/python2.7-fix-qname-already-registered.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10205>
_______________________________________

From report at bugs.python.org  Tue Oct 26 21:49:37 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 19:49:37 +0000
Subject: [issue10204] exec string fails with trailing whitespace
In-Reply-To: <1288120878.97.0.786929493479.issue10204@psf.upfronthosting.co.za>
Message-ID: <1288122577.01.0.635197488952.issue10204@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I can reproduce this on 3.1 but not py3k trunk.

----------
nosy: +benjamin.peterson, r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10204>
_______________________________________

From report at bugs.python.org  Tue Oct 26 21:58:28 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Oct 2010 19:58:28 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <1288123108.59.0.85071744005.issue10200@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r85849, r85850, and the third one isn't a typo.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________

From report at bugs.python.org  Tue Oct 26 22:01:28 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 20:01:28 +0000
Subject: [issue10206] python program starting with unmatched quote spews
	spaces to stdout
In-Reply-To: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>
Message-ID: <1288123288.86.0.422520379457.issue10206@psf.upfronthosting.co.za>


New submission from R. David Murray <rdmurray at bitdance.com>:

To reproduce:

  python -c "'"

(Hint: don't do this on a slow terminal)

----------
messages: 119646
nosy: r.david.murray
priority: critical
severity: normal
stage: needs patch
status: open
title: python program starting with unmatched quote spews spaces to stdout
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Tue Oct 26 22:09:00 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Oct 2010 20:09:00 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288123740.65.0.53612457965.issue10199@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/issue10199>
_______________________________________

From report at bugs.python.org  Tue Oct 26 22:33:39 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Oct 2010 20:33:39 +0000
Subject: [issue10204] exec string fails with trailing whitespace
In-Reply-To: <1288120878.97.0.786929493479.issue10204@psf.upfronthosting.co.za>
Message-ID: <1288125219.22.0.980185302116.issue10204@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

That's because it's fixed.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10204>
_______________________________________

From report at bugs.python.org  Tue Oct 26 22:35:53 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Tue, 26 Oct 2010 20:35:53 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <1288123108.59.0.85071744005.issue10200@psf.upfronthosting.co.za>
Message-ID: <AANLkTikpx56dSy_hwAh77YQ_V5EEVb0BC-54+Qt4zehj@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I forgot to mention to remove the comma in the text "This is used by
vformat()<http://docs.python.org/library/string.html#string.Formatter.vformat>
to
break the string into either literal text, or replacement fields." found at
http://docs.python.org/library/string.html#string.Formatter.parse. to be "This
is used by vformat()<http://docs.python.org/library/string.html#string.Formatter.vformat>
to
break the string into either literal text or replacement fields." Please
revisit this and remove the comma.

On Tue, Oct 26, 2010 at 9:58 PM, Georg Brandl <report at bugs.python.org>wrote:

>
> Georg Brandl <georg at python.org> added the comment:
>
> Fixed in r85849, r85850, and the third one isn't a typo.
>
> ----------
> nosy: +georg.brandl
> resolution:  -> fixed
> status: open -> closed
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue10200>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19375/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________
-------------- next part --------------
I forgot to mention to remove the comma in the text &quot;<span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 20px; ">This is used by??<a title="string.Formatter.vformat" class="reference internal" href="http://docs.python.org/library/string.html#string.Formatter.vformat" style="color: rgb(53, 95, 124); text-decoration: none; "><tt class="xref docutils literal" style="background-color: transparent; padding-top: 0px; padding-right: 1px; padding-bottom: 0px; padding-left: 1px; font-size: 0.95em; font-weight: bold; "><span class="pre">vformat()</span></tt></a>??to break the string into either literal text, or replacement fields.</span>&quot; found at??<a href="http://docs.python.org/library/string.html#string.Formatter.parse">http://docs.python.org/library/string.html#string.Formatter.parse</a>. to be &quot;<span class="Apple-style-span" style="font-family: sans-serif; font-size: 16px; line-height: 20px; ">This is used by??<a title="string.Formatter.vformat" class="reference internal" href="http://docs.python.org/library/string.html#string.Formatter.vformat" style="color: rgb(53, 95, 124); text-decoration: none; "><tt class="xref docutils literal" style="background-color: transparent; padding-top: 0px; padding-right: 1px; padding-bottom: 0px; padding-left: 1px; font-size: 0.95em; font-weight: bold; "><span class="pre">vformat()</span></tt></a>??to break the string into either literal text or replacement fields.</span>&quot; Please revisit this and remove the comma.<div>
<br><br><div class="gmail_quote">On Tue, Oct 26, 2010 at 9:58 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:0 0 0 .8ex;border-left:1px #ccc solid;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>
Fixed in r85849, r85850, and the third one isn&#39;t a typo.<br>
<br>
----------<br>
nosy: +georg.brandl<br>
resolution: ??-&gt; fixed<br>
status: open -&gt; closed<br>
<div><div></div><div class="h5"><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue10200" target="_blank">http://bugs.python.org/issue10200</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Tue Oct 26 22:36:04 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 20:36:04 +0000
Subject: [issue10202] ftplib doesn't check close status after sending file
In-Reply-To: <1288119890.05.0.476969255522.issue10202@psf.upfronthosting.co.za>
Message-ID: <1288125364.29.0.734765432924.issue10202@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +giampaolo.rodola
stage:  -> unit test needed
versions:  -Python 2.5, Python 2.6, Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10202>
_______________________________________

From report at bugs.python.org  Tue Oct 26 23:01:54 2010
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Oct 2010 21:01:54 +0000
Subject: [issue10200] Documentation: "link use"?
In-Reply-To: <AANLkTim9cza8NQYbMkwELXgTvaikj_dZWX4zk-s5EgkW@mail.gmail.com>
Message-ID: <1288126914.08.0.80009218368.issue10200@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't think that comma is an error; it's more a stylistic issue.  You could write it with and without, and both are correct.  (Remember that TOOWTDI does absolutely not apply to natural languages.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10200>
_______________________________________

From report at bugs.python.org  Tue Oct 26 23:04:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Tue, 26 Oct 2010 21:04:35 +0000
Subject: [issue10204] exec string fails with trailing whitespace
In-Reply-To: <1288120878.97.0.786929493479.issue10204@psf.upfronthosting.co.za>
Message-ID: <1288127075.76.0.145209708474.issue10204@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

The fix is not something that can be backported to 3.1?  (This is a regression relative to 2.x).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10204>
_______________________________________

From report at bugs.python.org  Tue Oct 26 23:07:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Tue, 26 Oct 2010 21:07:53 +0000
Subject: [issue10195] Memory allocation fault-injection?
In-Reply-To: <1288052629.43.0.603183515135.issue10195@psf.upfronthosting.co.za>
Message-ID: <1288127273.22.0.725704630329.issue10195@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> ... every call to PyRun_InteractiveOneFlags immediately returns 
>(the PyUnicode_FromString("stdin") in within PySys_GetObject() fails 
> to allocate memory); this leads to a tight loop sending the total
> refcount to stderr:

I think that it is the issue #8070.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10195>
_______________________________________

From report at bugs.python.org  Tue Oct 26 23:59:16 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 21:59:16 +0000
Subject: [issue10202] ftplib doesn't check close status after sending file
In-Reply-To: <1288119890.05.0.476969255522.issue10202@psf.upfronthosting.co.za>
Message-ID: <1288130356.59.0.93271863019.issue10202@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It sounds more like an issue in socket.close(), right?

----------
nosy: +exarkun, loewis, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10202>
_______________________________________

From report at bugs.python.org  Tue Oct 26 23:59:44 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Oct 2010 21:59:44 +0000
Subject: [issue10204] exec string fails with trailing whitespace
In-Reply-To: <1288127075.76.0.145209708474.issue10204@psf.upfronthosting.co.za>
Message-ID: <AANLkTinOdKQ1XdNN-T=U_mprtzjQ5FpZ0TE8L1uz9PD+@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/10/26 R. David Murray <report at bugs.python.org>:
>
> R. David Murray <rdmurray at bitdance.com> added the comment:
>
> The fix is not something that can be backported to 3.1? ?(This is a regression relative to 2.x).

No, it's not. The fix was a bit of "feature", so it was in 2.7 and py3k.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10204>
_______________________________________

From report at bugs.python.org  Wed Oct 27 00:06:42 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 26 Oct 2010 22:06:42 +0000
Subject: [issue9047] Python 2.7rc2 includes -isysroot twice on each gcc
	command line
In-Reply-To: <1287586765.29.0.693620018902.issue9047@psf.upfronthosting.co.za>
Message-ID: <4CC750EE.2080303@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Ronald Oussoren wrote:
> 
> Ronald Oussoren <ronaldoussoren at mac.com> added the comment:
> 
> Marc-Andre: does the current HEAD of the 2.7 and 3.2 branches work for you?
> 
> The build still has duplicate flags, but that doesn't seem to cause problems on my machines. If it also doesn't cause problems on your machines I'd prefer to close this issue as won't fixed because cleaning up the duplicate flags is non-trivial.

I'll give this a try tomorrow.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9047>
_______________________________________

From report at bugs.python.org  Wed Oct 27 00:20:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 22:20:25 +0000
Subject: [issue10207] test_file2k crashes under Windows
In-Reply-To: <1288131625.06.0.246375636536.issue10207@psf.upfronthosting.co.za>
Message-ID: <1288131625.06.0.246375636536.issue10207@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This recurrent crash appeared recently under the XP-4 buildbot, between r85816 and r85819. But none of these revisions looks related to potential file issues.

Each time the test just finishes with:

[...]
test_file2k
program finished with exit code -1073741819

(which according to Google means access violation)

See http://www.python.org/dev/buildbot/builders/x86%20XP-4%202.7/ for test logs.

----------
components: Tests, Windows
keywords: buildbot
messages: 119655
nosy: brian.curtin, db3l, loewis, ocean-city, pitrou
priority: normal
severity: normal
status: open
title: test_file2k crashes under Windows
type: crash
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10207>
_______________________________________

From report at bugs.python.org  Wed Oct 27 00:21:58 2010
From: report at bugs.python.org (Kevin Chen)
Date: Tue, 26 Oct 2010 22:21:58 +0000
Subject: [issue7978] SocketServer doesn't handle syscall interruption
In-Reply-To: <1266779695.23.0.617672066685.issue7978@psf.upfronthosting.co.za>
Message-ID: <1288131718.79.0.410912505814.issue7978@psf.upfronthosting.co.za>


Changes by Kevin Chen <kchen at mit.edu>:


----------
nosy: +kchen

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7978>
_______________________________________

From report at bugs.python.org  Wed Oct 27 00:48:38 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Tue, 26 Oct 2010 22:48:38 +0000
Subject: [issue10201] Fix building of socket module under Solaris
In-Reply-To: <1288110169.62.0.573070204064.issue10201@psf.upfronthosting.co.za>
Message-ID: <1288133318.81.0.252296294095.issue10201@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

This is not a problem under Solaris 10. I guess it is a problem with OpenSolaris/OpenIndiana/Illumos.

Can you confirm?.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10201>
_______________________________________

From report at bugs.python.org  Wed Oct 27 01:05:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 26 Oct 2010 23:05:38 +0000
Subject: [issue10201] Fix building of socket module under Solaris
In-Reply-To: <1288133318.81.0.252296294095.issue10201@psf.upfronthosting.co.za>
Message-ID: <1288134334.3547.36.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> This is not a problem under Solaris 10. I guess it is a problem with
> OpenSolaris/OpenIndiana/Illumos.
> 
> Can you confirm?.

It's with the most recent OpenSolaris development build (build 134).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10201>
_______________________________________

From report at bugs.python.org  Wed Oct 27 01:18:10 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Tue, 26 Oct 2010 23:18:10 +0000
Subject: [issue10202] ftplib doesn't check close status after sending file
In-Reply-To: <1288119890.05.0.476969255522.issue10202@psf.upfronthosting.co.za>
Message-ID: <1288135090.66.0.181611372593.issue10202@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't quite understand the problem. How exactly do you manage to lose data? The ftp server should send a 226 status code to indicate success over the control connection, and presumably it will do so only after receiving the proper TCP shutdown from its operating system. So regardless of any error handling that ftplib or .close() may fail to perform, I doubt that the problem can actually arise.

As for error checking in close(): I think this is a minor issue for this discussion. Usually, close() will succeed *without* sending all data to the remote system. So looking at the close() status will *not* tell you whether all data has been delivered. You would have to use the SO_LINGER socket option for that.

Even with SO_LINGER turned on, it's pretty pointless to check the close status. While we would be able to tell whether the data has arrived at the remote system, we can't know whether the ftp server has actually read them out of the socket, and written them to disk. So we absolutely need the ftp protocol status to determine the outcome of a STOR (say).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10202>
_______________________________________

From report at bugs.python.org  Wed Oct 27 01:50:04 2010
From: report at bugs.python.org (Peter Ingebretson)
Date: Tue, 26 Oct 2010 23:50:04 +0000
Subject: [issue10194] Add gc.remap() function to the gc module.
In-Reply-To: <1288043293.98.0.0362084529098.issue10194@psf.upfronthosting.co.za>
Message-ID: <1288137004.27.0.573809010831.issue10194@psf.upfronthosting.co.za>


Peter Ingebretson <pingebre at yahoo.com> added the comment:

Closing due to general lack of support on python-dev.  Some portion of this implementation may come back as part of a PEP reference implementation.

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10194>
_______________________________________

From report at bugs.python.org  Wed Oct 27 02:05:46 2010
From: report at bugs.python.org (Piotr Matuszewski)
Date: Wed, 27 Oct 2010 00:05:46 +0000
Subject: [issue10208] add mazovia.py to encodings/
In-Reply-To: <1288137946.29.0.185771065626.issue10208@psf.upfronthosting.co.za>
Message-ID: <1288137946.29.0.185771065626.issue10208@psf.upfronthosting.co.za>


New submission from Piotr Matuszewski <pythlea4 at farmatex.com.pl>:

mazovia is an old encoding for Polish language, it's modified cp437 (more info at http://en.wikipedia.org/wiki/Mazovia_encoding and (in Polish, but tables are useful anyway) http://pl.wikipedia.org/wiki/Mazovia_(kod) )

----------
components: Library (Lib), Unicode
files: mazovia.py
messages: 119660
nosy: matusz
priority: normal
severity: normal
status: open
title: add mazovia.py to encodings/
type: feature request
Added file: http://bugs.python.org/file19376/mazovia.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10208>
_______________________________________

From report at bugs.python.org  Wed Oct 27 02:19:19 2010
From: report at bugs.python.org (David Bolen)
Date: Wed, 27 Oct 2010 00:19:19 +0000
Subject: [issue10207] test_file2k crashes under Windows
In-Reply-To: <1288131625.06.0.246375636536.issue10207@psf.upfronthosting.co.za>
Message-ID: <1288138759.52.0.26139972612.issue10207@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Can't really say why it's just hitting now more consistently but the failure is an internal CRT exception during a file close, when it is handed what appears to be an invalid FILE * (the internal structure has bad data).

I think it's more chance that it appears to be in the 86819-85819 change.  I've been able to generate the same error in 85816 with 4-5 test runs.  In all cases it's sporadic, but can trigger just by running test_file2k so doesn't require any other tests to have run.

With a local build and the VS debugger, the failure point is the CRT during an internal flush as part of fclose().  The FILE * structure looks like it became corrupted prior to that point.

The tail end of the failure traceback is:

msvcr90d.dll!_write_nolock(int fh=3, const void * buf=0x00f4e008, unsigned int cnt=1)  Line 322 + 0x6 bytes
msvcr90d.dll!_write(int fh=3, const void * buf=0x00f4e008, unsigned int cnt=1)  Line 75 + 0x11 bytes
msvcr90d.dll!_flush(_iobuf * str=0x10311448)  Line 154 + 0x1d bytes
msvcr90d.dll!_fclose_nolock(_iobuf * str=0x10311448)  Line 105 + 0x9 bytes
msvcr90d.dll!fclose(_iobuf * stream=0x10311448)  Line 57 + 0x9 bytes
python27_d.dll!close_the_file(PyFileObject * f=0x00bef5d8)  Line 451 + 0x7 bytes
python27_d.dll!file_close(PyFileObject * f=0x00bef5d8)  Line 651 + 0x9 bytes
python27_d.dll!call_function(_object * * * pp_stack=0x0145f228, int oparg=12514776)  Line 3996 + 0x10 bytes

The last Python runtime code is in the close_the_file frame (fileobject.c, line 451), it's the line:

    sts = (*local_close)(local_fp)

and local_fp has bad pointers inside its structure:

    local_fp    0x10311448      _iobuf *
                _ptr    0x00f4e009 <Bad Ptr>    char *
                _cnt    16383   int
                _base   0x00f4e008 <Bad Ptr>    char *
                _flag   34178   int
                _file   3       int
                _charbuf        0       int
                _bufsiz 16384   int
                _tmpfname       0x00000000 <Bad Ptr>    char *

I've also seem some cases where _ptr isn't explicitly flagged as a Bad Ptr (e.g., value 0x00e56031 with r85816) but is still invalid to access.

The local_close code runs outside the GIL, so maybe some sort of race condition with the parent Python file object, though the file object internal file point is NULL'd before releasing the GIL so I don't know if that seems plausible.

I'm not sure of the best way to trace back across the C/Python interpreter boundary - the trace above this is really just a lot of PyEval_EvalFrameEx/fast_function/call_function entry points with Python objects that are fairly opaque to the VS debugger.

One thing I do find interesting is that sometimes after continuing past the failure point the tests actually run to completion.  Not sure if that means the issue might be more in test wrapper code than the tests themselves, or just that continuing past the flush failure in the debugger is something the test can't detect.

I'll try to break down the test module later tonight when I have some more time.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10207>
_______________________________________

From report at bugs.python.org  Wed Oct 27 02:36:36 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Oct 2010 00:36:36 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

PyUnicode_EncodeFSDefault() and os.fsencode() should decompose the filename (NFD) before encoding it to utf-8.

PyUnicode_DecodeFSDefault(AndSize)() and os.fsdecode() should precompose the filename (NFC) after decoding it from utf-8.

Qt library does this on Mac: see locale_encode()/locale_decode() (filename encoder/decoder) functions in src/corelib/io/qfile.cpp.

It should fix some issues of test_pep277 on Mac OS X (see #8423).

I'm not completly sure that we should do that :-)

(I used the nosy list from issues #4388 and #8423).

--

Technical Q&A QA1173, Text Encodings in VFS:
http://developer.apple.com/mac/library/qa/qa2001/qa1173.html

Q: I'm writing a file system (VFS) plug-in for Mac OS X. How do I handle text encodings correctly?
A: In Mac OS X's VFS API file names are, by definition, canonically decomposed Unicode, encoded using UTF-8. This raises a number of interesting issues. (...)

----------
assignee: ronaldoussoren
components: Interpreter Core, Macintosh, Unicode
messages: 119662
nosy: MrJean1, amaury.forgeotdarc, db3l, flox, haypo, ixokai, loewis, mark.dickinson, michael.foord, ned.deily, piro, pitrou, ronaldoussoren, rpetrov, skip.montanaro, slmnhq
priority: normal
severity: normal
status: open
title: Mac OS X: Decompose filenames on encode, and precompose filenames on decode
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Wed Oct 27 02:37:34 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Oct 2010 00:37:34 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1288139854.76.0.515114392293.issue8423@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I opened the issue #10209: "Mac OS X: Decompose filenames on encode, and precompose filenames on decode".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Wed Oct 27 02:39:07 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 27 Oct 2010 00:39:07 +0000
Subject: [issue10201] Fix building of socket module under Solaris
In-Reply-To: <1288110169.62.0.573070204064.issue10201@psf.upfronthosting.co.za>
Message-ID: <1288139947.07.0.814649498309.issue10201@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at jcea.es> added the comment:

Could this to be considered a bug in OpenSolaris?.

If not, I think this fix should be backported to 2.5/2.6/2.7/3.1.

Just for the record, I am asking for help to get a buildbot under OpenIndiana: http://openindiana.org/pipermail/openindiana-discuss/2010-October/000974.html . Hope somebody can help out. We need it.

----------
versions: +Python 2.5, Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10201>
_______________________________________

From report at bugs.python.org  Wed Oct 27 02:51:26 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Oct 2010 00:51:26 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288140686.04.0.212440512202.issue10209@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Patch for os.fsencode/fsdecode importing unicodedata in the function (instead of a global import). unicodedata module is not builtin and is dynamically loaded. We should maybe ignore ImportError if the module is not available? With a warning?

For PyUnicode_EncodeFSDefault() and PyUnicode_DecodeFSDefault(AndSize)() (C implementation), we can maybe use a hook (eg. implemented as as configurable callback) and set the hook after loading the unicodedata module.

It would be easier if unicodedata would be builtin module :-)

----------
keywords: +patch
Added file: http://bugs.python.org/file19377/10209.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Wed Oct 27 02:58:06 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Oct 2010 00:58:06 +0000
Subject: [issue10210] os.get_exec_path() should not produce any warning
In-Reply-To: <1288141086.46.0.441985990964.issue10210@psf.upfronthosting.co.za>
Message-ID: <1288141086.46.0.441985990964.issue10210@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

Using -b command line option, os.get_exec_path() always produce a warning. Example:

$ ./python -b
>>> import os: os.get_exec_path({'PATH': ''})
.../Lib/os.py:395: BytesWarning: Comparison between bytes and string
  path_listb = env[b'PATH']
['']

You can see such warning on some buildbots. This function should make this warning quiet because it is expected: it is not possible to check that a dict contains 'PATH' and b'PATH' keys without emiting a BytesWarning (see issue #9636).

Attached patch fixes this bug. It imports the warnings module in get_exec_path() function because os is a core module and it should not import too much modules. But... I'm not sure that it's the right way to fix this issue.

----------
components: Library (Lib), Unicode
files: get_exec_path_byteswarning.patch
keywords: patch
messages: 119666
nosy: haypo
priority: normal
severity: normal
status: open
title: os.get_exec_path() should not produce any warning
versions: Python 3.2
Added file: http://bugs.python.org/file19378/get_exec_path_byteswarning.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10210>
_______________________________________

From report at bugs.python.org  Wed Oct 27 03:06:24 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 27 Oct 2010 01:06:24 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1288141584.59.0.324890152682.issue8777@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Okay, here is a new submission.
I've redesigned it to be more reminiscent of the Java version, by allowing the barrier to have a "Broken" state and raising a BrokenBarrierError.
I've also redesigned the mechanism from a simple perpetually increasing index of "entered" and "released" into a proper two-state machine which is either "filling" or "draining".

There is also a rather comprehensive set of tests.

What is missing is documentation, somethign I shall add if this gets a positive response.

Note how, in the tests, I sometimes create a "barrier2" object to facilitate external synchronization.  This demonstrates the simplicity of using this primitive.

Another note:  In order to implement "timeout" behaviour, I changed Condition.wait() to return True in case it returns due to a timeout occurring.  I folded this into this patch, but if such a change is not accepted, or we want it separately, then I'll have to remove the timeout functionality from the Barrier.  I don't want to have complicated logic in there to measure time.  Also, I do think that locking primitives that time out should be able to provide an indication to that fact to their callers, so condition.wait() really should do that.

----------
Added file: http://bugs.python.org/file19379/barrier3.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Wed Oct 27 03:31:23 2010
From: report at bugs.python.org (David Bolen)
Date: Wed, 27 Oct 2010 01:31:23 +0000
Subject: [issue10207] test_file2k crashes under Windows
In-Reply-To: <1288131625.06.0.246375636536.issue10207@psf.upfronthosting.co.za>
Message-ID: <1288143083.98.0.721991702985.issue10207@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Ok, when it fails, the failure always appears to be one of the FileThreadingTests tests, with the affected close() call occurring within _close_file, called from _close_and_reopen_file, called from _test_close_open_io.  It seems tough to backtrace the VS traces to the exact parent test due to the threading involved, but so far I've only been able to see the problem (with some debugging output added) while in test_close_open_print_buffered.

It's a little tough to be positive, but I can seem to influence the odds of failure a bit with host I/O load, and I have yet to see a failure if I remove that test, while limiting the FileThreadingTests class to just that test fails with about the same frequency as the original full class did.  So even if the issue is more general, that test seems the best way to exercise/analyze it.

So there does seem to likely be a real race condition somewhere.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10207>
_______________________________________

From report at bugs.python.org  Wed Oct 27 03:39:02 2010
From: report at bugs.python.org (John Nagle)
Date: Wed, 27 Oct 2010 01:39:02 +0000
Subject: [issue10202] ftplib doesn't check close status after sending file
In-Reply-To: <1288119890.05.0.476969255522.issue10202@psf.upfronthosting.co.za>
Message-ID: <1288143542.6.0.0120996379651.issue10202@psf.upfronthosting.co.za>


John Nagle <nagle at users.sourceforge.net> added the comment:

Proper behavior for ftplib when sending is to send all desired data, then call "sock.shutdown(socket.SHUT_RDWR)".  This indicates that no more data will be sent, and blocks until the receiver has acknowledged all their data. 

"socketmodule.c" handles this right.  "shutdown" is called on the socket, and the return value is checked.  If the return value is negative, an error handler is returned.  Compare the handling in "close".  

FTP send is one of the few situations where this matters, because FTP uses the close of the data connection to indicate EOF.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10202>
_______________________________________

From report at bugs.python.org  Wed Oct 27 04:28:22 2010
From: report at bugs.python.org (mark saaltink)
Date: Wed, 27 Oct 2010 02:28:22 +0000
Subject: [issue10118] Tkinter does not find font
In-Reply-To: <1287192630.89.0.924571330725.issue10118@psf.upfronthosting.co.za>
Message-ID: <1288146502.29.0.471163546526.issue10118@psf.upfronthosting.co.za>


mark saaltink <platonic.liquid at gmail.com> added the comment:

I built the latest 2.7, with tk/tcl 8.5, and see the same problem.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10118>
_______________________________________

From report at bugs.python.org  Wed Oct 27 04:49:12 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Oct 2010 02:49:12 +0000
Subject: [issue10204] exec string fails with trailing whitespace
In-Reply-To: <1288120878.97.0.786929493479.issue10204@psf.upfronthosting.co.za>
Message-ID: <1288147752.86.0.055674463684.issue10204@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I thought I tested this on 2.6, but I forgot that my system has now made 2.7 the default python.  And now that you mention it, I vaguely remember this feature getting added.  Sorry for the noise.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10204>
_______________________________________

From report at bugs.python.org  Wed Oct 27 04:56:18 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Oct 2010 02:56:18 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1288121568.1.0.392879967985.issue7061@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Qnw-uaLVshZv-gf8s5QvgEerHum_WkxUASWKU@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Oct 26, 2010 at 3:32 PM, Georg Brandl <report at bugs.python.org> wrote:
..
> LGTM, if you verified that the label "debugger" is not in use at the moment.

Good point.  I naively hoped that Sphinx would warn me about a
reference to an undefined label.  Grep found a reference in sys.rst.
I will replace that with a :mod:`pdb` reference which seems to be a
better fit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Wed Oct 27 05:14:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Oct 2010 03:14:28 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288149268.89.0.0104872799727.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed in revision 85853.

Terry, please chime in if I missed anything that you would consider part of this issue.  Note that the speed vs. delay may not be just a doc issue.  I opened issue 10170 for that.

----------
resolution:  -> accepted
stage: commit review -> committed/rejected
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Wed Oct 27 05:32:28 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 27 Oct 2010 03:32:28 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288150348.98.0.913199834375.issue10199@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

First of all: I'd not like to see turtle.py converted into a package. I think with the turtle module things should be as simple as possible and I don't see any need to put approx. 100kB of code into an __init__.py and be it only because there are hundreds of them and on cannot see from the name what's in there. I do not expect the avarage turtle user to look at the code, but certainly some teachers and instructors do even if they are not python specialists accustomed to the use of packages.

As far as I understood from the discussion the MAIN POINT is to make the turtleDemo accessible as easyly as possible.

So at first this needs a decision to put the demo code into the Windows-Distribution.

The next question is where to put it. In my opinion there are two possibilities.

1) The one mentioned by Alexander in msg119612: a turtledemo directory in Lib. 
2) To put a turtledemo directory into the Tools directory (in some sense the demoViewer is sort of a tool, isn't it.)

I quickly prepared a 'prototypical' collection with a modified viewer, which accounts for some of the arguments which came up in the current  discussion. It contains a turtledemo package. Please download it and have a look.

Each demo can be run by doubleclicking, as a standalone script, as well as from the turtledemo.viewer

If from the above options 1) were chosen or the package is somewhere else in the search path, on can - at the interactive prompt - do things like:

>>> from turtledemo import bytedesign
>>> bytedesign.main()

and also:

>>> from turtledemo import viewer
>>> viewer.run()

Morover one can load the examples into Idle and start them via the run-command. So one has a look at the code and moreover the possibility to make changes and try out, what happens.

I have renamed the sample scripts, omitting the tdemo_ - prefix, as 
this looks nicer (at least for me). The previous version turtleDemo recognized scripts with this suffix as belonging to the demo-suite and
added it to the examples menu. This was necessary because of a script, which cannot be demonstrated in the demo_viewer (two canvases). I changed this in my proposition in the following way: scripts that are in the demodirectory and should not appear in the DemoViewer's example-Menu, should end with _.py or some other extension.

To make the demo_viewer importable creates a special problem: the demos are imported by the demoViewer via the __import__ function, so everyone can add his own demos to the demo-directory and they will show up in the viewer. The original version (and even this one) can do this also for demos in subdirectories when started directly. (I've included as an example the geometry directory). This does't work yet for importing the viewer, I only provided a very clumsy quick and dirty solution and I hope that someone has a better, more bright idea to do this more elegantly and correctly.

Now for something completely different: how to make it easily accessible.

1) Put remarks (and links) into the documentation, near the head of the turtle module's docs. (Referring to 24.5.7)
2) Put a hint into the commentary/docstring of the file turtle.py itself.
3) I do not consider it a good idea to put the viewer.py into the 
if __name__ == "__main__" - part of turtle.py thus replacing the current demo. I think this part should demonstrate the possibilities of the module without recurring to extra use of Tkinter (as the demo viewer does). (I must also confess, that the quality of the code of the viewer, which I programmed back in 2006, does not reach the standards I tried to achieve for turtle.py)
4) BUT I'd find it useful to change this final demo code of turtle.py, so it - in the end - displays a message where to find more demos (i. e. turtledemo) or even to put there a question like ("Do you want to see more demos?") and two "turtle-generated" "buttons": "YES" and "NO". If one chooses "Yes", the turtledemo.viewer would pop up in a separate process.

Please consider this to be a proposal or a contribution. I'm very interested in discussing it further and bringing it to a quick and easy solution for Python 3.2. Unfortunately I'm currently involved in a project (also python-related) with very severe time constraints for the next four to five month. So ideas for enhancing the demoviewer and probably turtle.py have to wait until then and possibly will be an issue for Python 3.3

Best regards,
Gregor

----------
Added file: http://bugs.python.org/file19380/turtledemo32.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Wed Oct 27 08:45:30 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Oct 2010 06:45:30 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288161930.03.0.379784153684.issue7061@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

If you do a full build, you'll get a warning; however, currently documents that reference a label will not be recognized as out of date when that label changes or is removed.

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Wed Oct 27 09:06:13 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Oct 2010 07:06:13 +0000
Subject: [issue5688] inability to ignore multiline warnings -- request to add
	re.DOTALL to re.compile
In-Reply-To: <1238858961.61.0.698895898394.issue5688@psf.upfronthosting.co.za>
Message-ID: <1288163173.65.0.928345038012.issue5688@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> works for me
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5688>
_______________________________________

From report at bugs.python.org  Wed Oct 27 09:09:56 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Oct 2010 07:09:56 +0000
Subject: [issue2703] SimpleXMLRPCDispatcher.__init__ is not
	python2.4-backward-compatible
In-Reply-To: <1209290195.97.0.404790617339.issue2703@psf.upfronthosting.co.za>
Message-ID: <1288163396.49.0.0178190046733.issue2703@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Seems to have been changed in 2.6 and 2.7 already.

----------
nosy: +georg.brandl
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2703>
_______________________________________

From report at bugs.python.org  Wed Oct 27 09:10:57 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Oct 2010 07:10:57 +0000
Subject: [issue4828] patch suggestion for webbrowser
In-Reply-To: <1231063999.69.0.0846570539702.issue4828@psf.upfronthosting.co.za>
Message-ID: <1288163457.97.0.507929689528.issue4828@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4828>
_______________________________________

From report at bugs.python.org  Wed Oct 27 09:21:06 2010
From: report at bugs.python.org (anatoly techtonik)
Date: Wed, 27 Oct 2010 07:21:06 +0000
Subject: [issue4828] patch suggestion for webbrowser
In-Reply-To: <1231063999.69.0.0846570539702.issue4828@psf.upfronthosting.co.za>
Message-ID: <1288164066.55.0.703522634769.issue4828@psf.upfronthosting.co.za>


anatoly techtonik <techtonik at gmail.com> added the comment:

Any explanations?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4828>
_______________________________________

From report at bugs.python.org  Wed Oct 27 09:27:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Oct 2010 07:27:24 +0000
Subject: [issue5975] csv unix file format ('\n' line terminator)
In-Reply-To: <1241821870.32.0.544896440632.issue5975@psf.upfronthosting.co.za>
Message-ID: <1288164444.94.0.93200703336.issue5975@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Added in r85856.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5975>
_______________________________________

From report at bugs.python.org  Wed Oct 27 09:29:23 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Oct 2010 07:29:23 +0000
Subject: [issue7167] Smarter FTP passive mode
In-Reply-To: <1255900945.2.0.567216991168.issue7167@psf.upfronthosting.co.za>
Message-ID: <1288164563.75.0.604021960425.issue7167@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing following Giampaolo's suggestion.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7167>
_______________________________________

From report at bugs.python.org  Wed Oct 27 09:30:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Oct 2010 07:30:32 +0000
Subject: [issue4828] patch suggestion for webbrowser
In-Reply-To: <1231063999.69.0.0846570539702.issue4828@psf.upfronthosting.co.za>
Message-ID: <1288164632.22.0.79745718412.issue4828@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Oh, sorry.  Shouldn't do too many things at once.

Well, I think there aren't many webbrowsers that come as a .com file, for example.  And as Amaury shows, the patch can't be applied as is anyway.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4828>
_______________________________________

From report at bugs.python.org  Wed Oct 27 09:31:40 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Oct 2010 07:31:40 +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: <1288164700.36.0.94744932789.issue7911@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Michael: ping? Will you do this before beta1?

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7911>
_______________________________________

From report at bugs.python.org  Wed Oct 27 09:43:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Oct 2010 07:43:47 +0000
Subject: [issue10208] add mazovia.py to encodings/
In-Reply-To: <1288137946.29.0.185771065626.issue10208@psf.upfronthosting.co.za>
Message-ID: <4CC7D82F.9050400@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Piotr Matuszewski wrote:
> 
> New submission from Piotr Matuszewski <pythlea4 at farmatex.com.pl>:
> 
> mazovia is an old encoding for Polish language, it's modified cp437 (more info at http://en.wikipedia.org/wiki/Mazovia_encoding and (in Polish, but tables are useful anyway) http://pl.wikipedia.org/wiki/Mazovia_(kod) )

Is this still in common use ?

The wikipedia pages suggest that it was used in the MS-DOS days,
but those are long over.

Please note that we don't want to add every single existing code
page to Python, just because we can. If their use is marginal,
it's better to maintain them externally.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10208>
_______________________________________

From report at bugs.python.org  Wed Oct 27 10:49:12 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 27 Oct 2010 08:49:12 +0000
Subject: [issue10211] BufferObject doesn't support new buffer interface
In-Reply-To: <1288169352.49.0.219368546772.issue10211@psf.upfronthosting.co.za>
Message-ID: <1288169352.49.0.219368546772.issue10211@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The BufferObject in 2.7 doesn't support the new buffer interface.
This makes it useless for use with the new memoryview object.
This simple patch adds that support.

----------
components: Interpreter Core
files: buffer_newbuf.patch
keywords: easy, patch
messages: 119683
nosy: krisvale
priority: normal
severity: normal
status: open
title: BufferObject doesn't support new buffer interface
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19381/buffer_newbuf.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10211>
_______________________________________

From report at bugs.python.org  Wed Oct 27 12:09:28 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 10:09:28 +0000
Subject: [issue10201] Fix building of socket module under Solaris
In-Reply-To: <1288139947.07.0.814649498309.issue10201@psf.upfronthosting.co.za>
Message-ID: <1288174162.3533.3.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Jes?s Cea Avi?n <jcea at jcea.es> added the comment:
> 
> Could this to be considered a bug in OpenSolaris?.

That's a good question. Perhaps Laca (who wrote the original patch) can
chime in.

> If not, I think this fix should be backported to 2.5/2.6/2.7/3.1.

It's not a security fix, so I think 2.5 and 2.6 are not applicable.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10201>
_______________________________________

From report at bugs.python.org  Wed Oct 27 12:23:29 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Wed, 27 Oct 2010 10:23:29 +0000
Subject: [issue10108] ExpatError not property wrapped
In-Reply-To: <1287093270.3.0.510777453712.issue10108@psf.upfronthosting.co.za>
Message-ID: <1288175009.37.0.6603479291.issue10108@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/issue10108>
_______________________________________

From report at bugs.python.org  Wed Oct 27 12:26:33 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 27 Oct 2010 10:26:33 +0000
Subject: [issue10202] ftplib doesn't check close status after sending file
In-Reply-To: <1288119890.05.0.476969255522.issue10202@psf.upfronthosting.co.za>
Message-ID: <1288175193.95.0.109062787396.issue10202@psf.upfronthosting.co.za>


Giampaolo Rodola' <g.rodola at gmail.com> added the comment:

> Proper behavior for ftplib when sending is to send all desired data, 
> then call "sock.shutdown(socket.SHUT_RDWR)".  This indicates that no 
> more data will be sent, and blocks until the receiver has acknowledged 
> all their data. 

I'm not sure about this. Such a requirement should be respected by both peers and AFAICR there's no FTP-related RFC which explicitly states that shutdown() should be used.

http://www.rfc-archive.org/getrfc.php?rfc=4217 chapter 12.4 should reflect the same use case we're talking about: a client sending a file (STOR).
In the example only close() is used, which perhaps should lead this discussion to question whether socket's close() method is implemented properly, as your linux man quote suggests.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10202>
_______________________________________

From report at bugs.python.org  Wed Oct 27 12:30:25 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 27 Oct 2010 10:30:25 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1288175425.49.0.0114388336643.issue1813@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

We've included this patch in Gentoo for about two years now. Can we get some discussion going on doing something like this?

----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Wed Oct 27 12:36:53 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 27 Oct 2010 10:36:53 +0000
Subject: [issue10212] struct.unpack and cStringIO.StringIO don't support new
	buffer
In-Reply-To: <1288175813.33.0.0310491559114.issue10212@psf.upfronthosting.co.za>
Message-ID: <1288175813.33.0.0310491559114.issue10212@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

When doing socket IO, it is beneficial to use a bytearra() and then using sock.recv_into() to avoid moving data about.
However, many useful functions still don't accept new style buffers, such as the bytearray and memoryview.  In particular, the struct module cannot unpack from them, and the StringIO doesn't accept them as input.

The attached patch adds new-buffer support to the struct module and cStringIO.

----------
components: Interpreter Core
files: newbuffer.patch
keywords: needs review, patch
messages: 119687
nosy: krisvale
priority: normal
severity: normal
status: open
title: struct.unpack and cStringIO.StringIO don't support new buffer
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19382/newbuffer.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10212>
_______________________________________

From report at bugs.python.org  Wed Oct 27 12:42:36 2010
From: report at bugs.python.org (John Levon)
Date: Wed, 27 Oct 2010 10:42:36 +0000
Subject: [issue10201] Fix building of socket module under Solaris
In-Reply-To: <1288110169.62.0.573070204064.issue10201@psf.upfronthosting.co.za>
Message-ID: <1288176156.24.0.841312107798.issue10201@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

This is not a bug in Solaris - the interfaces Python is trying to use are not standardized.

(It's a reasonable RFE for Solaris to fully support these, though - I'll follow up on that.)

WRT the patch, at least the PACKET_* defined would be better done via a specific guard (#ifdef PACKET_LOOPBACK ...).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10201>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:11:58 2010
From: report at bugs.python.org (=?utf-8?b?SmVzw7pzIENlYSBBdmnDs24=?=)
Date: Wed, 27 Oct 2010 11:11:58 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1288177918.89.0.673693215196.issue8852@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/issue8852>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:13:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 11:13:29 +0000
Subject: [issue10212] struct.unpack and cStringIO.StringIO don't support new
	buffer
In-Reply-To: <1288175813.33.0.0310491559114.issue10212@psf.upfronthosting.co.za>
Message-ID: <1288178009.94.0.651261113797.issue10212@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You can't add buffer protocol support to cStringIO in a bugfix release, since it would be a new feature.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10212>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:19:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 11:19:01 +0000
Subject: [issue9913] Misc/SpecialBuilds.txt  is out of date
In-Reply-To: <1285084668.56.0.665403194927.issue9913@psf.upfronthosting.co.za>
Message-ID: <1288178341.44.0.380775642484.issue9913@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Agreed the file needs updating.  Can you do it?

I?m not sure the contents of this file should be moved under Doc.  There is no build/installation guide on docs.python.org, probably because most users don?t build themselves.  Having advanced docs under Misc with a reference in the README seems okay to me.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9913>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:23:55 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 11:23:55 +0000
Subject: [issue10212] struct.unpack and cStringIO.StringIO don't support new
	buffer
In-Reply-To: <1288175813.33.0.0310491559114.issue10212@psf.upfronthosting.co.za>
Message-ID: <1288178635.92.0.178020256651.issue10212@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
components: +Extension Modules -Interpreter Core
nosy: +benjamin.peterson, eric.araujo
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10212>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:25:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 11:25:11 +0000
Subject: [issue10211] BufferObject doesn't support new buffer interface
In-Reply-To: <1288169352.49.0.219368546772.issue10211@psf.upfronthosting.co.za>
Message-ID: <1288178711.54.0.442890262186.issue10211@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Unless there is a mismatch between the documentation and the code, I suspect this will be rejected by the release manager.

----------
nosy: +benjamin.peterson, eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10211>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:27:28 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Oct 2010 11:27:28 +0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1288178848.38.0.994270596416.issue1813@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Looking at this again, I think we should change the codec registry C code to use Py_TOLOWER() and the encoding search function code to use the .translate() approach that Antoine suggested.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:37:26 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 27 Oct 2010 11:37:26 +0000
Subject: [issue7247] test_fcntl_64_bit from test_fcntl.py fails in Python 2.6.4
In-Reply-To: <1257103206.04.0.134413608226.issue7247@psf.upfronthosting.co.za>
Message-ID: <1288179446.22.0.204611919256.issue7247@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

I'm also unable to reproduce this.

----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7247>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:44:52 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 11:44:52 +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: <1288179892.27.0.78044150629.issue10205@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +flox

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10205>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:46:19 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 11:46:19 +0000
Subject: [issue10201] Fix building of socket module under Solaris
In-Reply-To: <1288110169.62.0.573070204064.issue10201@psf.upfronthosting.co.za>
Message-ID: <1288179979.86.0.482307667031.issue10201@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Actually, there's a better patch in #8852.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> _socket fails to build on OpenSolaris x64

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10201>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:47:22 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 11:47:22 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1288180042.88.0.355622528051.issue8852@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

David's patch works here (OpenSolaris build 134).

----------
components: +Build, Extension Modules
nosy: +laca, movement, pitrou
resolution:  -> accepted
stage:  -> commit review
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:51:26 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 27 Oct 2010 11:51:26 +0000
Subject: [issue10213] tests shouldn't fail with unset timezone
In-Reply-To: <1288180286.09.0.61662115749.issue10213@psf.upfronthosting.co.za>
Message-ID: <1288180286.09.0.61662115749.issue10213@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

test_strptime in test_time fails when the timezone is not set:

======================================================================
FAIL: test_strptime (test.test_time.TimeTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File
"/var/tmp/portage/dev-lang/python-2.6.4/work/Python-2.6.4/Lib/test/test_time.py",
line 117, in test_strptime
    (format, strf_output))
AssertionError: conversion specifier '%Z' failed with 'Local time zone must be set--see zic manual page' input.

----------------------------------------------------------------------
Ran 14 tests in 1.206s
Maybe something like this is good enough?

Index: test_time.py
===================================================================
--- test_time.py        (revision 85856)
+++ test_time.py        (working copy)
@@ -111,6 +111,8 @@
             try:
                 time.strptime(strf_output, format)
             except ValueError:
+                if 'Local time zone must be set' in strf_output:
+                    continue
                 self.fail("conversion specifier %r failed with '%s' input." %
                           (format, strf_output))

----------
components: Tests
messages: 119696
nosy: belopolsky, djc
priority: normal
severity: normal
status: open
title: tests shouldn't fail with unset timezone
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10213>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:53:11 2010
From: report at bugs.python.org (John Levon)
Date: Wed, 27 Oct 2010 11:53:11 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1288180391.38.0.802718720087.issue8852@psf.upfronthosting.co.za>


John Levon <movement at users.sourceforge.net> added the comment:

The posted patch: better if the PACKET_* tests were just at the two missing ones rather than removing all of the ones that are actually there like PACKET_OUTGOING.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:58:20 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 11:58:20 +0000
Subject: [issue10203] sqlite3.Row doesn't support sequence protocol
In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>
Message-ID: <1288180700.35.0.76122176983.issue10203@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Hello Paul, thanks for the report.  The doc only describe Row as a tuple-like object, but tuple does implement the Sequence ABC, so I?m inclined to agree with you this is a bug and not a feature request (my first reaction).

Adding Georg, the maintainer of the module, to the nosy list (found his username in Misc/maintainers.rst).

----------
nosy: +eric.araujo, ghaering
versions: +Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10203>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:58:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 11:58:54 +0000
Subject: [issue10203] sqlite3.Row doesn't support sequence protocol
In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>
Message-ID: <1288180734.5.0.709215624504.issue10203@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

(Gerhard, sorry, not well awake :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10203>
_______________________________________

From report at bugs.python.org  Wed Oct 27 13:59:38 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 11:59:38 +0000
Subject: [issue10210] os.get_exec_path() should not produce any warning
In-Reply-To: <1288141086.46.0.441985990964.issue10210@psf.upfronthosting.co.za>
Message-ID: <1288180778.13.0.462278275989.issue10210@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/issue10210>
_______________________________________

From report at bugs.python.org  Wed Oct 27 14:10:29 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 12:10:29 +0000
Subject: [issue10193] Simplify instrospection used by turtle module
In-Reply-To: <1288032526.99.0.352179918003.issue10193@psf.upfronthosting.co.za>
Message-ID: <1288181429.84.0.438942824387.issue10193@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

+1.  This is a small but nice improvement for the added readability and foremost for the removal of obscure code (testing for varargs is easier to understand than ?if co_flags & 0x4?).

(?"=%r" % (name,)? reminds me I never remember to protect my RHS with %-formatting, good job :) I wonder about the name ?name?, since we?re looping other default values here.)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10193>
_______________________________________

From report at bugs.python.org  Wed Oct 27 14:11:07 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 12:11:07 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1288181467.36.0.0927079034107.issue8852@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, here is an updated patch with finer-grained constants injection.

----------
Added file: http://bugs.python.org/file19383/buildsocket.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Wed Oct 27 14:13:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Oct 2010 12:13:47 +0000
Subject: [issue10203] sqlite3.Row doesn't support sequence protocol
In-Reply-To: <1288120293.93.0.799619941752.issue10203@psf.upfronthosting.co.za>
Message-ID: <1288181627.23.0.455233351562.issue10203@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Just as data point: the DB-API 2.0 requires that the row objects returned by the various .fetch*() methods are sequences, i.e. they need to implement the sequence protocol.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10203>
_______________________________________

From report at bugs.python.org  Wed Oct 27 14:14:02 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Wed, 27 Oct 2010 12:14:02 +0000
Subject: [issue9281] Race condition in distutils.dir_util.mkpath()
In-Reply-To: <1279342839.57.0.133468665449.issue9281@psf.upfronthosting.co.za>
Message-ID: <1288181642.29.0.670385164616.issue9281@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

Still, shouldn't this also be fixed in 2.7?

----------
nosy: +djc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9281>
_______________________________________

From report at bugs.python.org  Wed Oct 27 14:16:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 12:16:16 +0000
Subject: [issue4769] b64decode should accept strings or bytes
In-Reply-To: <1230572153.22.0.954048343235.issue4769@psf.upfronthosting.co.za>
Message-ID: <1288181776.7.0.929729192304.issue4769@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4769>
_______________________________________

From report at bugs.python.org  Wed Oct 27 14:19:53 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Oct 2010 12:19:53 +0000
Subject: [issue949667] setblocking() method on file objects
Message-ID: <1288181993.51.0.863020712391.issue949667@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Prototype to test nonblocking file objet:
 - add getblocking() and setblocking() methods to _io._FileIO and all _pyio classes
 - fileio_setblocking() is implemented using fcntl(fd, F_SETFL, flags | O_NONBLOCK) (POSIX only?)
 - BufferedReader.read() uses read1() if the file is blocking

Use test_process.py to test it: this script runs a Python interpreter in a subprocess. It uses select() to check if there is data or not. Eg. type '1+1\n' and then 'exit()\n'. Set PYIO_HAVE_BLOCKING constant to False (in test_process.py) to test the script without io_blocking.patch.

I'm not sure that select() is required, but it doesn't work without it (read() blocks).

----------
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file19384/io_blocking.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue949667>
_______________________________________

From report at bugs.python.org  Wed Oct 27 14:20:08 2010
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 27 Oct 2010 12:20:08 +0000
Subject: [issue949667] setblocking() method on file objects
Message-ID: <1288182008.7.0.0960729029909.issue949667@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


Added file: http://bugs.python.org/file19385/test_process.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue949667>
_______________________________________

From report at bugs.python.org  Wed Oct 27 14:25:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 12:25:45 +0000
Subject: [issue9939] Add a pipe type (FIFO) to the io module
In-Reply-To: <1285341562.44.0.992846065146.issue9939@psf.upfronthosting.co.za>
Message-ID: <1288182345.48.0.478152599113.issue9939@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/issue9939>
_______________________________________

From report at bugs.python.org  Wed Oct 27 14:30:17 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 12:30:17 +0000
Subject: [issue9916] errno module is missing some symbols
In-Reply-To: <1285105452.83.0.807715545592.issue9916@psf.upfronthosting.co.za>
Message-ID: <1288182617.99.0.951609513443.issue9916@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

You could ask python-ideas about -m support.  This test seems to reveal that runpy does not support extension modules:

 $ python -m sys
 /usr/bin/python: No code object available for sys

This may be another bug or feature request to open.

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9916>
_______________________________________

From report at bugs.python.org  Wed Oct 27 14:51:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 12:51:03 +0000
Subject: [issue10207] test_file2k crashes under Windows
In-Reply-To: <1288131625.06.0.246375636536.issue10207@psf.upfronthosting.co.za>
Message-ID: <1288183863.67.0.00242671782695.issue10207@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

There's a patch in issue9295 which might fix a similar problem ("test_close_open_print_buffered sometimes crashes"). Could you try it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10207>
_______________________________________

From report at bugs.python.org  Wed Oct 27 14:57:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 12:57:12 +0000
Subject: [issue9281] Race condition in distutils.dir_util.mkpath()
In-Reply-To: <1279342839.57.0.133468665449.issue9281@psf.upfronthosting.co.za>
Message-ID: <1288184232.53.0.725880478416.issue9281@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Yes, it should, that?s why the versions field lists 2.7 too.

I?ll get to this in some days.

----------
assignee: tarek -> eric.araujo
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9281>
_______________________________________

From report at bugs.python.org  Wed Oct 27 15:06:47 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Oct 2010 13:06:47 +0000
Subject: [issue9916] errno module is missing some symbols
In-Reply-To: <1285105452.83.0.807715545592.issue9916@psf.upfronthosting.co.za>
Message-ID: <1288184807.67.0.155060850014.issue9916@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I'm not surprised -m doesn't work with extension modules.  It would certainly be a new feature to implement such a thing, so it would only be possible for 3.2.  It's not a priority for me to add this support.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9916>
_______________________________________

From report at bugs.python.org  Wed Oct 27 15:13:08 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Oct 2010 13:13:08 +0000
Subject: [issue10214] Misc/python-mode.el is out of date.
In-Reply-To: <1288185188.37.0.749151956354.issue10214@psf.upfronthosting.co.za>
Message-ID: <1288185188.37.0.749151956354.issue10214@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

Misc/python-mode.el is pretty far out of date.  http://launchpad.net/python-mode has the latest versions.  Of course, there's also python.el that comes with GNU Emacs.

I will replace Misc/python-mode.el with Misc/README.Emacs

----------
assignee: barry
messages: 119709
nosy: barry
priority: normal
severity: normal
status: open
title: Misc/python-mode.el is out of date.
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10214>
_______________________________________

From report at bugs.python.org  Wed Oct 27 15:26:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Oct 2010 13:26:47 +0000
Subject: [issue10193] Simplify instrospection used by turtle module
In-Reply-To: <1288181429.84.0.438942824387.issue10193@psf.upfronthosting.co.za>
Message-ID: <AANLkTimM6GSFMzV_h1op25YDrNtZTgfdedQpK7EzV4j+@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Oct 27, 2010 at 8:10 AM, ?ric Araujo <report at bugs.python.org> wrote:
..
> I wonder about the name ?name?, since we?re looping other default values here.)

Good point.  I changed that and committed in revision 85857.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10193>
_______________________________________

From report at bugs.python.org  Wed Oct 27 15:27:08 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Oct 2010 13:27:08 +0000
Subject: [issue10193] Simplify instrospection used by turtle module
In-Reply-To: <1288032526.99.0.352179918003.issue10193@psf.upfronthosting.co.za>
Message-ID: <1288186028.8.0.100353529878.issue10193@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10193>
_______________________________________

From report at bugs.python.org  Wed Oct 27 15:33:40 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Oct 2010 13:33:40 +0000
Subject: [issue6639] turtle: _tkinter.TclError: invalid command name
	".10170160"
In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za>
Message-ID: <1288186420.93.0.419815357463.issue6639@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Same error occurs when the python -m turtle demo is interrupted by closing the window.  I think the correct fix is to exit when the window is closed, but I cannot figure out the best way to achieve that.  This probably should be done at the application/test level.

----------
nosy: +gregorlingl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6639>
_______________________________________

From report at bugs.python.org  Wed Oct 27 15:34:27 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Oct 2010 13:34:27 +0000
Subject: [issue7074] Turtle module crashes python
In-Reply-To: <1254872370.89.0.72942382773.issue7074@psf.upfronthosting.co.za>
Message-ID: <1288186467.66.0.169908586509.issue7074@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/issue7074>
_______________________________________

From report at bugs.python.org  Wed Oct 27 15:35:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Oct 2010 13:35:41 +0000
Subject: [issue1702036] Make Turtle thread-safe so it does not crash
Message-ID: <1288186541.72.0.999907146153.issue1702036@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/issue1702036>
_______________________________________

From report at bugs.python.org  Wed Oct 27 15:42:49 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Oct 2010 13:42:49 +0000
Subject: [issue10214] Misc/python-mode.el is out of date.
In-Reply-To: <1288185188.37.0.749151956354.issue10214@psf.upfronthosting.co.za>
Message-ID: <1288186969.48.0.53943072117.issue10214@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

+1

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10214>
_______________________________________

From report at bugs.python.org  Wed Oct 27 15:50:21 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 27 Oct 2010 13:50:21 +0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1288187421.87.0.247128908404.issue2001@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Unassigning from ping given the lack of comments - I should be able to have a look at this in time for beta 1

----------
assignee: ping -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
_______________________________________

From report at bugs.python.org  Wed Oct 27 16:40:03 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Wed, 27 Oct 2010 14:40:03 +0000
Subject: [issue10211] BufferObject doesn't support new buffer interface
In-Reply-To: <1288169352.49.0.219368546772.issue10211@psf.upfronthosting.co.za>
Message-ID: <1288190403.77.0.0925484090254.issue10211@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Well, we can always fix the documentation, then :)
Seriously, having two different buffer interfaces in the interpreter core that can only communicate through weird middle men (like str()) should be considered a bug.  There shouldn't be any surprises like this. Simple is better than complex.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10211>
_______________________________________

From report at bugs.python.org  Wed Oct 27 16:48:59 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Oct 2010 14:48:59 +0000
Subject: [issue10213] tests shouldn't fail with unset timezone
In-Reply-To: <1288180286.09.0.61662115749.issue10213@psf.upfronthosting.co.za>
Message-ID: <1288190939.59.0.450104223274.issue10213@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

My first reaction to this was the feeling that the error message was correct and appropriate :)

But it is true that since it doesn't represent a failure in Python itself it shouldn't be reported as a failure.  The test should be skipped, though, rather than just doing a continue, so that it appears as a skip in verbose test output.  (You do that by raising a unittest.SkipTest exception.)

----------
nosy: +r.david.murray
type:  -> behavior
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10213>
_______________________________________

From report at bugs.python.org  Wed Oct 27 17:20:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Oct 2010 15:20:56 +0000
Subject: [issue10213] tests shouldn't fail with unset timezone
In-Reply-To: <1288190939.59.0.450104223274.issue10213@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=Cxb1P6CP02ghZ_CkWg_9KfN7s3f+76Tp0nMQi@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Oct 27, 2010 at 10:48 AM, R. David Murray
<report at bugs.python.org> wrote:
..
> My first reaction to this was the feeling that the error message was correct and appropriate :)
>
That was my first reaction as well.

> But it is true that since it doesn't represent a failure in Python itself it shouldn't be reported as a failure.
> ?The test should be skipped, though, rather than just doing a continue, so that it appears as a skip in verbose
> test output. ?(You do that by raising a unittest.SkipTest exception.)

I am not so sure about that.  Changing fail to skip will pretty much
disable the test.  There is no assert in the test.  Maybe we should
replace the fail on ValueError with a real round-trip test? Now, if
the test has prerequisites such as set timezone, it should be skipped
entirely if prerequisites are not met and not after strptime fails.
Is 'TZ' in os.environ a prerequisite on all system?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10213>
_______________________________________

From report at bugs.python.org  Wed Oct 27 17:35:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Oct 2010 15:35:22 +0000
Subject: [issue10213] tests shouldn't fail with unset timezone
In-Reply-To: <1288180286.09.0.61662115749.issue10213@psf.upfronthosting.co.za>
Message-ID: <1288193722.14.0.042576208743.issue10213@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Just put the Z at the end, so the skip only happens if all of the others pass?

What we really need, of course, is parameterized tests :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10213>
_______________________________________

From report at bugs.python.org  Wed Oct 27 17:38:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Oct 2010 15:38:25 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288193905.41.0.90694187592.issue10199@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attached patch, issue10199.diff is mostly a copy of Gregor's turtledemo32.zip, with the main difference being that viewer code is in turtledemo/__main__.py so it can be run with just

$ python -m turtledemo

I would like to commit this before any further improvements.  Just as Gregor, I have many ideas on how to improve the demo, but implementing them would be a subject of a new ticket.

Here is a quick list:

1. Add test_turtledemo to unittests.
2. Add means to run all examples in order without user input.
3. Prune the examples: do we need both "tree" and "forest"?
5. Turn the left panel to the expanded list of tests and add a "show source" button to display source in a separate window.
6. Improve names of examples.   "I_dont_like_tiltdemo" is not really a good name. :-)

----------
keywords: +patch
resolution:  -> accepted
stage:  -> commit review
Added file: http://bugs.python.org/file19386/issue10199.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Wed Oct 27 17:53:10 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Oct 2010 15:53:10 +0000
Subject: [issue10213] tests shouldn't fail with unset timezone
In-Reply-To: <1288193722.14.0.042576208743.issue10213@psf.upfronthosting.co.za>
Message-ID: <AANLkTimJyuknwQXJ4NvJ1dMv-SQGRL4iVLOY_uVzv6Wa@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Oct 27, 2010 at 11:35 AM, R. David Murray
<report at bugs.python.org> wrote:
..
> Just put the Z at the end, so the skip only happens if all of the others pass?

What if time.strptime('%Z', ..) fails  because of a bug in python? We
don't want that to be reported as a skipped test.

BTW, where does  'Local time zone must be set--see zic manual page'
error message come from?  This does not look like a system message and
time.strptime is implemented in python rather than as a wrapper around
a libc call.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10213>
_______________________________________

From report at bugs.python.org  Wed Oct 27 19:04:16 2010
From: report at bugs.python.org (John Nagle)
Date: Wed, 27 Oct 2010 17:04:16 +0000
Subject: [issue10202] ftplib doesn't check close status after sending file
In-Reply-To: <1288119890.05.0.476969255522.issue10202@psf.upfronthosting.co.za>
Message-ID: <1288199056.53.0.132535062708.issue10202@psf.upfronthosting.co.za>


John Nagle <nagle at users.sourceforge.net> added the comment:

Re: "Such a requirement should be respected by both peers and AFAICR there's no FTP-related RFC which explicitly states that shutdown() should be used.".

That's because the FTP spec (RFC 959) talks about TCP in reference to the TCP specification, not the Berkeley Sockets implementation.  "shutdown" is a Berkeley Sockets interface feature, and isn't formally standardized.  Which is why it isn't mentioned in RFCs. 

The issue here is that an FTP data connection send is one of the few places where 1) the sender is indicating an EOF by closing the connection, and 2) the sender cares about complete delivery to the receiver.  (HTTP servers don't care if the client disconnects before transfer is complete.)

The TCP spec (the original RFC 793) says "A TCP will reliably deliver all buffers SENT before the connection was CLOSED so a user who expects no data in return need only wait to hear the connection was CLOSED successfully to know that all his data was received at the destination TCP."  That's the way it was supposed to work when the FTP spec was written.  In other words, "close" is supposed to wait for completion of the TCP close handshake.

Today, it's common to close connections to abandon them, in which case there's no need to wait for the close handshake to complete.  This resulted in a split at the socket level - there's "close", "SO_LINGER" to affect the wait for the close handshake, and an optional timeout. Then there's "shutdown" for when you explicitly care about what's happening during close.  

Python's socket implementation is written with "close" as a "don't care" operation.  Since many Python closes happen implicitly, when a reference count goes to 0, this is appropriate; raising an exception during deallocation generally surprises the user. So it's implicit in the Python interface that, if you're using connection close to signal EOF and care about delivery, you should use "shutdown".

So I'd put a shutdown call in "ftplib" at the end of each data connection send.  That will block at the end of the transfer and raise an exception (I think that's the way the socket library is coded) if the close handshake doesn't finish cleanly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10202>
_______________________________________

From report at bugs.python.org  Wed Oct 27 19:08:30 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 27 Oct 2010 17:08:30 +0000
Subject: [issue10211] BufferObject doesn't support new buffer interface
In-Reply-To: <1288169352.49.0.219368546772.issue10211@psf.upfronthosting.co.za>
Message-ID: <1288199310.98.0.598263439353.issue10211@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The memoryview object was added to simplify porting applications to Python3. If that backport is incomplete in the sense that the memoryview object is not compatible with the standard Python2 object for such memory views, then I'd consider that a bug.

Without compatibility to the buffer objects, there's no way to make other Python2 buffer interface compatible object compatible to memoryviews.

Alternatively, the Python2 memoryview object implementation could also accept objects with the old buffer interface, much like "s*" does.

Note that the patch needs to check the buffer flags - writing to such buffers is not allowed.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10211>
_______________________________________

From report at bugs.python.org  Wed Oct 27 19:14:48 2010
From: report at bugs.python.org (David Bolen)
Date: Wed, 27 Oct 2010 17:14:48 +0000
Subject: [issue10207] test_file2k crashes under Windows
In-Reply-To: <1288131625.06.0.246375636536.issue10207@psf.upfronthosting.co.za>
Message-ID: <1288199688.39.0.222775818362.issue10207@psf.upfronthosting.co.za>


David Bolen <db3l.net at gmail.com> added the comment:

Yes, the patch from issue9295 (py27_fix_threaded_file_close.patch) seems to do the trick.  I managed to get pretty good (90%+ success) at tickling the issue - interestingly by interactively clicking away from the test console window just after starting the test - and have run the test dozens of times with the patch with no problem.

Oddly, I couldn't seem to create the issue with other tests by adding buffering to them, which I had expected if it was a general threading issue with file buffering - only the print test was crashing.  Maybe since print is internally less atomic (with separate I/O due to softspace) it's more susceptible to thread switching.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10207>
_______________________________________

From report at bugs.python.org  Wed Oct 27 19:46:07 2010
From: report at bugs.python.org (Eric Smith)
Date: Wed, 27 Oct 2010 17:46:07 +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: <1288201567.81.0.156143494432.issue10206@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This is caused by r85814. I've got a fix, as soon as I get it in a presentable state I'll post it.

----------
nosy: +eric.smith

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Wed Oct 27 20:29:03 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 18:29:03 +0000
Subject: [issue5027] xml namespace not understood by
	xml.sax.saxutils.XMLGenerator
In-Reply-To: <1232571582.02.0.360824752482.issue5027@psf.upfronthosting.co.za>
Message-ID: <1288204143.45.0.69783554715.issue5027@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

According to http://www.w3.org/TR/xml-names/:

?The prefix xml is by definition bound to the namespace name http://www.w3.org/XML/1998/namespace. It MAY, but need not, be declared, and MUST NOT be bound to any other namespace name. Other prefixes MUST NOT be bound to this namespace name, and it MUST NOT be declared as the default namespace.?

The patch looks good to me.

----------
nosy: +pitrou
resolution:  -> accepted
stage: patch review -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5027>
_______________________________________

From report at bugs.python.org  Wed Oct 27 20:37:41 2010
From: report at bugs.python.org (Gregor Lingl)
Date: Wed, 27 Oct 2010 18:37:41 +0000
Subject: [issue10199] Move Demo/turtle under Lib/
In-Reply-To: <1288108136.2.0.449929547782.issue10199@psf.upfronthosting.co.za>
Message-ID: <1288204661.42.0.184844735996.issue10199@psf.upfronthosting.co.za>


Gregor Lingl <gregorlingl at users.sourceforge.net> added the comment:

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.

We all know, that things once they have found their way into Lib cannot be changed easily afterwards. Guidos argument on backwards compatibility applies. So now is the only point in time to decide about this.

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?

Please note that there are other constraints also for demo_files anyway, like the size of the graphics window and the presence of a main()-function to be called by the viewer. 

I'd like this to be decided actively. 

What do you think?
Best regards,
Gregor

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10199>
_______________________________________

From report at bugs.python.org  Wed Oct 27 20:52:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 18:52:37 +0000
Subject: [issue5027] xml namespace not understood by
	xml.sax.saxutils.XMLGenerator
In-Reply-To: <1232571582.02.0.360824752482.issue5027@psf.upfronthosting.co.za>
Message-ID: <1288205557.71.0.536882639341.issue5027@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85858 (3.2), r85859 (3.1) and r85860 (2.7). Thank you!

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5027>
_______________________________________

From report at bugs.python.org  Wed Oct 27 21:04:08 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Oct 2010 19:04:08 +0000
Subject: [issue10213] tests shouldn't fail with unset timezone
In-Reply-To: <1288180286.09.0.61662115749.issue10213@psf.upfronthosting.co.za>
Message-ID: <1288206248.08.0.138103880133.issue10213@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Well, djc's patch (turned into a skip) would only skip if the specific system error checked for was found.

The message is a system message, you'll see it in the 'date' command output if the timezone isn't set.  A little googling indicates that it is not Gentoo specific.  (Oddly, if I rename my /etc/localtime file date falls back to UTC, but I know I've seen this error when initially installing Gentoo, before I've set /etc/localtime).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10213>
_______________________________________

From report at bugs.python.org  Wed Oct 27 21:47:42 2010
From: report at bugs.python.org (Ralph Gauges)
Date: Wed, 27 Oct 2010 19:47:42 +0000
Subject: [issue5752] xml.dom.minidom does not escape CR,
	LF and TAB characters within attribute values
In-Reply-To: <1239707588.77.0.33795755364.issue5752@psf.upfronthosting.co.za>
Message-ID: <1288208862.43.0.0907762542107.issue5752@psf.upfronthosting.co.za>


Ralph Gauges <ralph.gauges at bioquant.uni-heidelberg.de> added the comment:

I tried to apply the minidom.diff patch below, but it seems that removing the two lines that replace the "<" and ">" characters is not a good idea.
It least in some files I now suddenly get "<" and ">" characters in text elements where there should be &gt; and &lt;

At least the part with the tabs seems to work now and if I add the two lines with the replace calls that got deleted by the patch, everything seems fine.

----------
nosy: +gauges

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5752>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:06:33 2010
From: report at bugs.python.org (Konstantin Svist)
Date: Wed, 27 Oct 2010 20:06:33 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1288209993.26.0.810003595522.issue9942@psf.upfronthosting.co.za>


Konstantin Svist <fry.kun at gmail.com> added the comment:

This issue sounds very interesting to me for a somewhat different reason.
My problem is that I'm trying to run multiple processes on separate CPUs/cores with os.fork(). In short, the data set is the same (~2GB) and the separate processes do whatever they need, although each fork treats the data set as read-only.
Right after the fork, data is shared and fits in RAM nicely, but after a few minutes each child process runs over a bunch of the data set (thereby modifying the ref counters) and the data is copied for each process. RAM usage jumps from 15GB to 30GB and the advantage of a fork is gone.

It would be great if there was an option to separate out the ref counters for specific data structures, since it's obviously a bad idea to turn it on by default for everything and everyone.

----------
nosy: +Fry-kun

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:16:34 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 27 Oct 2010 20:16:34 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288210594.67.0.591442880839.issue7351@psf.upfronthosting.co.za>


Bo?tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I'm reopening this and I am making it a feature request for Python 3.2

----------
components: +Interpreter Core -Documentation
resolution: wont fix -> 
status: closed -> open
type:  -> feature request
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:33:33 2010
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 27 Oct 2010 20:33:33 +0000
Subject: =?utf-8?q?=5Bissue7351=5D_Documentation_typos_found_in_=22zipfile_?=
	=?utf-8?q?=E2=80=94_Work_with_ZIP_archives=22?=
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288211613.37.0.588906419846.issue7351@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> 

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:38:14 2010
From: report at bugs.python.org (Bruce Sherwood)
Date: Wed, 27 Oct 2010 20:38:14 +0000
Subject: [issue10215] Mac Python 3.1 installer does less than earlier
	installers
In-Reply-To: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>
Message-ID: <1288211894.49.0.439153814714.issue10215@psf.upfronthosting.co.za>


New submission from Bruce Sherwood <bruce.sherwood at gmail.com>:

For Python 2.x on Macs, the installer added PATH code to .profile and switched /Library/Framework/Python.framework/Versions/Current to point to the newly installed version of Python. Neither of these actions is carried out by the 3.1.2 installer, and I wonder whether this is intentional or an oversight. Also, it's not clear to me what command one could issue in a terminal to execute the new Python (you can of course start the new Python from the Applications folder).

----------
components: Installation
messages: 119731
nosy: Bruce.Sherwood
priority: normal
severity: normal
status: open
title: Mac Python 3.1 installer does less than earlier installers
type: feature request
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10215>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:41:17 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Oct 2010 20:41:17 +0000
Subject: [issue10216] json.loads() on str erroneously returns str
In-Reply-To: <1288212077.55.0.987280574244.issue10216@psf.upfronthosting.co.za>
Message-ID: <1288212077.55.0.987280574244.issue10216@psf.upfronthosting.co.za>


New submission from Barry A. Warsaw <barry at python.org>:

json is defined as mapping the JSON string type into unicodes.  This works as advertised in Python 2.6 and 3, but in Python 2.7 it returns a str.

% python2.6 -c "import json; print json.loads('{\"foo\":\"bar\"}')"
{u'foo': u'bar'}
% python2.7 -c "import json; print json.loads('{\"foo\":\"bar\"}')"
{'foo': 'bar'}

Platform tested so far: Ubuntu 10.10 amd64.

----------
messages: 119732
nosy: barry
priority: critical
severity: normal
status: open
title: json.loads() on str erroneously returns str
type: behavior
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10216>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:42:18 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Oct 2010 20:42:18 +0000
Subject: [issue10216] json.loads() on str erroneously returns str
In-Reply-To: <1288212077.55.0.987280574244.issue10216@psf.upfronthosting.co.za>
Message-ID: <1288212138.88.0.252181919289.issue10216@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

BTW, the workaround for Python 2.7 is to pass a unicode to json.loads().

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10216>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:43:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Wed, 27 Oct 2010 20:43:28 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288212208.33.0.320624108331.issue7351@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Bo?tjan, you need to update your patch to add the missing alias to the old name, as well as docs and test updates.

I?m +0 on the change.

----------
stage: committed/rejected -> patch review
title: Documentation typos found in "zipfile ? Work with ZIP archives" -> Rename BadZipfile to BadZipFile for consistency

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:43:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 20:43:56 +0000
Subject: [issue10216] json.loads() on str erroneously returns str
In-Reply-To: <1288212077.55.0.987280574244.issue10216@psf.upfronthosting.co.za>
Message-ID: <1288212236.75.0.267671525734.issue10216@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Duplicate of issue10038.

----------
nosy: +pitrou
resolution:  -> duplicate
status: open -> closed
superseder:  -> Returntype of json.loads() on strings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10216>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:46:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 20:46:32 +0000
Subject: [issue8852] _socket fails to build on OpenSolaris x64
In-Reply-To: <1275143413.04.0.262553470749.issue8852@psf.upfronthosting.co.za>
Message-ID: <1288212392.11.0.368825117458.issue8852@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85868 (3.2), r85869 (3.1) and r85870 (2.7). Thank you.

----------
resolution: accepted -> fixed
stage: commit review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8852>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:46:34 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Wed, 27 Oct 2010 20:46:34 +0000
Subject: [issue9942] Allow memory sections to be OS MERGEABLE
In-Reply-To: <1285350759.4.0.118127426287.issue9942@psf.upfronthosting.co.za>
Message-ID: <1288212394.46.0.334872313166.issue9942@psf.upfronthosting.co.za>


Dave Malcolm <dmalcolm at redhat.com> added the comment:

One possible use for this: mark the "str" buffers of PyUnicodeObject instances when demarshalling docstrings from disk; in theory these ought not to change, and can be quite large: the bulk of the memory overhead is stored in a separate allocation from the object, and thus isn't subjected to the ob_refcnt twiddling.

No idea if it's worth it though; the syscall overhead might slow down module import; also, KSM works at the level of 4K pages, and it's not clear that the allocations would line up nicely with pages.

FWIW, various related ideas here:
  http://dmalcolm.livejournal.com/4183.html
Again, no idea if these are worthwhile, this was a brainstorm on my blog, and some of the ideas would involve major surgery to CPython to implement.

----------
nosy: +dmalcolm

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9942>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:49:54 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Oct 2010 20:49:54 +0000
Subject: [issue10216] json.loads() on str erroneously returns str
In-Reply-To: <1288212077.55.0.987280574244.issue10216@psf.upfronthosting.co.za>
Message-ID: <1288212594.94.0.818061139302.issue10216@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Yay.  I guess I have to submit a tracker bug now because searching for "json unicode" didn't turn up the original bug. ;/

Thanks for duping it __ap__.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10216>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:57:24 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Oct 2010 20:57:24 +0000
Subject: [issue10038] Returntype of json.loads() on strings
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1288213044.84.0.729232909389.issue10038@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

I completely agree with Fred; this is a regression and a bug in Python 2.7 and should be fixed.  I have a doctest in Mailman 3 for example that cannot pass in both Python 2.6 and 2.7 (without IMO ugly hackery).  Not only that, but json is documented as converting JSON str to unicode, which it does fine in Python 2.6, 3.1 and 3.2.  Why should Python 2.7 be different (and broken)?

----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:59:23 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Oct 2010 20:59:23 +0000
Subject: [issue10038] json.loads() on str erroneously returns str. should
	return unicode
In-Reply-To: <1286379418.7.0.631387512608.issue10038@psf.upfronthosting.co.za>
Message-ID: <1288213163.54.0.669692312041.issue10038@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
title: Returntype of json.loads() on strings -> json.loads() on str erroneously returns str.  should return unicode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Wed Oct 27 22:59:44 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 27 Oct 2010 20:59:44 +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: <1288213184.34.0.125946612054.issue10038@psf.upfronthosting.co.za>


Changes by Barry A. Warsaw <barry at python.org>:


----------
title: json.loads() on str erroneously returns str.  should return unicode -> json.loads() on str should return unicode, not str

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Wed Oct 27 23:11:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 21:11:48 +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: <1288213908.07.0.023365029603.issue10215@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
assignee:  -> ronaldoussoren
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10215>
_______________________________________

From report at bugs.python.org  Wed Oct 27 23:20:54 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Oct 2010 21:20:54 +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: <1288214454.79.0.0127695961736.issue10215@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Yes this is deliberate.  On linux, 'python' is Python2, and 'python3' is Python3.  I'm not a mac user, so I don't know exactly how the naming conventions work there, but I certainly wouldn't expect the 'current version' of 'python' to change to python3.  I think perhaps the command name you use from the terminal is the same as it is on linux: python3, but I'm not positive.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10215>
_______________________________________

From report at bugs.python.org  Wed Oct 27 23:24:06 2010
From: report at bugs.python.org (R. David Murray)
Date: Wed, 27 Oct 2010 21:24:06 +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: <1288214646.93.0.0241473849395.issue10215@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution:  -> invalid
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10215>
_______________________________________

From report at bugs.python.org  Wed Oct 27 23:37:27 2010
From: report at bugs.python.org (Rodrigue Alcazar)
Date: Wed, 27 Oct 2010 21:37:27 +0000
Subject: [issue9517] Make test.script_helper more comprehensive,
	and use it in the test suite
In-Reply-To: <1280962247.74.0.724550733964.issue9517@psf.upfronthosting.co.za>
Message-ID: <1288215447.44.0.071776244477.issue9517@psf.upfronthosting.co.za>


Rodrigue Alcazar <rodriguealcazar at gmail.com> added the comment:

> someone wanting to get to know the process of working on CPython without having to deal with anything that is particularly tricky to understand.

That sounds exactly like me :)

I can have a look at this ticket.

----------
nosy: +Rodrigue.Alcazar

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9517>
_______________________________________

From report at bugs.python.org  Thu Oct 28 00:30:56 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Wed, 27 Oct 2010 22:30:56 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288218656.75.0.941169915676.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

I've (finally) finalized the api and prepared pyliblzma to be ready for inclusion now.

The code can be found in the 'py3k' branch referred to earlier.

Someone else (don't remember who:p) volunteered for writing the PEP earlier, so I leave it up to that person to write the PEP, I won't be able to get around to do so myself in the near future..

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct 28 00:46:10 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 27 Oct 2010 22:46:10 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288219570.76.0.784585048201.issue6715@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct 28 01:40:43 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 27 Oct 2010 23:40:43 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288222843.13.0.608899648083.issue6715@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

As promised, here is a quick review of the module.
https://code.launchpad.net/~proyvind/pyliblzma/py3k looks ready for a new entry in the PyPI, but for inclusion in core python it needs some cleanup:

- I suppose that src/pyliblzma.c is the only interesting file. In CPython it will be named Modules/lzmamodule.c
- There are some calls to malloc(), calloc() and free() that are incorrect (there is even a call to free() on a PyObject*!); in any case, functions like PyMem_Malloc() are preferred.
- please don't use alloca (and it has another name on Windows)
- snprintf is not available everywhere; use PyOS_snprintf instead.
- The module does not compile on Windows: types like uint8_t don't exist,  __attribute__((unused)) is GCC-specific.
- Don't use PyBytesObject*; PyObject* is enough and avoids many casts.
- PyLong_FromLong(LZMA_FILTER_LZMA1) truncates the value on 32bit platforms
- You could use LZMA_VERSION_STRING to fill the version attribute.

Also, I did not find any documentation.
Otherwise the code follows CPython conventions and is easy to read. Good job!

3.2beta1 is scheduled for November 13, 2010, and no new feature will be accepted after. Do you think you can update it before the limit? otherwise the package could live in PyPI before it is shipped with Python.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct 28 01:57:30 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 27 Oct 2010 23:57:30 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1288212208.33.0.320624108331.issue7351@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=FjFoTxoTdVx5bXHcJR0z141Kg+33gVL6zwEky@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

I am -1 for the alias. I want that this gets renamed in Python 3.2, not
aliased. I don't care about old pickles. Anyway, who has BadZipfile object
pickled? Just incorporate my patch and fix the docs and any test
cases/units. Thanks.

On Wed, Oct 27, 2010 at 10:43 PM, ??ric Araujo <report at bugs.python.org>wrote:

>
> ??ric Araujo <merwok at netwok.org> added the comment:
>
> Bo??tjan, you need to update your patch to add the missing alias to the old
> name, as well as docs and test updates.
>
> I???m +0 on the change.
>
> ----------
> stage: committed/rejected -> patch review
> title: Documentation typos found in "zipfile ??? Work with ZIP archives" ->
> Rename BadZipfile to BadZipFile for consistency
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7351>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19387/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________
-------------- next part --------------
I am -1 for the alias. I want that this gets renamed in Python 3.2, not aliased. I don&#39;t care about old pickles. Anyway, who has BadZipfile object pickled? Just incorporate my patch and fix the docs and any test cases/units. Thanks.<br>
<br><div><br><div class="gmail_quote">On Wed, Oct 27, 2010 at 10:43 PM, ??ric Araujo <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<br>
Bo??tjan, you need to update your patch to add the missing alias to the old name, as well as docs and test updates.<br>
<br>
I???m +0 on the change.<br>
<br>
----------<br>
stage: committed/rejected -&gt; patch review<br>
title: Documentation typos found in &quot;zipfile ??? Work with ZIP archives&quot; -&gt; Rename BadZipfile to BadZipFile for consistency<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/issue7351" target="_blank">http://bugs.python.org/issue7351</a>&gt;<br>
_______________________________________<br>
</blockquote></div><br></div>

From report at bugs.python.org  Thu Oct 28 01:58:21 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Wed, 27 Oct 2010 23:58:21 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288223901.79.0.910368740905.issue7351@psf.upfronthosting.co.za>


Changes by Bo?tjan Mejak <bostjan.mejak at gmail.com>:


Removed file: http://bugs.python.org/file19387/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 02:11:43 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Thu, 28 Oct 2010 00:11:43 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288224703.73.0.483830847858.issue7351@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

You may "not care" about backwards compatibility, but introducing a breaking change in 3.2 for mere style-conformity is not OK, IMO. If the patcher insists on it being a breaking change, it should be rejected.

FWIW, this casing is sufficiently bizarre and inconsistent in the module itself, that it seems clearly wrong and likely to produce difficulties for people using it-- so although I'm not upgrading to Python3 anytime soon, I'd really like to change my code to be BadZipFile when I do, so I'd be +1 with an alias. :)

----------
nosy: +ixokai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 02:29:56 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 28 Oct 2010 00:29:56 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1288224703.73.0.483830847858.issue7351@psf.upfronthosting.co.za>
Message-ID: <AANLkTinEgzPFoaTSWbhf7ayMYm0J+SMGVUY5s_LO2f6P@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

No alias. Be stubborn and let the stdlib die in inconsistency.

On Thu, Oct 28, 2010 at 2:11 AM, Stephen Hansen <report at bugs.python.org>wrote:

>
> Stephen Hansen <me+python at ixokai.io <me%2Bpython at ixokai.io>> added the
> comment:
>
> You may "not care" about backwards compatibility, but introducing a
> breaking change in 3.2 for mere style-conformity is not OK, IMO. If the
> patcher insists on it being a breaking change, it should be rejected.
>
> FWIW, this casing is sufficiently bizarre and inconsistent in the module
> itself, that it seems clearly wrong and likely to produce difficulties for
> people using it-- so although I'm not upgrading to Python3 anytime soon, I'd
> really like to change my code to be BadZipFile when I do, so I'd be +1 with
> an alias. :)
>
> ----------
> nosy: +ixokai
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7351>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19388/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________
-------------- next part --------------
No alias. Be stubborn and let the stdlib die in inconsistency.<br><br><div class="gmail_quote">On Thu, Oct 28, 2010 at 2:11 AM, Stephen Hansen <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
Stephen Hansen &lt;<a href="mailto:me%2Bpython at ixokai.io">me+python at ixokai.io</a>&gt; added the comment:<br>
<br>
You may &quot;not care&quot; about backwards compatibility, but introducing a breaking change in 3.2 for mere style-conformity is not OK, IMO. If the patcher insists on it being a breaking change, it should be rejected.<br>

<br>
FWIW, this casing is sufficiently bizarre and inconsistent in the module itself, that it seems clearly wrong and likely to produce difficulties for people using it-- so although I&#39;m not upgrading to Python3 anytime soon, I&#39;d really like to change my code to be BadZipFile when I do, so I&#39;d be +1 with an alias. :)<br>

<br>
----------<br>
nosy: +ixokai<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/issue7351" target="_blank">http://bugs.python.org/issue7351</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>

From report at bugs.python.org  Thu Oct 28 03:04:45 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Thu, 28 Oct 2010 01:04:45 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288227885.97.0.852913821613.issue7351@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

Considering I do use zipfiles a lot, I slightly care about this (at least, eventually)-- I'm attaching a new patch, with doc and test changes as well (and the compatibility alias).

What convinced me was looking at test_zipfile, and noticing how often it actually confused the issue in comments at least, between typing BadZipfile and BadZipFile.

Dunno if I worded the doc-change well, so you may want to adjust that.

----------
Added file: http://bugs.python.org/file19389/issue7351-complete.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 03:06:36 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Thu, 28 Oct 2010 01:06:36 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288227996.0.0.823424345661.issue7351@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

Oh: and I tested it against branches/py3k in the head, it applies cleanly and builds, and test_zipfile runs without error.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 03:12:24 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 28 Oct 2010 01:12:24 +0000
Subject: [issue6639] turtle: _tkinter.TclError: invalid command name
	".10170160"
In-Reply-To: <1249344565.24.0.634557720335.issue6639@psf.upfronthosting.co.za>
Message-ID: <1288228344.45.0.0330844076797.issue6639@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy: +ned.deily -BreamoreBoy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6639>
_______________________________________

From report at bugs.python.org  Thu Oct 28 03:28:44 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 28 Oct 2010 01:28:44 +0000
Subject: [issue10211] BufferObject doesn't support new buffer interface
In-Reply-To: <1288169352.49.0.219368546772.issue10211@psf.upfronthosting.co.za>
Message-ID: <1288229324.55.0.59424294355.issue10211@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Do you mean that we should disable writing for the new style buffer interface?  Currently the patch respects the Buffer object's read-only flag (self->b_readonly):

static int buffer_getbuffer(PyBufferObject *self, Py_buffer *buf, int flags)
{
	void *ptr;
	Py_ssize_t size;
	if (!get_buf(self, &ptr, &size, ANY_BUFFER))
		return -1;
	return PyBuffer_FillInfo(buf, (PyObject*)self, ptr, size,
		self->b_readonly, flags);
}

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10211>
_______________________________________

From report at bugs.python.org  Thu Oct 28 03:46:53 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 28 Oct 2010 01:46:53 +0000
Subject: [issue10212] struct.unpack and cStringIO.StringIO don't support new
	buffer
In-Reply-To: <1288175813.33.0.0310491559114.issue10212@psf.upfronthosting.co.za>
Message-ID: <1288230413.47.0.0692085021147.issue10212@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

I disagree.  It's not a new feature.  We're merely completing an old feature (adding new-style buffers from 3.x to 2.7) that wasn't fully implemented. by the core.  The new buffer isn't accepted in a lot of places where you'd expect it to be.

The good alternative, of course, would be to add this to "trunk" but for some reason that is frowned upon.

See also issue 10211

----------
status: pending -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10212>
_______________________________________

From report at bugs.python.org  Thu Oct 28 03:52:51 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Thu, 28 Oct 2010 01:52:51 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1288230771.94.0.873453946795.issue10116@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

The attached patch wraps all the calls to the internet in support.transient_internet; I ran it against 3.x and it passed, and then I ran it for quite awhile with the -F option, and encountered one event that I believe would previously had resulted in one of these sporadic failures, and it resulted in a skipped 'resource not available' message. 

I left in the previous 'retry' code, just by virtue of changing as little as possible. I can adjust if its desired.

I believe that transient_internet won't capture EBADF: so if that particular sporadic failure happens again, I'll post up a new issue about it.

----------
keywords: +patch
Added file: http://bugs.python.org/file19390/issue10116.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Thu Oct 28 03:55:44 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 28 Oct 2010 01:55:44 +0000
Subject: [issue10038] Returntype of json.loads() on strings
In-Reply-To: <1288213044.84.0.729232909389.issue10038@psf.upfronthosting.co.za>
Message-ID: <AANLkTinEmty-vxKemW0Um_hBAUe2nF4COm0y7owCs1GT@mail.gmail.com>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

I'll note that it seems relevant that this package is not considered
"externally maintained" by the terms of PEP 360:

    http://www.python.org/dev/peps/pep-0360/

Given the level of attention this has received from the originator of
the code, we should not hesitate to commit technically acceptable
changes to the Python repository,

----------
title: json.loads() on str should return unicode, not str -> Returntype of json.loads() on strings

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Thu Oct 28 04:58:26 2010
From: report at bugs.python.org (Manfred Bartz)
Date: Thu, 28 Oct 2010 02:58:26 +0000
Subject: [issue10217] python-2.7.amd64.msi install fails
In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>
Message-ID: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>


New submission from Manfred Bartz <manfred.bartz at gmail.com>:

python-2.7.amd64.msi as well as python-2.6.6.amd64.msi fail to install on a Windows7-64 system.  In both cases with: "An error occurred during the installation of assembly 'Microsoft.VC90.CRT,version=9.0.21022.8 ...'"

See attached screen-cap.

The installer succeeds with its automatic roll-back.

python-2.7.msi (32bit installer) succeeds without any problems.

----------
components: Installation, Windows
files: Python-64bit_on_Win7-64_install_fails.png
messages: 119753
nosy: Manfred.Bartz
priority: normal
severity: normal
status: open
title: python-2.7.amd64.msi install fails
type: crash
versions: Python 2.6, Python 2.7
Added file: http://bugs.python.org/file19391/Python-64bit_on_Win7-64_install_fails.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10217>
_______________________________________

From report at bugs.python.org  Thu Oct 28 05:02:34 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 28 Oct 2010 03:02:34 +0000
Subject: [issue10217] python-2.7.amd64.msi install fails
In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>
Message-ID: <1288234954.77.0.471847133669.issue10217@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
nosy: +brian.curtin
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10217>
_______________________________________

From report at bugs.python.org  Thu Oct 28 05:11:44 2010
From: report at bugs.python.org (Manfred Bartz)
Date: Thu, 28 Oct 2010 03:11:44 +0000
Subject: [issue10217] python-2.7.amd64.msi install fails
In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>
Message-ID: <1288235504.79.0.444177069374.issue10217@psf.upfronthosting.co.za>


Manfred Bartz <manfred.bartz at gmail.com> added the comment:

since the error msg suggests that the installer detected a 32 bit system, I attached a partial screen cap of system properties -- it really is a Win7-64 system, Enterprise edition.

----------
Added file: http://bugs.python.org/file19392/Python-64bit_on_Win7-64_sysProperties.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10217>
_______________________________________

From report at bugs.python.org  Thu Oct 28 05:22:00 2010
From: report at bugs.python.org (Brian Curtin)
Date: Thu, 28 Oct 2010 03:22:00 +0000
Subject: [issue10217] python-2.7.amd64.msi install fails
In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>
Message-ID: <1288236120.67.0.0443942749987.issue10217@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

The 2.6, 2.7, and 3.1 amd64 installers work on my 64-bit Windows 7 machines.

Can you follow the steps in msg83923 on #4735?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10217>
_______________________________________

From report at bugs.python.org  Thu Oct 28 06:13:01 2010
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 28 Oct 2010 04:13:01 +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: <1288239181.99.0.465032724988.issue10038@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


----------
title: Returntype of json.loads() on strings -> json.loads() on str should return unicode, not str

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Thu Oct 28 08:26:25 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 28 Oct 2010 06:26:25 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1288247185.32.0.368829847477.issue8777@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

ping?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu Oct 28 08:39:46 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Oct 2010 06:39:46 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288247986.36.0.412776123921.issue7351@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied after review in r85873. (Please make sure your patches don't have trailing whitespace.)

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 08:42:39 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Oct 2010 06:42:39 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288248159.95.0.816775346336.issue7351@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
Removed message: http://bugs.python.org/msg119757

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 08:42:48 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Oct 2010 06:42:48 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288248168.0.0.71876341517.issue7351@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Applied after review in r85874. (Please make sure your patches don't have trailing whitespace.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 08:43:41 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Oct 2010 06:43:41 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1288248221.19.0.59283275125.issue8777@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The tests pass for me, and the patch looks good except for a stray change to Condition objects.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu Oct 28 08:54:51 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 28 Oct 2010 06:54:51 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1288248891.54.0.0181403590968.issue8777@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Right.  The condition object change is necessary to have timeout work.  I can remove that feature, and slate it for another day.  Add a separate patch for a Condition.wait() return value.  All of the other apis are able to let the caller know whether a timeout occurred or not, I think Condition.wait() should do the same.

Actually, I can fudge the timeout with time.clock(), which is good enough.

I'll write up some docs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu Oct 28 08:57:25 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Oct 2010 06:57:25 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1288249045.61.0.570214381669.issue8777@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, that change would be fine by me, it was just not explained anywhere in the patch.  So if it's going to be documented (with versionchanged etc.), just leave it in.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu Oct 28 09:24:54 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 28 Oct 2010 07:24:54 +0000
Subject: [issue10213] tests shouldn't fail with unset timezone
In-Reply-To: <1288180286.09.0.61662115749.issue10213@psf.upfronthosting.co.za>
Message-ID: <1288250694.06.0.971095184729.issue10213@psf.upfronthosting.co.za>


Dirkjan Ochtman <dirkjan at ochtman.nl> added the comment:

You can easily reproduce (at least on Gentoo) by copying /usr/share/zoneinfo/Factory to /etc/localtime.

By checking for this exact message, I don't think the chance is very high that we're hiding a Python bug. I also think that Python tests should test Python; if we see this message, we know we can't reliably test Python, in which case I think a skipped test (hey, we can't test this!) is better than a failed test (implication that Python failed).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10213>
_______________________________________

From report at bugs.python.org  Thu Oct 28 09:34:22 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 28 Oct 2010 07:34:22 +0000
Subject: [issue10218] Add a return value to threading.Condition.wait()
In-Reply-To: <1288251262.79.0.658149458375.issue10218@psf.upfronthosting.co.za>
Message-ID: <1288251262.79.0.658149458375.issue10218@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

Add a return value to Condition.wait() that can be used to tell if Condition.wait() returns due to a timeout effect.  This mirrors other wait apis in threading.py

----------
components: Library (Lib)
files: condwait.patch
keywords: patch
messages: 119763
nosy: georg.brandl, krisvale
priority: normal
severity: normal
status: open
title: Add a return value to threading.Condition.wait()
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19393/condwait.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10218>
_______________________________________

From report at bugs.python.org  Thu Oct 28 10:21:16 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 28 Oct 2010 08:21:16 +0000
Subject: [issue8755] idle crash  UnicodeDecodeError utf-8 codec
In-Reply-To: <1274206913.48.0.235847350829.issue8755@psf.upfronthosting.co.za>
Message-ID: <1288254076.64.0.996103042429.issue8755@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Duplicate of Issue1028.

----------
nosy: +ned.deily
resolution:  -> duplicate
superseder:  -> Tkinter binding involving Control-spacebar raises unicode error

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8755>
_______________________________________

From report at bugs.python.org  Thu Oct 28 10:21:56 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 28 Oct 2010 08:21:56 +0000
Subject: [issue8755] idle crash  UnicodeDecodeError utf-8 codec
In-Reply-To: <1274206913.48.0.235847350829.issue8755@psf.upfronthosting.co.za>
Message-ID: <1288254116.47.0.0154390607862.issue8755@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy:  -ned.deily
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8755>
_______________________________________

From report at bugs.python.org  Thu Oct 28 10:47:54 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 28 Oct 2010 08:47:54 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1288255674.46.0.876710783625.issue8777@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Here is an updated patch.  It contains documentation.
ReStructured isn't my Forte, and I don't know how to verify that it is correct, so please review it for me.

----------
dependencies: +Add a return value to threading.Condition.wait()
Added file: http://bugs.python.org/file19394/barrier4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu Oct 28 11:00:52 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Oct 2010 09:00:52 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1288256452.21.0.384007054763.issue8777@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Two comments:

* The return value of wait() isn't documented well.  What is the significance of the returned index, i.e. what does distinguish it from a randomly selected one in range(parties)?

* get_parties() and is_broken() should be properties (waiting, broken), to be consistent with other threading APIs (Thread.name etc). get_waiting() does "real" work (can it block?) and should remain a method.

Don't worry about markup errors, I review doc changes routinely after they are committed.

*

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu Oct 28 11:03:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Oct 2010 09:03:36 +0000
Subject: [issue10218] Add a return value to threading.Condition.wait()
In-Reply-To: <1288251262.79.0.658149458375.issue10218@psf.upfronthosting.co.za>
Message-ID: <1288256616.84.0.680583483942.issue10218@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed in r85876.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10218>
_______________________________________

From report at bugs.python.org  Thu Oct 28 11:08:06 2010
From: report at bugs.python.org (Ned Deily)
Date: Thu, 28 Oct 2010 09:08:06 +0000
Subject: [issue6008] Idle should be installed as `idle3.1` and not `idle3`
In-Reply-To: <1242175792.97.0.077794043098.issue6008@psf.upfronthosting.co.za>
Message-ID: <1288256886.17.0.267538168025.issue6008@psf.upfronthosting.co.za>


Changes by Ned Deily <nad at acm.org>:


----------
nosy:  -BreamoreBoy
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6008>
_______________________________________

From report at bugs.python.org  Thu Oct 28 11:28:16 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 28 Oct 2010 09:28:16 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1288258096.03.0.657585549761.issue8777@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Right.
I've provided more text for the return value and provided an example.
I?ve changed all three to properties, the locking wasn't really required for waiting().
I added some extra tests for the properties.

----------
Added file: http://bugs.python.org/file19395/barrier4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu Oct 28 11:36:24 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Oct 2010 09:36:24 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1288258584.01.0.167211147264.issue8777@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good to me now, I think you can commit it.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu Oct 28 11:45:07 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Thu, 28 Oct 2010 09:45:07 +0000
Subject: [issue8777] Add threading.Barrier
In-Reply-To: <1274375262.53.0.647489735751.issue8777@psf.upfronthosting.co.za>
Message-ID: <1288259107.0.0.294057055395.issue8777@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Committed as revision 85878

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8777>
_______________________________________

From report at bugs.python.org  Thu Oct 28 12:56:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 10:56:15 +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: <1288263375.89.0.617379183933.issue9981@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/issue9981>
_______________________________________

From report at bugs.python.org  Thu Oct 28 13:43:18 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 28 Oct 2010 11:43:18 +0000
Subject: [issue10219] BufferedReader.read1 does not check for closed file
In-Reply-To: <1288266198.95.0.214499177882.issue10219@psf.upfronthosting.co.za>
Message-ID: <1288266198.95.0.214499177882.issue10219@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

The following snippet should raise ValueError (twice :-)

f = open('foo', 'rb')
print(f.read1(1)) # OK
f.close()
print(f.read1(5)) # expected ValueError("I/O operation on closed file")
print(f.peek())   # expected ValueError("I/O operation on closed file")

The _pyio implementation of BufferedReader.read() has the same issue.

----------
messages: 119771
nosy: amaury.forgeotdarc, pitrou
priority: normal
severity: normal
status: open
title: BufferedReader.read1 does not check for closed file

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10219>
_______________________________________

From report at bugs.python.org  Thu Oct 28 13:43:55 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 28 Oct 2010 11:43:55 +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: <1288266235.51.0.533378857834.issue10206@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

This patch fixes the issue, and makes print_error_text slightly more understandable (and efficient to boot, not that it matters).

But I'm not convinced it's the correct solution. I think the real error might be the computation "offset" in the caller. I'm still looking at it.

----------
assignee:  -> eric.smith
components: +Interpreter Core
keywords: +patch
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19396/issue10206.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Thu Oct 28 13:46:24 2010
From: report at bugs.python.org (Eric Smith)
Date: Thu, 28 Oct 2010 11:46:24 +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: <1288266384.59.0.38473010178.issue10206@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Now that I think about it some more, I think my patch (although it fixes this issue and passes all tests) doesn't do what the original code does in the presence of multiple newlines. I'm going to rework it some more. I'll have another patch shortly.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Thu Oct 28 14:42:53 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Oct 2010 12:42:53 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

Generators can be in four different states that may be relevant to framework code making use of them (especially as coroutines). This state is all currently available from Python code, but is rather obscure and could be made readable.

The four states are:

Created:
  "g.gi_frame is not None and g.gi_frame.f_lasti == -1"
  (Frame exists, but no instructions have been executed yet)

Currently executing:
  "g.gi_running"
  (This being true implies other things about the state as well, but this is all you need to check)

Suspended at a yield point:
  "g.gi_frame is not None and g.gi_frame.f_lasti != -1 and not g.gi_running"

Exhausted/closed:
  "g.gi_frame is None"

My API proposal is to add the following to the inspect module:

GEN_CREATED, GEN_RUNNING, GEN_SUSPENDED, GEN_CLOSED = range(4)

def getgeneratorstate(g):
  if g.gi_running:
    return GEN_RUNNING
  if g.gi_frame is None:
    return GEN_CLOSED
  if g.gi_frame.f_lasti == -1:
    return GEN_CREATED
  return GEN_SUSPENDED

(the lack of underscores in the function name follows the general style of the inspect module)

----------
components: Library (Lib)
keywords: easy
messages: 119774
nosy: ncoghlan
priority: normal
severity: normal
stage: needs patch
status: open
title: Make generator state easier to introspect
type: feature request
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Thu Oct 28 14:55:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 12:55:13 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1288270513.75.0.411536303265.issue10220@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is it CPython-specific?
Does "currently executing" also include "currently closing"?

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:05:10 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Thu, 28 Oct 2010 13:05:10 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288270513.75.0.411536303265.issue10220@psf.upfronthosting.co.za>
Message-ID: <AANLkTinq_L813DY680ho9t+2sfdX9bCvZvKqd46zqbg1@mail.gmail.com>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

On Thu, Oct 28, 2010 at 10:55 PM, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Is it CPython-specific?

The states are not CPython-specific (they're logical states of the
underlying generator), but I don't know if other implementations
expose generator and frame details in the same way (all the more
reason to put this in inspect - other implementations can provide the
information without needing to exactly mimic gi_frame and f_lasti).

> Does "currently executing" also include "currently closing"?

"Currently executing" means the frame is being evaluated in a Python
thread (the thread running it may be suspended in a multi-threaded
environment, but the frame itself is in the middle of doing something,
which may include processing a thrown in GeneratorExit)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:25:26 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Thu, 28 Oct 2010 13:25:26 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288272326.17.0.0137997619671.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

All fixed now. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:26:42 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 28 Oct 2010 13:26:42 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>


New submission from Dirkjan Ochtman <dirkjan at ochtman.nl>:

djc at miles ~ $ python2.7
Python 2.7 (r27:82500, Oct  4 2010, 10:01:41)
[GCC 4.3.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> {}.pop('a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'pop(): dictionary is empty'
>>> {'a': 'b'}.pop('c')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
KeyError: 'c'

IMO the former exception should be in line with normal KeyErrors.

----------
messages: 119778
nosy: djc
priority: normal
severity: normal
status: open
title: {}.pop('a') raises non-standard KeyError exception

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10221>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:27:04 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 28 Oct 2010 13:27:04 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288272424.72.0.197140587354.issue10221@psf.upfronthosting.co.za>


Changes by Dirkjan Ochtman <dirkjan at ochtman.nl>:


----------
components: +Interpreter Core
versions: +Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10221>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:37:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 13:37:18 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288273038.34.0.244825369638.issue10221@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +rhettinger
type:  -> behavior
versions: +Python 3.2 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10221>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:38:08 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 28 Oct 2010 13:38:08 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1288272326.17.0.0137997619671.issue6715@psf.upfronthosting.co.za>
Message-ID: <4CC97CBC.3040804@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> All fixed now. :)

Does that refer to msg119743? Please provide this module
as a patch for branches/py3k, otherwise it's difficult to see
what exactly you are contributing.

Also, please provide Doc/library/lzma.rst.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:49:03 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 28 Oct 2010 13:49:03 +0000
Subject: [issue6103] Static library (libpythonX.Y.a) installed in incorrect
	location
In-Reply-To: <1243229174.04.0.856181043806.issue6103@psf.upfronthosting.co.za>
Message-ID: <1288273743.14.0.0143288068001.issue6103@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/issue6103>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:50:22 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Oct 2010 13:50:22 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288273822.48.0.791725804438.issue7351@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

A ?BadZipZile? in the patch made it to Subversion :)  Fixed in r85891.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:50:24 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 13:50:24 +0000
Subject: [issue6103] Static library (libpythonX.Y.a) installed in incorrect
	location
In-Reply-To: <1243229174.04.0.856181043806.issue6103@psf.upfronthosting.co.za>
Message-ID: <1288273824.9.0.606803146177.issue6103@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +barry, loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6103>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:52:11 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Oct 2010 13:52:11 +0000
Subject: [issue10212] struct.unpack and cStringIO.StringIO don't support new
	buffer
In-Reply-To: <1288175813.33.0.0310491559114.issue10212@psf.upfronthosting.co.za>
Message-ID: <1288273931.59.0.425501771585.issue10212@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

MAL?s viewpoint from msg119721:

?The memoryview object was added to simplify porting applications to Python3. If that backport is incomplete in the sense that the memoryview object is not compatible with the standard Python2 object for such memory views, then I'd consider that a bug.

Without compatibility to the buffer objects, there's no way to make other Python2 buffer interface compatible object compatible to memoryviews.

Alternatively, the Python2 memoryview object implementation could also accept objects with the old buffer interface, much like "s*" does.

Note that the patch needs to check the buffer flags - writing to such buffers is not allowed.?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10212>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:53:01 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Oct 2010 13:53:01 +0000
Subject: [issue10212] struct.unpack and cStringIO.StringIO don't support new
	buffer
In-Reply-To: <1288175813.33.0.0310491559114.issue10212@psf.upfronthosting.co.za>
Message-ID: <1288273981.68.0.873028527171.issue10212@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/issue10212>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:53:12 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Oct 2010 13:53:12 +0000
Subject: [issue10211] BufferObject doesn't support new buffer interface
In-Reply-To: <1288169352.49.0.219368546772.issue10211@psf.upfronthosting.co.za>
Message-ID: <1288273992.54.0.771064339195.issue10211@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/issue10211>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:54:35 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 28 Oct 2010 13:54:35 +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: <1288274075.62.0.596962833867.issue6731@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/issue6731>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:57:08 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Oct 2010 13:57:08 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288274228.89.0.439024753285.issue7351@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks for the catch!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 15:59:00 2010
From: report at bugs.python.org (Dirkjan Ochtman)
Date: Thu, 28 Oct 2010 13:59:00 +0000
Subject: [issue1222585] C++ compilation support for distutils
Message-ID: <1288274340.28.0.946180894758.issue1222585@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/issue1222585>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:00:08 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 28 Oct 2010 14:00:08 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1288248168.0.0.71876341517.issue7351@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=8Ek98PF_7f3OzC_jk9nJAycWBkTBXcAZSMX2n@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Is the trailing whitespace problem solved? Please make sure everything is
correct and that no more typos occur for this issue. And I am the original
patch author, so mention my name (Bo??tjan Mejak) in the NEWS file. Thanks.

On Thu, Oct 28, 2010 at 8:42 AM, Georg Brandl <report at bugs.python.org>wrote:

>
> Georg Brandl <georg at python.org> added the comment:
>
> Applied after review in r85874. (Please make sure your patches don't have
> trailing whitespace.)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7351>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19397/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________
-------------- next part --------------
Is the trailing whitespace problem solved? Please make sure everything is correct and that no more typos occur for this issue. And I am the original patch author, so mention my name (Bo??tjan Mejak) in the NEWS file. Thanks.<br>
<br><div><br><div class="gmail_quote">On Thu, Oct 28, 2010 at 8:42 AM, Georg Brandl <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org" target="_blank">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br>
Georg Brandl &lt;<a href="mailto:georg at python.org" target="_blank">georg at python.org</a>&gt; added the comment:<br>
<br>
</div>Applied after review in r85874. (Please make sure your patches don&#39;t have trailing whitespace.)<br>
<br>
----------<br>
<div><div></div><div><br>
_______________________________________<br>
Python tracker &lt;<a href="mailto:report at bugs.python.org" target="_blank">report at bugs.python.org</a>&gt;<br>
&lt;<a href="http://bugs.python.org/issue7351" target="_blank">http://bugs.python.org/issue7351</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br>
</div>

From report at bugs.python.org  Thu Oct 28 16:02:54 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Oct 2010 14:02:54 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288274574.54.0.0290599148249.issue7351@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19388/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:02:58 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Oct 2010 14:02:58 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288274578.22.0.613422672619.issue7351@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19397/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:05:47 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Oct 2010 14:05:47 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288274747.79.0.467729606416.issue7351@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

a) I already removed the whitespace before committing.  The pre-commit hook wouldn't even allow committing that.

b) I don't think constant refusal to submit a patch in the way we request earns you a place in the acknowledgements.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:05:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Oct 2010 14:05:59 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288274759.03.0.174585792515.issue7351@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> Is the trailing whitespace problem solved?
You can follow the link to the revision to see that it is.  Georg?s message implied this, too.

> Please make sure everything is correct and that no more typos occur for this issue.
We do.

> And I am the original patch author, so mention my name (Bo?tjan Mejak) in the NEWS file. Thanks.
We don?t add names for very small patches like this one.

(P.S. Would you be so kind as to follow some netiquette in the tracker?  HTML email creates noisy unnamed attachments, and top-posting is redundant and hard to read.  Thanks in advance.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:11:01 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Thu, 28 Oct 2010 14:11:01 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1288275061.82.0.0467937594368.issue10116@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

New patch, sans trailing whitespace. Ahem.

----------
Added file: http://bugs.python.org/file19398/issue10116-nowhitespace.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:11:07 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Thu, 28 Oct 2010 14:11:07 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1288275067.85.0.539968333807.issue10116@psf.upfronthosting.co.za>


Changes by Stephen Hansen <me+python at ixokai.io>:


Removed file: http://bugs.python.org/file19390/issue10116.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:11:48 2010
From: report at bugs.python.org (=?utf-8?q?Bo=C5=A1tjan_Mejak?=)
Date: Thu, 28 Oct 2010 14:11:48 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1288274759.03.0.174585792515.issue7351@psf.upfronthosting.co.za>
Message-ID: <AANLkTinYzCfBPtyGXdNLxn8f_RxTRZy9ZtdGZ5g-AFnR@mail.gmail.com>


Bo??tjan Mejak <bostjan.mejak at gmail.com> added the comment:

Then disable the tracker's ability to post messages via POP/IMAP. Just block
those protocols in the tracker and you won't see any gibberish anymore. ;)

On Thu, Oct 28, 2010 at 4:05 PM, ??ric Araujo <report at bugs.python.org> wrote:

>
> ??ric Araujo <merwok at netwok.org> added the comment:
>
> > Is the trailing whitespace problem solved?
> You can follow the link to the revision to see that it is.  Georg???s message
> implied this, too.
>
> > Please make sure everything is correct and that no more typos occur for
> this issue.
> We do.
>
> > And I am the original patch author, so mention my name (Bo??tjan Mejak) in
> the NEWS file. Thanks.
> We don???t add names for very small patches like this one.
>
> (P.S. Would you be so kind as to follow some netiquette in the tracker?
>  HTML email creates noisy unnamed attachments, and top-posting is redundant
> and hard to read.  Thanks in advance.)
>
> ----------
>
> _______________________________________
> Python tracker <report at bugs.python.org>
> <http://bugs.python.org/issue7351>
> _______________________________________
>

----------
Added file: http://bugs.python.org/file19399/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________
-------------- next part --------------
Then disable the tracker&#39;s ability to post messages via POP/IMAP. Just block those protocols in the tracker and you won&#39;t see any gibberish anymore. ;)<br><br><div><br><div class="gmail_quote">On Thu, Oct 28, 2010 at 4:05 PM, ??ric Araujo <span dir="ltr">&lt;<a href="mailto:report at bugs.python.org">report at bugs.python.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
??ric Araujo &lt;<a href="mailto:merwok at netwok.org">merwok at netwok.org</a>&gt; added the comment:<br>
<div class="im"><br>
&gt; Is the trailing whitespace problem solved?<br>
</div>You can follow the link to the revision to see that it is. ??Georg???s message implied this, too.<br>
<div class="im"><br>
&gt; Please make sure everything is correct and that no more typos occur for this issue.<br>
</div>We do.<br>
<br>
&gt; And I am the original patch author, so mention my name (Bo??tjan Mejak) in the NEWS file. Thanks.<br>
We don???t add names for very small patches like this one.<br>
<br>
(P.S. Would you be so kind as to follow some netiquette in the tracker? ??HTML email creates noisy unnamed attachments, and top-posting is redundant and hard to read. ??Thanks in advance.)<br>
<div><div></div><div class="h5"><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/issue7351" target="_blank">http://bugs.python.org/issue7351</a>&gt;<br>
_______________________________________<br>
</div></div></blockquote></div><br></div>

From report at bugs.python.org  Thu Oct 28 16:14:18 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Thu, 28 Oct 2010 14:14:18 +0000
Subject: [issue7351] Rename BadZipfile to BadZipFile for consistency
In-Reply-To: <1258571555.95.0.0442517354263.issue7351@psf.upfronthosting.co.za>
Message-ID: <1288275258.42.0.869710653444.issue7351@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19399/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7351>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:14:35 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 28 Oct 2010 14:14:35 +0000
Subject: [issue10202] ftplib doesn't check close status after sending file
In-Reply-To: <1288143542.6.0.0120996379651.issue10202@psf.upfronthosting.co.za>
Message-ID: <4CC98545.6090401@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Proper behavior for ftplib when sending is to send all desired data,
> then call "sock.shutdown(socket.SHUT_RDWR)".  This indicates that no
> more data will be sent, and blocks until the receiver has
> acknowledged all their data.

I think you misunderstand. Calling shutdown does *not* block
until the receiver has acknowledged all data. It just put a
FIN packet into the send queue.

> FTP send is one of the few situations where this matters, because FTP
> uses the close of the data connection to indicate EOF.

Not only. It also uses the server response on the control connection
to indicate that all data has been received. Relying on successful
shutdown is both insufficient and unnecessary.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10202>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:18:13 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 14:18:13 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1288275493.24.0.280475171584.issue10116@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage: committed/rejected -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:22:30 2010
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 28 Oct 2010 14:22:30 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288275750.42.0.304632160235.issue10221@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/issue10221>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:32:05 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 28 Oct 2010 14:32:05 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288276324.99.0.797654989898.issue10209@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'd like to see this patch reverted. I don't think it is useful.

1. encoding with NFD should not be necessary, as the system will do that, anyway.
2. decoding with NFC is incompatible with previous Python releases, and I can't see why NFC is conceptually better than NFD.

To give an analogy: if we have a case-insensitive file system, we don't normalize into lower-case, either, do we?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:35:11 2010
From: report at bugs.python.org (R. David Murray)
Date: Thu, 28 Oct 2010 14:35:11 +0000
Subject: [issue10213] tests shouldn't fail with unset timezone
In-Reply-To: <1288180286.09.0.61662115749.issue10213@psf.upfronthosting.co.za>
Message-ID: <1288276511.1.0.221317365469.issue10213@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Indeed, Factory is part of the standard tz (zoneinfo) database, as can be seen on this web page that makes the database browsable:

http://twiki.org/cgi-bin/xtra/tzdatepick.html

Whether or not a distribution uses Factory initially is of course a distribution decision, but for our purposes we can consider that message to be a constant provided by upstream that indicates there is no valid timezone to test.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10213>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:47:04 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 28 Oct 2010 14:47:04 +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: <1288277224.6.0.603882794202.issue9981@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why is the second parameter optional?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9981>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:53:26 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 14:53:26 +0000
Subject: [issue9295] test_close_open_print_buffered(test_file) sometimes
	crashes
In-Reply-To: <1279465176.3.0.233257918018.issue9295@psf.upfronthosting.co.za>
Message-ID: <1288277606.4.0.111141908721.issue9295@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Hirokazu, I've committed your 2.7 patch in r85892. Let's see what the buildbots say.

----------
resolution:  -> fixed
status: open -> pending
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9295>
_______________________________________

From report at bugs.python.org  Thu Oct 28 16:55:31 2010
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Oct 2010 14:55:31 +0000
Subject: [issue10116] Sporadic failures in test_urllibnet
In-Reply-To: <1287150282.16.0.127032822399.issue10116@psf.upfronthosting.co.za>
Message-ID: <1288277731.89.0.724568252135.issue10116@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Let's try with the patch. r85893.

(I'm afraid the pre-commit hook still rejected the file after applying the patch.)

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> pending

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10116>
_______________________________________

From report at bugs.python.org  Thu Oct 28 17:01:56 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Oct 2010 15:01:56 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288278116.28.0.203822885088.issue10209@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I'd like to see this patch reverted.

I created a specific branch to test the patch (I also patched PyUnicode_EncodeFSDefault() and PyUnicode_DecodeFSDefaultAndSize()): issue10209. test_pep277 now pass in this branch!

> encoding with NFD should not be necessary, as the system will 
> do that, anyway.

Yes, but not exactly... Mac OS X NFD normalization is a little bit different than Python's normalization: see msg105669 and
http://developer.apple.com/library/mac/#qa/qa2001/qa1173.html

I don't understand why test_pep277 pass on issue10209 branch, but it works. I suppose that normalize the filename to NFD in Python avoids some Mac OS X normalization bugs?

> decoding with NFC is incompatible with previous Python releases,
> I can't see why NFC is conceptually better than NFD.

I propose to normalize to NFC because Qt does that.

On Linux, the keyboard uses NFC. Eg. press ? key writes U+00e9, not U+0065 U+0301. If you ask the user to write a filename, the filename will be stored in the same norm. So indirectly, Linux stores filenames as NFC.

Which norm is used on Mac OS X, eg. for the keyboard?

To display a filename, the norm is not important. With my patch, the norm is also no more important when accessing to the filesystem (no more strange Mac OS X normalization bug). So it's only important when comparing two filenames. If the two filenames are normalized in different norms (eg. NFC vs NFD), they will be seen as different even if they are the same name.

--

Anyway, I think that os.fsencode(os.fsdecode(name)) should be equal to name. If it's different, "open(name, 'w').close(); name in listdir()" is False (on systems storing filenames as bytes). So if you change fsdecode(), fsencode() should also be changed.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Thu Oct 28 17:04:35 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 28 Oct 2010 15:04:35 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1288278275.24.0.0982899252355.issue10220@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I could imagine separating the state into two parts:

- a three-valued enum distinguishing created, active, or exhausted

- a bool (only relevant in the active state) whether it is currently running or suspended

The latter is just g.gi_running so we don't need a new API for this. :-)

----------
nosy: +gvanrossum

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Thu Oct 28 17:44:28 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Oct 2010 15:44:28 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288280668.88.0.900832112461.issue10221@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

There have been several requests for KeyError to grow "key" attribute that will always contain the key that caused the error. See issue 1182143, for example.  If this is done, I think it would be natural to unify the args as well for empty and non-empy case.  Without adding key access API, however, I am at most -0 on changing the error message.   Traditionally, the error messages are not considered part of language specification, so this is not a bug.

----------
nosy: +belopolsky
type: behavior -> feature request
versions:  -Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10221>
_______________________________________

From report at bugs.python.org  Thu Oct 28 17:52:09 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Oct 2010 15:52:09 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288281129.53.0.273183543541.issue10209@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Some pointers.

"MacFUSE"
http://code.google.com/p/macfuse/issues/detail?id=139#c2

"FILENAME_ENCODING_PROPOSAL" (MacFUSE)
http://code.google.com/p/macfuse/wiki/FILENAME_ENCODING_PROPOSAL

"Converting to Precomposed Unicode"
http://developer.apple.com/library/mac/#qa/qa2001/qa1235.html

"Unicode NFD and file attachment on Mac OS X" (filenames of email attachments)
http://lists.w3.org/Archives/Public/www-international/2003OctDec/0079.html
extract: " the applications dealing with these files names should convert it to NFC before sending it to the wire."

"Bug: TWiki on Mac OS X server with I18N generates odd looking file names"
http://twiki.org/cgi-bin/view/Codev/MacOSXFilesystemEncodingWithI18N
(search "NFD" or "HFS+")

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Thu Oct 28 18:11:42 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Thu, 28 Oct 2010 16:11:42 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288278116.28.0.203822885088.issue10209@psf.upfronthosting.co.za>
Message-ID: <4CC9A0BA.209@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Yes, but not exactly... Mac OS X NFD normalization is a little bit
> different than Python's normalization: see msg105669 and 
> http://developer.apple.com/library/mac/#qa/qa2001/qa1173.html

I see. This is one more reason not to convert strings into NFD, no?

> I don't understand why test_pep277 pass on issue10209 branch, but it
> works. I suppose that normalize the filename to NFD in Python avoids
> some Mac OS X normalization bugs?

My question is rather why it failed in the first place, when issue8207
had supposedly fixed it.

> I propose to normalize to NFC because Qt does that.

Hmm. I find that a weak argument - in particular given that the
system will normalize then in turn anyway, and to a slightly different
normalform. So what is Qt's motivation to normalize?

> On Linux, the keyboard uses NFC.

I think this is technically incorrect. When you press ?, then some
scan code is generated. That goes through various mapping layers.
The outcome will depend on how specifically these layers are
configured.

> Which norm is used on Mac OS X, eg. for the keyboard?

Same reasoning: pressing a key initially does not generate any Unicode
at all. My guess is that when eventually a character is generated
(e.g. on the terminal), no normal form is used; instead, it most likely
will always strive to generate a single character (even if that is not
normalized). See

http://developer.apple.com/library/mac/#qa/qa2001/qa1235.html

which says "Macintosh keyboards generally produce precomposed Unicode"

> Anyway, I think that os.fsencode(os.fsdecode(name)) should be equal
> to name.

I agree. and that is currently already the case.

> If it's different, "open(name, 'w').close(); name in
> listdir()" is False (on systems storing filenames as bytes). So if
> you change fsdecode(), fsencode() should also be changed.

I'm saying that fsdecode shouldn't change, either, the primary reason
being backwards compatibility here.

----------
title: Mac OS X: Decompose filenames on encode, and precompose filenames on decode -> Mac OS X: Decompose filenames on encode,	and precompose filenames on decode

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Thu Oct 28 18:13:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 16:13:17 +0000
Subject: [issue9295] test_close_open_print_buffered(test_file) sometimes
	crashes
In-Reply-To: <1279465176.3.0.233257918018.issue9295@psf.upfronthosting.co.za>
Message-ID: <1288282397.79.0.357902686291.issue9295@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Apparently it's fixed!

----------
stage: needs patch -> committed/rejected
status: pending -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9295>
_______________________________________

From report at bugs.python.org  Thu Oct 28 18:14:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 16:14:30 +0000
Subject: [issue10207] test_file2k crashes under Windows
In-Reply-To: <1288131625.06.0.246375636536.issue10207@psf.upfronthosting.co.za>
Message-ID: <1288282470.84.0.942775784429.issue10207@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the aforementioned patch (r85892) and this seems to be fixed. Thank you!

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10207>
_______________________________________

From report at bugs.python.org  Thu Oct 28 18:18:31 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Oct 2010 16:18:31 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288282711.02.0.0737628258261.issue10209@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> My question is rather why it failed in the first place, 
> when issue8207 had supposedly fixed it.

r79426 (of #8207) only disabled some tests.

The problem with test_normalize() and test_listdir() of test_pep277 is maybe that these tests are irrevelant on Mac OS X?

I still don't understand exaclty why the tests fail and what the tests do check.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Thu Oct 28 18:37:52 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 28 Oct 2010 16:37:52 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288283872.68.0.20059652253.issue10221@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I agree with the OP's request.

d.pop(k) is conceptually equivalent to:
   r = d[k]    # raises KeyError(k)
   del d[k]
   return r

The current message was probably borrowed from dict.popitem().  But that is much different since the dict.pop(k) method is key-specific (instead of size related).

This fix should be backported (as it doesn't change guaranteed behaviors but does improve the debugability).

----------
assignee:  -> rhettinger
stage:  -> needs patch
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10221>
_______________________________________

From report at bugs.python.org  Thu Oct 28 18:38:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 28 Oct 2010 16:38:09 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288283889.13.0.372920389564.issue10221@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/issue10221>
_______________________________________

From report at bugs.python.org  Thu Oct 28 18:55:57 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Oct 2010 16:55:57 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288284957.49.0.117969237374.issue10221@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This is the case where fixing an issue is easier than arguing that it is not a bug. :-)  (Changing to "behavior" not because I agree that it is a bug, but for consistency with targeting 2.7)

A (1-line) patch attached.

----------
keywords: +patch
stage: needs patch -> unit test needed
type: feature request -> behavior
Added file: http://bugs.python.org/file19400/issue10221.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10221>
_______________________________________

From report at bugs.python.org  Thu Oct 28 19:07:59 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Oct 2010 17:07:59 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288285679.75.0.994693088808.issue10221@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attaching a patch with tests.

----------
keywords: +needs review
resolution:  -> accepted
stage: unit test needed -> commit review
Added file: http://bugs.python.org/file19401/issue10221-with-tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10221>
_______________________________________

From report at bugs.python.org  Thu Oct 28 19:21:24 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Oct 2010 17:21:24 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288286484.16.0.875129861744.issue10221@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I wonder if it would be worthwhile to unify missing key processing as in issue10221a-with-tests.diff.

----------
Added file: http://bugs.python.org/file19402/issue10221a-with-tests.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10221>
_______________________________________

From report at bugs.python.org  Thu Oct 28 19:41:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 17:41:35 +0000
Subject: [issue5437] Singleton MemoryError can hold traceback data and locals
	indefinitely
In-Reply-To: <1236475192.44.0.322213447469.issue5437@psf.upfronthosting.co.za>
Message-ID: <1288287695.33.0.0812127020185.issue5437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Updated patch against py3k.

----------
Added file: http://bugs.python.org/file19403/memerror.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5437>
_______________________________________

From report at bugs.python.org  Thu Oct 28 19:58:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 17:58: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: <1288288709.46.0.157026087341.issue10038@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

+1 for fixing this in-tree. We need a patch, though ;)

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10038>
_______________________________________

From report at bugs.python.org  Thu Oct 28 21:19:28 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 28 Oct 2010 19:19:28 +0000
Subject: [issue8332] regrtest single TestClass/test_method
In-Reply-To: <1270631958.05.0.652340331128.issue8332@psf.upfronthosting.co.za>
Message-ID: <1288293568.43.0.305481513961.issue8332@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
as explained in msg108109 (of issue9028) you can actually call a single test, or a single TestClass:

$ ./python -m unittest test.test_httpservers.BaseHTTPServerTestCase.test_handler
.
----------------------------------------------------------------------
Ran 1 test in 0.168s

OK
$ ./python -m unittest test.test_httpservers.BaseHTTPServerTestCase
..............
----------------------------------------------------------------------
Ran 14 tests in 1.132s

OK

I'm closing this report, but feel free to reopen it if you think I'm missing something.

Thanks,
Sandro

----------
nosy: +sandro.tosi
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8332>
_______________________________________

From report at bugs.python.org  Thu Oct 28 21:44:14 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Thu, 28 Oct 2010 19:44:14 +0000
Subject: [issue10222] 3.2 on AIX -  Unexpected text ',' encountered.
In-Reply-To: <1288295054.95.0.251729908149.issue10222@psf.upfronthosting.co.za>
Message-ID: <1288295054.95.0.251729908149.issue10222@psf.upfronthosting.co.za>


New submission from Sridhar Ratnakumar <sridharr at activestate.com>:

"Parser/tokenizer.h", line 18.17: 1506-275 (S) Unexpected text ',' encountered.

http://svn.python.org/view/python/branches/py3k/Parser/tokenizer.h?annotate=76232#l16

Extra comma in the following line:

  STATE_NORMAL, /* have a codec associated with input */

Introduced by neil.schem in r58226

----------
components: Build
messages: 119809
nosy: nascheme, srid
priority: normal
severity: normal
status: open
title: 3.2 on AIX -  Unexpected text ',' encountered.
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10222>
_______________________________________

From report at bugs.python.org  Thu Oct 28 21:57:33 2010
From: report at bugs.python.org (Jeremy Kloth)
Date: Thu, 28 Oct 2010 19:57:33 +0000
Subject: [issue10217] python-2.7.amd64.msi install fails
In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>
Message-ID: <1288295853.43.0.273374949583.issue10217@psf.upfronthosting.co.za>


Changes by Jeremy Kloth <jeremy.kloth at gmail.com>:


----------
nosy: +jkloth

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10217>
_______________________________________

From report at bugs.python.org  Thu Oct 28 22:08:53 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 28 Oct 2010 20:08:53 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288296533.48.0.987809790561.issue10221@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
resolution: accepted -> 
stage: commit review -> patch review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10221>
_______________________________________

From report at bugs.python.org  Thu Oct 28 22:10:31 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 28 Oct 2010 20:10:31 +0000
Subject: [issue6661] Transient test_multiprocessing failure
	(test_active_children)
In-Reply-To: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>
Message-ID: <1288296631.01.0.855638844426.issue6661@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
what can we do with this issue? It doesn't seem it happened again after Antoine's report (or at least no-one had followed it up) and it doesn't happen nowdays (f.e. I exec'd test_multiprocessing in a loop for some time, and no error comes).

What do you think about closing it as "sorry, unable to replicate it" and so mark it a glitch somehow?

----------
nosy: +sandro.tosi

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6661>
_______________________________________

From report at bugs.python.org  Thu Oct 28 22:11:41 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 28 Oct 2010 20:11:41 +0000
Subject: [issue10186] Invalid SyntaxError pointer offset
In-Reply-To: <1287877325.31.0.208364473897.issue10186@psf.upfronthosting.co.za>
Message-ID: <1288296701.07.0.655927369703.issue10186@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

Hi, I've problems with two recent commits (r85814 and r85817):


Example:

r85812 is ok:
==============

Python 3.2a3+ (py3k:85812:85835M, Oct 28 2010, 22:02:19) 
[GCC 4.2.4 (Ubuntu 4.2.4-3ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 5 | 4 |
  File "<stdin>", line 1
    x = 5 | 4 |
              ^
SyntaxError: invalid syntax
>>> 



r85814 does not give the intended output:
==========================================

Python 3.2a3+ (py3k:85814:85835M, Oct 28 2010, 22:03:06) 
[GCC 4.2.4 (Ubuntu 4.2.4-3ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 5 | 4 |
  File "<stdin>", line 1
    
    ^
SyntaxError: invalid syntax
>>> 


r85817 goes into an "infinite" loop. The last one is obvious;
offset is 0, so the while loop does not stop.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10186>
_______________________________________

From report at bugs.python.org  Thu Oct 28 22:11:57 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 28 Oct 2010 20:11:57 +0000
Subject: [issue10186] Invalid SyntaxError pointer offset
In-Reply-To: <1287877325.31.0.208364473897.issue10186@psf.upfronthosting.co.za>
Message-ID: <1288296717.79.0.373458873659.issue10186@psf.upfronthosting.co.za>


Changes by Stefan Krah <stefan-usenet at bytereef.org>:


----------
resolution: fixed -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10186>
_______________________________________

From report at bugs.python.org  Thu Oct 28 22:14:58 2010
From: report at bugs.python.org (Stefan Krah)
Date: Thu, 28 Oct 2010 20:14:58 +0000
Subject: [issue6661] Transient test_multiprocessing failure
	(test_active_children)
In-Reply-To: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>
Message-ID: <1288296898.85.0.748298766711.issue6661@psf.upfronthosting.co.za>


Stefan Krah <stefan-usenet at bytereef.org> added the comment:

I've seen that one as well, but very rarely.

----------
nosy: +skrah

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6661>
_______________________________________

From report at bugs.python.org  Thu Oct 28 22:22:55 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Thu, 28 Oct 2010 20:22:55 +0000
Subject: [issue6661] Transient test_multiprocessing failure
	(test_active_children)
In-Reply-To: <1249589448.92.0.976190766506.issue6661@psf.upfronthosting.co.za>
Message-ID: <1288297375.54.0.256464491386.issue6661@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

well, at least we have a confirmation it's still there :)

any idea how we can try to debug it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6661>
_______________________________________

From report at bugs.python.org  Thu Oct 28 22:30:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Oct 2010 20:30:55 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288297855.48.0.580918345272.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Attaching another small doc improvement: "gon" is better know as "grad" and even under that name requires an explanation. See issue7061a.diff

----------
Added file: http://bugs.python.org/file19404/issue7061a.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Thu Oct 28 22:31:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Oct 2010 20:31:15 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288297875.81.0.605780040381.issue7061@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
stage: committed/rejected -> commit review

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Fri Oct 29 00:10:00 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Thu, 28 Oct 2010 22:10:00 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288303800.83.0.235702414183.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

Here's a patch with the latest code generated against py3k branch, it comes with Doc/library/lzma.rst as well now.

----------
keywords: +patch
Added file: http://bugs.python.org/file19405/py3k-lzmamodule.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Oct 29 00:10:51 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Thu, 28 Oct 2010 22:10:51 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288303851.75.0.0653932836942.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

here's Lib/test/teststring.lzma, required by the test suite.

----------
Added file: http://bugs.python.org/file19406/teststring.lzma

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Oct 29 00:11:19 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Thu, 28 Oct 2010 22:11:19 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288303879.52.0.728090929249.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

here's Lib/test/teststring.xz, required by the test suite.

----------
Added file: http://bugs.python.org/file19407/teststring.xz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Oct 29 00:13:09 2010
From: report at bugs.python.org (EcmaXp)
Date: Thu, 28 Oct 2010 22:13:09 +0000
Subject: [issue10223] socket.gethostname() fail
In-Reply-To: <1288303989.88.0.633861339057.issue10223@psf.upfronthosting.co.za>
Message-ID: <1288303989.88.0.633861339057.issue10223@psf.upfronthosting.co.za>


New submission from EcmaXp <admin at ecmaxp.pe.kr>:

C:\Users\PC-\Desktop>c:\python31\python
Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on
win32
Type ?help?, ?copyright?, ?credits? or ?license? for more information.
>>> import socket
>>> socket.gethostname()
Traceback (most recent call last):
  File ?<stdin>?, line 1, in <module>
UnicodeDecodeError: ?utf8? codec can?t decode bytes in position 0-1: invalid data
>>>

socket.gethostname() fail when system name is korean on Window Vista

[...

----------
components: Library (Lib)
messages: 119818
nosy: EcmaXp
priority: normal
severity: normal
status: open
title: socket.gethostname() fail
type: crash
versions: Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10223>
_______________________________________

From report at bugs.python.org  Fri Oct 29 00:16:42 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Oct 2010 22:16:42 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Opening a ticket to track the progress of getting python 3.x build its own documentation.

So far I have installed Sphinx from http://bitbucket.org/birkenfeld/sphinx, but I get the following error:

$ sphinx-build -b html -d Doc/build3/doctrees -D latex_paper_size=  Doc  Doc/build3/html


There is a syntax error in your configuration file: invalid syntax (patchlevel.py, line 71)
Did you change the syntax from 2.x to 3.x?

----------
messages: 119819
nosy: belopolsky
priority: normal
severity: normal
status: open
title: Build 3.x documentation using python3.x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 00:17:57 2010
From: report at bugs.python.org (EcmaXp)
Date: Thu, 28 Oct 2010 22:17:57 +0000
Subject: [issue10223] socket.gethostname() fail
In-Reply-To: <1288303989.88.0.633861339057.issue10223@psf.upfronthosting.co.za>
Message-ID: <1288304277.48.0.549434109207.issue10223@psf.upfronthosting.co.za>


EcmaXp <admin at ecmaxp.pe.kr> added the comment:

http://bugs.python.org/issue9377

----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10223>
_______________________________________

From report at bugs.python.org  Fri Oct 29 00:29:14 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Oct 2010 22:29:14 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288304954.53.0.103811946905.issue10224@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
nosy: +eric.araujo, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 00:29:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Oct 2010 22:29:53 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288304993.21.0.125594867693.issue10224@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
assignee:  -> docs at python
components: +Build, Documentation
nosy: +docs at python
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 00:39:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 28 Oct 2010 22:39:07 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288305547.24.0.704150467458.issue10224@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I had some success after running 2to3 on Doc/conf.py and Doc/tools.  The build succeeded, but I have not compared the output yet.  Running doctest, however, still reported lots of errors and hang in turtle.rst. 

$ sphinx-build -b doctest -d Doc/build3/doctrees -D latex_paper_size=  Doc  Doc/build3/html

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 00:41:17 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 22:41:17 +0000
Subject: [issue5437] Singleton MemoryError can hold traceback data and locals
	indefinitely
In-Reply-To: <1236475192.44.0.322213447469.issue5437@psf.upfronthosting.co.za>
Message-ID: <1288305677.05.0.346288647945.issue5437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I can't manage to reproduce the issue with PyExc_RecursionErrorInst. It seems this instance is only used in a very select condition, that is, when the recursion limit is hit when trying to "normalize" an exception. Therefore, I will add a test without "fixing" anything.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5437>
_______________________________________

From report at bugs.python.org  Fri Oct 29 01:07:27 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 23:07:27 +0000
Subject: [issue5437] Singleton MemoryError can hold traceback data and locals
	indefinitely
In-Reply-To: <1236475192.44.0.322213447469.issue5437@psf.upfronthosting.co.za>
Message-ID: <1288307247.56.0.0917116182389.issue5437@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Patch with improved tests committed in r85896 (3.2) and r85898 (3.1).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5437>
_______________________________________

From report at bugs.python.org  Fri Oct 29 01:15:33 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 23:15:33 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1288307733.86.0.779989564751.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I would need opinions on one more thing. The current patch warns when a socket has not been explicitly closed. But it does so even when the socket isn't bound at all. e.g.:

$ ./python -c "import socket; socket.socket()"
-c:1: ResourceWarning: unclosed <socket.socket object, fd=3, family=2, type=1, proto=0>

Perhaps we should be more discriminate and only warn when either bind(), listen() or connect() had been called previously? What do you think?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 01:18:16 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Oct 2010 23:18:16 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288307896.16.0.210416858371.issue10209@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> The problem with test_normalize() and test_listdir() of test_pep277
> is maybe that these tests are irrevelant on Mac OS X?

I tried a different approach (different than my patch and the svn branch):
 - r85897 disables the filenames that are normalized differently by Python and by darwin
 - r85899 disables test_normalize and test_listdir tests

Let's watch the buildbots...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Fri Oct 29 01:35:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 23:35:51 +0000
Subject: [issue10217] python-2.7.amd64.msi install fails
In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>
Message-ID: <1288308951.99.0.722778961827.issue10217@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/issue10217>
_______________________________________

From report at bugs.python.org  Fri Oct 29 01:36:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 23:36:12 +0000
Subject: [issue10222] 3.2 on AIX -  Unexpected text ',' encountered.
In-Reply-To: <1288295054.95.0.251729908149.issue10222@psf.upfronthosting.co.za>
Message-ID: <1288308972.95.0.0354725233675.issue10222@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +sable

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10222>
_______________________________________

From report at bugs.python.org  Fri Oct 29 01:37:54 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 28 Oct 2010 23:37:54 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288309074.61.0.821422803106.issue6715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Could you upload the patch to http://codereview.appspot.com/?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Oct 29 01:52:18 2010
From: report at bugs.python.org (STINNER Victor)
Date: Thu, 28 Oct 2010 23:52:18 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288309938.03.0.351953112684.issue10209@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> - r85897 disables the filenames that are normalized differently by Python and by darwin
> - r85899 disables test_normalize and test_listdir tests

It looks like r85897 is enough to fix test_pep277 on "x86 Tiger 3.x" buildbot. But r85899 should not make the situation worse :-)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Fri Oct 29 02:06:51 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Oct 2010 00:06:51 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288310811.69.0.675953325582.issue10209@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

I now agree with Martin: "Mac OS X: Decompose filenames on encode,	and precompose filenames on decode" was a bad idea, fix the test is the right solution.

test_pep277 now pass on "x86 Tiger 3.x" buildbot, and so I can close this issue and issue #8423.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Fri Oct 29 02:08:15 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Oct 2010 00:08:15 +0000
Subject: [issue8423] tiger buildbot: test_pep277 failures
In-Reply-To: <1271435749.81.0.011008649482.issue8423@psf.upfronthosting.co.za>
Message-ID: <1288310895.84.0.0158765515882.issue8423@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

> I opened the issue #10209: "Mac OS X: Decompose filenames on encode, 
> and precompose filenames on decode".

It was a bad idea. I fixed test_pep277 instead with:
 - r85897 disables the filenames that are normalized differently by Python and by darwin
 - r85899 disables test_normalize and test_listdir tests

And test_pep277 now pass on "x86 Tiger 3.x" buildbot, and so I can close this issue (and issue #10209).

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8423>
_______________________________________

From report at bugs.python.org  Fri Oct 29 02:08:37 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Oct 2010 00:08:37 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288310917.51.0.372847398929.issue10209@psf.upfronthosting.co.za>


Changes by STINNER Victor <victor.stinner at haypocalc.com>:


----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Fri Oct 29 02:26:04 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 29 Oct 2010 00:26:04 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1288311964.34.0.620278625513.issue10220@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

So something like:

GEN_CREATED, GEN_ACTIVE, GEN_CLOSED = range(3)

def getgeneratorstate(g):
  """Get current state of a generator-iterator.
  
  Possible states are:
    GEN_CREATED: Created, waiting to start execution
    GEN_ACTIVE: Currently being executed (or suspended at yield)
    GEN_CLOSED: Execution has completed

  Use g.gi_running to determine if an active generator is running or
  is suspended at a yield expression.
  """
  if g.gi_frame is None:
    return GEN_CLOSED
  if g.gi_frame.f_lasti == -1:
    return GEN_CREATED
  return GEN_ACTIVE

Having 4 separate states actually makes the documentation a little easier to write:

def getgeneratorstate(g):
  """Get current state of a generator-iterator.
  
  Possible states are:
    GEN_CREATED: Waiting to start execution
    GEN_RUNNING: Currently being executed by the interpreter
    GEN_SUSPENDED: Currently suspended at a yield expression
    GEN_CLOSED: Execution has completed
  """

Checking if the generator is active is then just a matter of checking "gen_state in (GEN_RUNNING, GEN_SUSPENDED)".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Fri Oct 29 02:26:48 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Oct 2010 00:26:48 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1288312008.44.0.129775752502.issue10093@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If a new, unbound socket uses some form of OS resource, then a warning is needed. Is their an equivalent limitation like there is with file descriptors as to how many an OS can possibly have open at once?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 02:29:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 00:29:43 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1288312008.44.0.129775752502.issue10093@psf.upfronthosting.co.za>
Message-ID: <1288312178.3753.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> If a new, unbound socket uses some form of OS resource, then a warning
> is needed. Is their an equivalent limitation like there is with file
> descriptors as to how many an OS can possibly have open at once?

A socket *is* a file descriptor (under Unix), so, yes, there is a limit.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 02:39:25 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Oct 2010 00:39:25 +0000
Subject: [issue10210] os.get_exec_path() should not produce any warning
In-Reply-To: <1288141086.46.0.441985990964.issue10210@psf.upfronthosting.co.za>
Message-ID: <1288312765.82.0.346537433761.issue10210@psf.upfronthosting.co.za>


STINNER Victor <victor.stinner at haypocalc.com> added the comment:

Fixed by r85902.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10210>
_______________________________________

From report at bugs.python.org  Fri Oct 29 02:43:03 2010
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 29 Oct 2010 00:43:03 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288311964.34.0.620278625513.issue10220@psf.upfronthosting.co.za>
Message-ID: <AANLkTinLjF7FyGRM+=CbbDtkKpOe0iM8gV1K9F_Qz2FQ@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I take it back. The 4-value state looks better.

My initial hesitance was that if you ever see GEN_RUNNING you are
probably already in trouble, since you can't call send, next, throw or
even close on a running generator (they all throw ValueError), so why
are you looking at its state at all? But most reasons for looking at
the state are obscure anyway, and from a different perspective it's a
nice state machine. (Note that there's no transition from SUSPENDED to
CLOSED -- you have to go through RUNNING to possibly handle
GeneratorExit.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Fri Oct 29 02:54:21 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 29 Oct 2010 00:54:21 +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: <1288313661.88.0.316946392154.issue9981@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

For backwards compatibility, say with other build configurations (there is still rudimentary support for VS2005, 2003.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9981>
_______________________________________

From report at bugs.python.org  Fri Oct 29 03:04:28 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Oct 2010 01:04:28 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1288314268.12.0.309822559266.issue8194@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


----------
nosy: +eric.araujo, loewis, orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Fri Oct 29 03:28:40 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 29 Oct 2010 01:28:40 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1288315720.11.0.959117032588.issue10220@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Indeed, the minimal lifecycles are:

GEN_CREATED->GEN_CLOSED (exception thrown in before the generator was even started)
GEN_CREATED->GEN_RUNNING->GEN_CLOSED (initial next() with internal logic that skips all yields)
GEN_CREATED->GEN_RUNNING->GEN_SUSPENDED->GEN_RUNNING->GEN_CLOSED (initial next() with a throw, next or send to close it)

Other cases following the same basic pattern as the last one, they just bounce back and forth between suspended and running more times.

It occurred to me that threads really use the same state machine, it's just that almost nobody writes their own Python thread schedulers, so only _thread and threading care about the suspended/running distinction. There are quite a few different generator schedulers though, so the distinctions matters to more 3rd party code than it does for threads.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Fri Oct 29 03:28:54 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 29 Oct 2010 01:28:54 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1288315734.08.0.00813245909041.issue10220@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
assignee:  -> ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Fri Oct 29 03:50:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Oct 2010 01:50:02 +0000
Subject: [issue10223] socket.gethostname() fail
In-Reply-To: <1288303989.88.0.633861339057.issue10223@psf.upfronthosting.co.za>
Message-ID: <1288317002.23.0.994713642531.issue10223@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
resolution: rejected -> duplicate
stage:  -> committed/rejected
superseder:  -> socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names
type: crash -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10223>
_______________________________________

From report at bugs.python.org  Fri Oct 29 04:00:14 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Oct 2010 02:00:14 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <1288317614.35.0.801926353104.issue9377@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Looks like we have our first customer (issue 10223).

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Fri Oct 29 04:00:58 2010
From: report at bugs.python.org (Anthony Long)
Date: Fri, 29 Oct 2010 02:00:58 +0000
Subject: [issue8194] Incompatible API change in
	xmlrpclib.Transport.parse_response() of Python 2.7 and 3.2
In-Reply-To: <1269199462.82.0.615666977327.issue8194@psf.upfronthosting.co.za>
Message-ID: <1288317658.2.0.287516789145.issue8194@psf.upfronthosting.co.za>


Anthony Long <antlong at gmail.com> added the comment:

Patched my installation of python27 (via macports, snow leopard) and the patch was successful. Verified patch works in a limited capacity, using yolk.

----------
nosy: +antlong

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8194>
_______________________________________

From report at bugs.python.org  Fri Oct 29 04:15:21 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Oct 2010 02:15:21 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1288318521.68.0.924960498775.issue10093@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

That's what I thought. So if socket.socket() alone is enough to consume an fd then there should be a warning.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 04:18:55 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 02:18:55 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

As noted in issue 10224, python 3.x documentation is not being built with python 3.x yet, so a simple cd Doc; make doctest does not work.  However, hg trunk version os sphinx works with python 3.x and can be used to validate examples in ReST documentation.

----------
assignee: belopolsky
components: Documentation
messages: 119840
nosy: belopolsky
priority: normal
severity: normal
stage: needs patch
status: open
title: Fix doctest runable examples in python manual
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Fri Oct 29 04:19:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 02:19:06 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1288318746.83.0.63634162426.issue10225@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
dependencies: +Build 3.x documentation using python3.x

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Fri Oct 29 04:20:50 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Oct 2010 02:20:50 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1288318850.73.0.312135010169.issue10225@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

> hg trunk version [of] sphinx works with python 3.x and can be used to
> validate examples in ReST documentation.

How do you replace ?make doctest??

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Fri Oct 29 04:22:51 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 02:22:51 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318850.73.0.312135010169.issue10225@psf.upfronthosting.co.za>
Message-ID: <AANLkTikWOPVvqce2bV4v-ihPL276E7x7GttcArbv_=dZ@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Oct 28, 2010 at 10:20 PM, ?ric Araujo <report at bugs.python.org> wrote:

>
> How do you replace ?make doctest??

$ sphinx-build -b html -d Doc/build3/doctrees -D latex_paper_size=
Doc  Doc/build3/html

but I had to run 2to3 on Doc/conf.py and Doc/tools first.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Fri Oct 29 04:25:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Oct 2010 02:25:59 +0000
Subject: [issue4032] distutils cannot recognize ".dll.a" as library on cygwin
In-Reply-To: <1223055534.39.0.439061882395.issue4032@psf.upfronthosting.co.za>
Message-ID: <1288319159.59.0.220137573249.issue4032@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Okay, let?s reach a conclusion on the other bug before getting back to this one.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4032>
_______________________________________

From report at bugs.python.org  Fri Oct 29 04:32:45 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Oct 2010 02:32:45 +0000
Subject: [issue10147] Python Documentation bugs
In-Reply-To: <1287515992.96.0.884562024831.issue10147@psf.upfronthosting.co.za>
Message-ID: <1288319565.5.0.62696760445.issue10147@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Marc-Andr?: I do recall it being a grammar rule.  Take for example the difference between the compound noun ?a system call? and the compound noun used as adjective ?system-level? (in ?a system-level call?).

Again, I?m not on a crusade here, just reacting on my gut feeling about a minor change.  I can ask English professors if you want :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10147>
_______________________________________

From report at bugs.python.org  Fri Oct 29 04:33:59 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Oct 2010 02:33:59 +0000
Subject: [issue10147] Python Documentation bugs
In-Reply-To: <1287515992.96.0.884562024831.issue10147@psf.upfronthosting.co.za>
Message-ID: <1288319639.29.0.143157797097.issue10147@psf.upfronthosting.co.za>


Changes by ?ric Araujo <merwok at netwok.org>:


Removed file: http://bugs.python.org/file19333/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10147>
_______________________________________

From report at bugs.python.org  Fri Oct 29 04:53:13 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Oct 2010 02:53:13 +0000
Subject: [issue10191] scripts files are not RECORDed.
In-Reply-To: <1288014947.33.0.874343051999.issue10191@psf.upfronthosting.co.za>
Message-ID: <1288320793.47.0.735320874461.issue10191@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for the report.  This is indeed a bug with respect to PEP 376.

It would be too difficult to modify shutil (and copy2) to make it return filenames, but thanks to the new copy_function hook it will be easy to store filenames in a list and use that.  I?ll have to synchronize _backport.shutil with the 3.2 version first.

----------
assignee: tarek -> eric.araujo
versions: +3rd party -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10191>
_______________________________________

From report at bugs.python.org  Fri Oct 29 05:30:12 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Oct 2010 03:30:12 +0000
Subject: [issue10186] Invalid SyntaxError pointer offset
In-Reply-To: <1287877325.31.0.208364473897.issue10186@psf.upfronthosting.co.za>
Message-ID: <1288323012.14.0.027314821417.issue10186@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r85904

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10186>
_______________________________________

From report at bugs.python.org  Fri Oct 29 05:37:44 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Oct 2010 03:37:44 +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: <1288323464.15.0.224472743539.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I can?t reliably reproduce it, but here you go:

$ pwd
/home/wok/python/3.2/sep-build-dir-?ric?
$ ../configure --prefix $PWD
[okay]
$ make
[snip gcc and ar]
ranlib libpython3.2m.a
gcc -pthread   -Xlinker -export-dynamic -o python Modules/python.o libpython3.2m.a -lpthread -ldl  -lutil   -lm  
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
SystemError: NULL result without error in PyObject_Call
Aborted
make: *** [sharedmods] Error 134

Setting PYTHONHOME to ., .:., $PWD or $PWD:$PWD did not help.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri Oct 29 05:39:06 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Oct 2010 03:39:06 +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: <1288323546.96.0.499338589016.issue6011@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Of course, first export LANG and LC_ALL to C.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri Oct 29 05:48:56 2010
From: report at bugs.python.org (Manfred Bartz)
Date: Fri, 29 Oct 2010 03:48:56 +0000
Subject: [issue10217] python-2.7.amd64.msi install fails
In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>
Message-ID: <1288324136.62.0.0855565314627.issue10217@psf.upfronthosting.co.za>


Manfred Bartz <manfred.bartz at gmail.com> added the comment:

I ran the install from the command line with:
    msiexec /i python-2.7.amd64.msi /l*v python.log
compresed log attached.

The install completed without error dialogs and a superficial test suggests that I have a working python-2.7-64 installation.

----------
Added file: http://bugs.python.org/file19408/pythonInstallLog.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10217>
_______________________________________

From report at bugs.python.org  Fri Oct 29 06:06:16 2010
From: report at bugs.python.org (Manfred Bartz)
Date: Fri, 29 Oct 2010 04:06:16 +0000
Subject: [issue10217] python-2.7.amd64.msi install fails
In-Reply-To: <1288234706.92.0.436900381953.issue10217@psf.upfronthosting.co.za>
Message-ID: <1288325176.0.0.245150288192.issue10217@psf.upfronthosting.co.za>


Manfred Bartz <manfred.bartz at gmail.com> added the comment:

I uninstalled python and then re-installed it using the same procedure which caused the original problem.

This time the install succeeded without any problems.

The only explanation I can think of is that either the temporary 32-bit install or the command-line install caused a file to be installed which was missing before.

I will try this again on Monday in a virgin Win7-64 VM.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10217>
_______________________________________

From report at bugs.python.org  Fri Oct 29 06:07:13 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 04:07:13 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288325233.7.0.847599039572.issue10224@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Incremental build was not that successful.  After editing Doc/faq/programming.rst, I get the following in the error log:


# Sphinx version: 1.1pre
# Python version: 3.2a3+.0
# Docutils version: 0.7 release
# Jinja2 version: 2.5.5
Traceback (most recent call last):
  File "/Users/sasha/Apps/lib/python3.2/site-packages/Sphinx-1.1predev_20101028-py3.2.egg/sphinx/cmdline.py", line 173, in main
    app.build(force_all, filenames)
  File "/Users/sasha/Apps/lib/python3.2/site-packages/Sphinx-1.1predev_20101028-py3.2.egg/sphinx/application.py", line 203, in build
    self.builder.build_update()
  File "/Users/sasha/Apps/lib/python3.2/site-packages/Sphinx-1.1predev_20101028-py3.2.egg/sphinx/builders/__init__.py", line 193, in build_update
    'out of date' % len(to_build))
  File "/Users/sasha/Apps/lib/python3.2/site-packages/Sphinx-1.1predev_20101028-py3.2.egg/sphinx/builders/__init__.py", line 249, in build
    self.write(docnames, list(updated_docnames), method)
  File "/Users/sasha/Apps/lib/python3.2/site-packages/Sphinx-1.1predev_20101028-py3.2.egg/sphinx/builders/__init__.py", line 279, in write
    self.prepare_writing(docnames)
  File "/Users/sasha/Apps/lib/python3.2/site-packages/Sphinx-1.1predev_20101028-py3.2.egg/sphinx/builders/html.py", line 231, in prepare_writing
    self.load_indexer(docnames)
  File "/Users/sasha/Apps/lib/python3.2/site-packages/Sphinx-1.1predev_20101028-py3.2.egg/sphinx/builders/html.py", line 619, in load_indexer
    self.indexer.load(f, self.indexer_format)
  File "/Users/sasha/Apps/lib/python3.2/site-packages/Sphinx-1.1predev_20101028-py3.2.egg/sphinx/search.py", line 131, in load
    frozen = format.load(stream)
  File "/Users/sasha/Apps/lib/python3.2/site-packages/Sphinx-1.1predev_20101028-py3.2.egg/sphinx/search.py", line 64, in load
    return self.loads(f.read())
  File "/Users/sasha/Apps/lib/python3.2/site-packages/Sphinx-1.1predev_20101028-py3.2.egg/sphinx/search.py", line 55, in loads
    if not data or not s.startswith(self.PREFIX) or not \
TypeError: expected an object with the buffer interface

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 06:51:31 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 04:51:31 +0000
Subject: [issue10147] Python Documentation bugs
In-Reply-To: <1287515992.96.0.884562024831.issue10147@psf.upfronthosting.co.za>
Message-ID: <1288327891.17.0.649718399012.issue10147@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I can only repeat myself and point to <http://www.nerdcore.de/wp/2010/10/19/stephen-frys-message-to-grammer-nazis/>.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10147>
_______________________________________

From report at bugs.python.org  Fri Oct 29 06:54:30 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 04:54:30 +0000
Subject: [issue10222] 3.2 on AIX -  Unexpected text ',' encountered.
In-Reply-To: <1288295054.95.0.251729908149.issue10222@psf.upfronthosting.co.za>
Message-ID: <1288328070.52.0.716068963045.issue10222@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r85907.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10222>
_______________________________________

From report at bugs.python.org  Fri Oct 29 07:20:02 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 05:20:02 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288329602.16.0.115594874287.issue10224@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I fixed that bug in Sphinx rev 49747f5b0c70 (which I will push as soon as bitbucket is up again); incremental build now works for me.

----------
versions: +Python 3.3 -Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 07:26:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 05:26:06 +0000
Subject: [issue10226] urlparse example is wrong
In-Reply-To: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>
Message-ID: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

The following example in Doc/library/urlparse.rst is wrong

>>> urlparse('www.cwi.nl:80/%7Eguido/Python.html')
ParseResult(scheme='', netloc='', path='www.cwi.nl:80/%7Eguido/Python.html',
           params='', query='', fragment='')

In the actual output, scheme='www.cwi.nl'.

In addition, the preceding text is confusing and probably not grammatical:

"""
Otherwise, it is not possible to distinguish between netloc and path components, and would the indistinguishable component would be classified as the path as in a relative URL.
"""

Discovered while working on issue 10225.

----------
assignee: docs at python
components: Documentation
messages: 119855
nosy: belopolsky, docs at python
priority: normal
severity: normal
status: open
title: urlparse example is wrong
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10226>
_______________________________________

From report at bugs.python.org  Fri Oct 29 07:31:27 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 05:31:27 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288330287.09.0.876213805364.issue10224@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

In r85910, I ported the Python-specific modules in tools/ so that they don't need to be 2to3-converted.

Now you can basically easy_install Sphinx on 3.1 and run its sphinx-build without touching the Doc/ tree.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 07:32:19 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 05:32:19 +0000
Subject: [issue10226] urlparse example is wrong
In-Reply-To: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>
Message-ID: <1288330339.92.0.63285237693.issue10226@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: docs at python -> orsenthil
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10226>
_______________________________________

From report at bugs.python.org  Fri Oct 29 07:51:25 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 05:51:25 +0000
Subject: [issue10226] urlparse example is wrong
In-Reply-To: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>
Message-ID: <1288331485.96.0.298263716884.issue10226@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Looks like I've been beaten again by make doctest picking up older python, but something is not right here:

In Python 2.6.5:


>>> urlparse('www.cwi.nl:80/%7Eguido/Python.html')
ParseResult(scheme='www.cwi.nl', netloc='', path='80/%7Eguido/Python.html', params='', query='', fragment='')

but in 2.7:

>>> urlparse('www.cwi.nl:80/%7Eguido/Python.html')
ParseResult(scheme='', netloc='', path='www.cwi.nl:80/%7Eguido/Python.html', params='', query='', fragment='')


and the text preceding the example in the doc does not really tell which is right.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10226>
_______________________________________

From report at bugs.python.org  Fri Oct 29 08:01:48 2010
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 29 Oct 2010 06:01:48 +0000
Subject: [issue10209] Mac OS X: Decompose filenames on encode,
	and precompose filenames on decode
In-Reply-To: <1288139796.38.0.381630346424.issue10209@psf.upfronthosting.co.za>
Message-ID: <1288332108.99.0.957844597454.issue10209@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

For completeness sake: Apple's Cocoa APIs do not renormalize strings, that is: I've created a file named '??n' in the Terminal, then (using a python 3.2 build):

# Terminal input seems NFC:
>>> len('??n')
3

# Output from os.listdir isn't:
>>> os.listdir('.')
['??n']
>>> len(_[0])
5

# Output from the Cocoa equivalant also isn't:
>>> import Foundation
>>> mgr = Foundation.NSFileManager.defaultManager()
>>> mgr.directoryContentsAtPath_('.')
(
    "e\U0301e\U0301n"
)
>>> len(_[0])
5

BTW. fsdecode(fsencode(x)) cannot in general be a no-op, unicode normalizations can screw things up (with the now withdrawn proposal the expression wouldn't be a no-op for NFD strings).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10209>
_______________________________________

From report at bugs.python.org  Fri Oct 29 08:15:07 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 06:15:07 +0000
Subject: [issue10226] urlparse example is wrong
In-Reply-To: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>
Message-ID: <1288332907.9.0.835031469356.issue10226@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I think this is correct: it is the new behavior after the fix for #754016 was committed.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10226>
_______________________________________

From report at bugs.python.org  Fri Oct 29 08:28:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 06:28:26 +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: <1288333706.13.0.354845845212.issue10198@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r85914.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10198>
_______________________________________

From report at bugs.python.org  Fri Oct 29 08:40:30 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 Oct 2010 06:40:30 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288334430.35.0.313222344826.issue10224@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Did you know break building the 3.x documentation with Python 2? If so, please revert that change.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 08:54:32 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 06:54:32 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288335272.44.0.889723895773.issue6715@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

After applying the patch, it builds fine here and the test suite passes.  However, it seems to leak quite a bit -- if I run regrtest with -R::, my system starts swapping heavily after the second run.

In lzmamodule, there are lots of API calls that aren't error-checked, e.g.

  PyDict_SetItemString(filter, "dict_size", PyLong_FromLong((long)lzma_options.dict_size));

General comments: please don't introduce tabs and trailing whitespace in C and Python files, and wrap your lines at 79 characters whenever possible.  reST function/class directives need a blank line after the signature.  (But don't worry about the markup too much, I'll review the new file anyway after commit.)

@pitrou: Why is this marked "Python 3.3"?  If the error handling in the C module is corrected, it's in a good enough shape to be committed before 3.2b1, and the remaining bugs ironed out until final.

----------
nosy: +georg.brandl
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Oct 29 08:55:36 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 06:55:36 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288335336.84.0.712847798586.issue10224@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Nope, these files run just as fine in Python 2.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 08:56:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 06:56:26 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288335386.25.0.413396397624.issue10224@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

(The usual build process via Makefile still uses Python 2, and that won't change for 3.2.)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 09:00:39 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 07:00:39 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1288335272.44.0.889723895773.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288335633.3565.11.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> @pitrou: Why is this marked "Python 3.3"?  If the error handling in
> the C module is corrected, it's in a good enough shape to be committed
> before 3.2b1, and the remaining bugs ironed out until final.

I think it needs a real review before going in. Now if that review can
get done and the issues fixed before the beta, it's ok. By a quick look
at the code it seemed to need quite a bit of polish before being
acceptable for commit, but I might be mistaken.

(we should also avoid the multiprocessing syndrome where we rushed some
alpha-quality code just before the feature deadline and then had to fix
many issues in urgency. I do believe xz/lzma support is important in the
long term, though)

Oh, by the way, Per should agree to do maintenance directly against the
CPython repository. Please, no more externally-maintained modules (you
know what I'm talking about).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Oct 29 09:04:26 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 07:04:26 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288335866.92.0.648011864908.issue6715@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, definitely no externally maintained modules.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Fri Oct 29 09:05:15 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 07:05:15 +0000
Subject: [issue10226] urlparse example is wrong
In-Reply-To: <1288332907.9.0.835031469356.issue10226@psf.upfronthosting.co.za>
Message-ID: <AANLkTimXsLtzKj5T_K-9GHUZepTK8nPtNgMkAfcvgCxU@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Oct 29, 2010 at 2:15 AM, Georg Brandl <report at bugs.python.org> wrote:
..
> I think this is correct: it is the new behavior after the fix for #754016 was committed.
>

I agree.  I kept the issue open because I cannot parse

"""
Otherwise, it is not possible to distinguish between netloc and path
components, and would the indistinguishable component would be
classified as the path as in a relative URL.
"""

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10226>
_______________________________________

From report at bugs.python.org  Fri Oct 29 09:06:13 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 07:06:13 +0000
Subject: [issue10226] urlparse example is wrong
In-Reply-To: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>
Message-ID: <1288335973.37.0.470788636865.issue10226@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

That's for Senthil to rephrase as intended :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10226>
_______________________________________

From report at bugs.python.org  Fri Oct 29 09:19:07 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 07:19:07 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1288336747.07.0.653423504362.issue10225@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I started with 2.7 branch because some of the issues are the same there, but the tools work better at the moment.  I a posting a work-in-progress patch to solicit early feedback.

----------
versions: +Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Fri Oct 29 09:49:47 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 07:49:47 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1288338587.73.0.0698978406246.issue10225@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file19409/issue10225-r27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Fri Oct 29 09:50:32 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 07:50:32 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1288338632.62.0.0214168152513.issue10225@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/issue10225>
_______________________________________

From report at bugs.python.org  Fri Oct 29 10:07:36 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 08:07:36 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287785853.06.0.999498237481.issue10093@psf.upfronthosting.co.za>
Message-ID: <4CCA80C3.5080605@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Brett Cannon wrote:
> 
> Brett Cannon <brett at python.org> added the comment:
> 
> But this is meant to be an optional warning; users will never see it. Me as a developer, I would like to know when I leave a file open as that is a waste of resources, plus with no guarantee of everything being flushed to disk.

That's what I'm referring to: most Python applications are
written with the fact in mind, that garbage collection will
close the files or socket.

That's a perfectly fine way of writing Python applications,
so why should the programmer get warned about this regular
approach to Python programming ?

> Besides, the context manager for files makes the chance of leaving a file open a much more blaring mistake.

See above: context aren't required for working with files. And again:
it's *not* a mistake to not explicitly close a file.

The same applies for sockets.

Think of the simple idiom:

data = open(filename).read()

This would always create a warning under the proposal.

Same for:

for line in open(filename):
   print line

Also note that files and sockets can be kept as references in data
structures (other than local variables or on the stack) and there
you usually have the same approach: you expect Python to close the
files when garbage collecting the data structures and that's
perfectly ok.

If you want to monitor resource usage in your application it
would be a lot more useful to provide access to the number of
currently open FDs, than scattering warnings around the
application which mostly trigger false positives.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 10:22:36 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 08:22:36 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <4CCA80C3.5080605@egenix.com>
Message-ID: <1288340552.3565.17.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> That's what I'm referring to: most Python applications are
> written with the fact in mind, that garbage collection will
> close the files or socket.
> 
> That's a perfectly fine way of writing Python applications,

Some people would disagree, especially Windows users who cannot timely
delete files when some file descriptors still point to them.

> so why should the programmer get warned about this regular
> approach to Python programming ?

Again: it is an *optional* warning. It is *disabled* by default, except
when compiled --with-pydebug.

> The same applies for sockets.

It is *definitely* a mistake if the socket has been bound to a local
address and/or connected to a remote endpoint.

> Think of the simple idiom:
> 
> data = open(filename).read()
> 
> This would always create a warning under the proposal.

We have had many Windows buildbot failures because of such coding style.

> If you want to monitor resource usage in your application it
> would be a lot more useful to provide access to the number of
> currently open FDs

Agreed it would be useful as well, but please tell that to operating
system vendors. Python has no way to calculate such a statistic.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 10:50:29 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 29 Oct 2010 08:50:29 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

In a recent email exchange on python-dev, Antoine Pitrou mentioned that slicing memoryview objects (lazy slices) wasn't necessarily very efficient when dealing with short slices.  The data he posted was:


$ ./python -m timeit -s "x = b'x'*10000" "x[:100]"
10000000 loops, best of 3: 0.134 usec per loop
$ ./python -m timeit -s "x = memoryview(b'x'*10000)" "x[:100]"
10000000 loops, best of 3: 0.151 usec per loop

Actually, this is not a fair comparison.  A more realistic alternative to the memoryview is the bytearray, a mutable buffer.  My local tests gave these numbers:

python.exe -m timeit -n 10000000 -s "x = ((b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.14 usec per loop

python.exe -m timeit -n 10000000 -s "x = (bytearray(b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.215 usec per loop

python.exe -m timeit -n 10000000 -s "x = memoryview(bytearray(b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.163 usec per loop

In this case, lazy slicing is indeed faster than greedy slicing.  However, I was intrigued by how much these cases differ.  Why was slicing bytes objects so much faster?  Each should just result in the generation of a single object.

It turns out that the slicing operation for strings (and sequences is very streamlined in the core.  To address this to some extent I provide a patch with three main components:

1) There is now a single object cache of slice objects.  These are generated by the core when slicing and immediately released.  Reusing them if possible is very beneficial.
2) The PySlice_GetIndicesEx couldn't be optimized because of aliasing.  Fixing that function sped it up considerably.
3) Creating a new api to create a memory view from a base memory view and a slice is much faster.  The old way would do two copies of a Py_buffer with adverse effects on cache performance.

Applying this patch provides the following figures:
python.exe -m timeit -n 10000000 -s "x = ((b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.125 usec per loop

python.exe -m timeit -n 10000000 -s "x = (bytearray(b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.202 usec per loop

python.exe -m timeit -n 10000000 -s "x = memoryview(bytearray(b'x'*10000))" "x[:100]"
10000000 loops, best of 3: 0.138 usec per loop

in memoryobject.c there was a comment stating that there should be an API for this.  Now there is, only internal.

----------
components: Interpreter Core
keywords: needs review, patch
messages: 119872
nosy: krisvale, pitrou
priority: normal
severity: normal
status: open
title: Improve performance of MemoryView slicing
type: performance
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Oct 29 10:56:06 2010
From: report at bugs.python.org (Senthil Kumaran)
Date: Fri, 29 Oct 2010 08:56:06 +0000
Subject: [issue10226] urlparse example is wrong
In-Reply-To: <1288335973.37.0.470788636865.issue10226@psf.upfronthosting.co.za>
Message-ID: <AANLkTintBmt=P7jpJwD=4=mbeVWT1z-zr_KGnrVTMUv3@mail.gmail.com>


Senthil Kumaran <orsenthil at gmail.com> added the comment:

-   Otherwise, it is not possible to distinguish between netloc and path
-   components, and would the indistinguishable component would be classified
-   as the path as in a relative URL.
+   If the netloc does not start with '//', the module cannot distinguish it
+   from path and it would classify it as path component in the relative url.

How does this sound?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10226>
_______________________________________

From report at bugs.python.org  Fri Oct 29 11:14:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 09:14:31 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288343671.68.0.765514046082.issue10227@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You forgot to attach your patch.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Oct 29 11:50:32 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 29 Oct 2010 09:50:32 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288345832.65.0.0164936082053.issue10227@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Oh dear.  Here it is.

----------
Added file: http://bugs.python.org/file19410/memoryobj.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Oct 29 12:04:37 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 29 Oct 2010 10:04:37 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288346677.39.0.539861852647.issue10227@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

But then, perhaps implementing the sequence protocol for memoryviews might be more efficient still.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Oct 29 12:11:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 10:11:52 +0000
Subject: [issue10228] Refleak run of test_dbm fails when several dbm modules
	are available
In-Reply-To: <1288347112.92.0.717435942769.issue10228@psf.upfronthosting.co.za>
Message-ID: <1288347112.92.0.717435942769.issue10228@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is only when several dbm modules are compiled in (e.g. "gnu" and "dumb"):

$ ./python -m test.regrtest -R 3:2 test_dbm
[1/1] test_dbm
beginning 5 repetitions
12345
test test_dbm failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/deallocwarn/Lib/test/test_dbm.py", line 129, in test_whichdb
    self.assertEqual(name, dbm.whichdb(_fname))
AssertionError: 'dbm.gnu' != 'dbm.dumb'
- dbm.gnu
+ dbm.dumb

----------
components: Tests
messages: 119877
nosy: pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Refleak run of test_dbm fails when several dbm modules are available
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10228>
_______________________________________

From report at bugs.python.org  Fri Oct 29 12:12:52 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 10:12:52 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288347172.82.0.109054149323.issue10227@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The sequence protocol (if I'm not confused) only work with a PyObject ** array.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Oct 29 12:15:12 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 10:15:12 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1288347312.93.0.656648238619.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch (also fixes a small refleak).

----------
Added file: http://bugs.python.org/file19411/deallocwarn4.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 12:20:07 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 29 Oct 2010 10:20:07 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288347607.17.0.721962967677.issue10227@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

As an additional point:  the PyMemoryObject has a "base" member that I think is redundant.  the "view.obj" should be sufficient.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Oct 29 12:23:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 10:23:53 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288347607.17.0.721962967677.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288347829.3565.51.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> As an additional point:  the PyMemoryObject has a "base" member that I
> think is redundant.  the "view.obj" should be sufficient.

Yes, that's what I think as well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Oct 29 12:31:34 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 10:31:34 +0000
Subject: [issue10229] Refleak run of test_gettext fails
In-Reply-To: <1288348294.62.0.0907397506052.issue10229@psf.upfronthosting.co.za>
Message-ID: <1288348294.62.0.0907397506052.issue10229@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This is probably caused by r85223.

$ ./python -m test.regrtest -R 3:2 test_gettext
[1/1] test_gettext
beginning 5 repetitions
12345
test test_gettext failed -- Traceback (most recent call last):
  File "/home/antoine/py3k/deallocwarn/Lib/test/test_gettext.py", line 348, in test_cache
    self.assertEqual(len(gettext._translations), 0)
AssertionError: 2 != 0

1 test failed:
    test_gettext

----------
assignee: eric.araujo
components: Tests
messages: 119882
nosy: eric.araujo, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: Refleak run of test_gettext fails
type: resource usage
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10229>
_______________________________________

From report at bugs.python.org  Fri Oct 29 12:39:15 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 10:39:15 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1288348755.87.0.538383500771.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've committed the patch in r85920; let's watch the buildbots. Also, you'll see many warnings in the test suite if compiled --with-pydebug.

----------
resolution:  -> fixed
stage:  -> committed/rejected

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 12:48:38 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 29 Oct 2010 10:48:38 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288349318.74.0.841355382384.issue10227@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

In 2.x, strings are sliced using PySequence_GetSlice().  ceval.c in 3.0 is different, there is no apply_slice there (despite comments to that effect).  I'd have to take another look with the profiler to figure out how bytes slicing in 3.0 works, but I suspect that it is somehow fasttracked passed the creation of slice objects, etc.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Oct 29 12:50:44 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 10:50:44 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288349318.74.0.841355382384.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288349440.3565.52.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> I'd have to take another look with the profiler to figure out how
> bytes slicing in 3.0 works, but I suspect that it is somehow
> fasttracked passed the creation of slice objects, etc.

I don't think it is fasttracked at all. 
Even plain indexing is not fasttracked either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Oct 29 12:57:24 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Fri, 29 Oct 2010 10:57:24 +0000
Subject: [issue10227] Improve performance of MemoryView slicing
In-Reply-To: <1288342228.97.0.170566139041.issue10227@psf.upfronthosting.co.za>
Message-ID: <1288349844.34.0.233496761748.issue10227@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Well then, its back to the profiler for 3.2.  I did all of the profiling with 2.7 for practical reasons (it was the only version I had available at the time) and then ported the change to 3.2 today.  But obviously there are different rules in 3.2 :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10227>
_______________________________________

From report at bugs.python.org  Fri Oct 29 13:11:34 2010
From: report at bugs.python.org (Jacques Grove)
Date: Fri, 29 Oct 2010 11:11:34 +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: <1288350694.14.0.76473383047.issue2636@psf.upfronthosting.co.za>


Jacques Grove <jacques at tripitinc.com> added the comment:

Do we expect this to work on 64 bit Linux and python 2.6.5?  I've compiled and run some of my code through this, and there seems to be issues with non-greedy quantifier matching (at least relative to the old re module):

$ cat test.py
import re, regex

text = "(MY TEST)"
regexp = '\((?P<test>.{0,5}?TEST)\)'
print re.findall(regexp, text)
print regex.findall(regexp, text)


$ python test.py
['MY TEST']
[]

python 2.7 produces the same results for me.

However, making the quantifier greedy (removing the '?') gives the same result for both re and regex modules.

----------
nosy: +jacques

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Oct 29 13:18:36 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 11:18:36 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1288340552.3565.17.camel@localhost.localdomain>
Message-ID: <4CCAAD88.8090705@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> That's what I'm referring to: most Python applications are
>> written with the fact in mind, that garbage collection will
>> close the files or socket.
>>
>> That's a perfectly fine way of writing Python applications,
> 
> Some people would disagree, especially Windows users who cannot timely
> delete files when some file descriptors still point to them.

There is no difference here:

Whether you write an application with automatic closing of
the file/socket at garbage collection time in mind, or you explicitly
close the file/socket, the timing is the same.

The only difference is with Python implementations that don't
use synchronous garbage collection, e.g. Jython, but not with
CPython.

>> so why should the programmer get warned about this regular
>> approach to Python programming ?
> 
> Again: it is an *optional* warning. It is *disabled* by default, except
> when compiled --with-pydebug.

Yes, I know. I still find the warning rather useless, since it
warns about code that's perfectly ok.

>> The same applies for sockets.
> 
> It is *definitely* a mistake if the socket has been bound to a local
> address and/or connected to a remote endpoint.

I don't follow you. Where's the difference between writing:

s.close()
or
s = None

for an open socket s ?

>> Think of the simple idiom:
>>
>> data = open(filename).read()
>>
>> This would always create a warning under the proposal.
> 
> We have had many Windows buildbot failures because of such coding style.

Again: where's the difference between writing:

data = open(filename).read()
and
f = open(filename)
data = f.read()
f.close()

?

If the above coding style causes problems, the reasons must be
elsewhere, since there is no difference between those two
styles (other than cluttering up your locals).

The for-loop file iterator support was explicitly added to make
writing:

for line in open(filename):
    print line

possible.

>> If you want to monitor resource usage in your application it
>> would be a lot more useful to provide access to the number of
>> currently open FDs
> 
> Agreed it would be useful as well, but please tell that to operating
> system vendors. Python has no way to calculate such a statistic.

At least for Linux, that's not hard and I doubt it is for other OSes.

4

On other Unixes, you can simply use fcntl() to scan all possible FDs
for open FDs.

On Windows you can use one of these functions for the same effect:
http://msdn.microsoft.com/en-us/library/kdfaxaay(v=VS.90).aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 13:52:38 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 11:52:38 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <4CCAAD88.8090705@egenix.com>
Message-ID: <1288353153.3565.66.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Whether you write an application with automatic closing of
> the file/socket at garbage collection time in mind, or you explicitly
> close the file/socket, the timing is the same.

No, because objects can be kept alive through tracebacks (or reference
cycles).

> I don't follow you. Where's the difference between writing:
> 
> s.close()
> or
> s = None
> 
> for an open socket s ?

The difference is when s is still referenced elsewhere.
Also, the intent of the former is clear while the latter is deliberately
obscure (while not saving any significant amount of typing).

> The for-loop file iterator support was explicitly added to make
> writing:
> 
> for line in open(filename):
>     print line
> 
> possible.

So what?

> At least for Linux, that's not hard and I doubt it is for other OSes.
> 
> 4
> 
> On other Unixes, you can simply use fcntl() to scan all possible FDs
> for open FDs.
> 
> On Windows you can use one of these functions for the same effect:
> http://msdn.microsoft.com/en-us/library/kdfaxaay(v=VS.90).aspx

Until you post some code I won't understand what you are talking about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 14:08:21 2010
From: report at bugs.python.org (STINNER Victor)
Date: Fri, 29 Oct 2010 12:08:21 +0000
Subject: [issue10230] test_tarfile failure (test_extractall) on AMD64 debian
	parallel 3.x: os.utime(float) issue
In-Reply-To: <1288354101.14.0.267054038013.issue10230@psf.upfronthosting.co.za>
Message-ID: <1288354101.14.0.267054038013.issue10230@psf.upfronthosting.co.za>


New submission from STINNER Victor <victor.stinner at haypocalc.com>:

test_tarfile in only failing on one 3.x buildbot: AMD64 debian parallel 3.x. The problem is related to the mtime field and os.utime():

http://www.python.org/dev/buildbot/builders/AMD64 debian parallel 3.x/builds/508/steps/test/logs/stdio
======================================================================
FAIL: test_extractall (test.test_tarfile.MiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 358, in test_extractall
    self.assertEqual(tarinfo.mtime, file_mtime, errmsg)
AssertionError: tar mtime 1041808783 (int) != file time 1041808783.000001 (0x1.f0c5ec7800008p+29) of path '/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/build/test_python_23882/@test_23882_tmp-tardir/ustar/dirtype'

======================================================================
FAIL: test_extractall (test.test_tarfile.GzipMiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 358, in test_extractall
    self.assertEqual(tarinfo.mtime, file_mtime, errmsg)
AssertionError: tar mtime 1041808783 (int) != file time 1041808783.000003 (0x1.f0c5ec7800019p+29) of path '/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/build/test_python_23882/@test_23882_tmp-tardir/ustar/dirtype'

======================================================================
FAIL: test_extractall (test.test_tarfile.Bz2MiscReadTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/Lib/test/test_tarfile.py", line 358, in test_extractall
    self.assertEqual(tarinfo.mtime, file_mtime, errmsg)
AssertionError: tar mtime 1041808783 (int) != file time 1041808783.000005 (0x1.f0c5ec780002ap+29) of path '/var/autofs/net/homedir/home/martin.vonloewis/buildarea/3.x.loewis-parallel2/build/build/test_python_23882/@test_23882_tmp-tardir/ustar/dirtype'

----------------------------------------------------------------------

(I patched test_extractall to dump mtime values as hexadecimal for floats)

Binary dump os this "ustar/dirtype" entry:

15360) file[2]: Tar File (ustar/dirtype/: Directory, 0 bytes) (512 bytes)
      0) name= "ustar/dirtype/": Name (100 bytes)
      100) mode= "0000755": Mode (8 bytes)
      108) uid= "0001750": User ID (8 bytes)
      116) gid= "0000144": Group ID (8 bytes)
      124) size= "00000000000": Size (12 bytes)
      136) mtime= "07606136617": Modification time (12 bytes)
      148) check_sum= "015042": Check sum (8 bytes)
      156) type= Directory: Type (1 byte)
      157) lname= (empty): Link name (100 bytes)
      257) magic= "ustar\x0000": Magic (8 bytes)
      265) uname= "tarfile": User name (32 bytes)
      297) gname= "tarfile": Group name (32 bytes)
      329) devmajor= "0000000": Dev major (8 bytes)
      337) devminor= "0000000": Dev minor (8 bytes)
      345) padding= <null>: Padding (zero) (167 bytes)             

So this directory has no PAX extra headers, only classical headers, and mtime is 0o7606136617 (1041808783).

os.utime() gets an integer with exact value 1041808783, but then os.stat() gives st_mtime:
 - 1041808783.000001 (0x1.f0c5ec7800008p+29)
 - 1041808783.000003 (0x1.f0c5ec7800019p+29)
 - 1041808783.000005 (0x1.f0c5ec780002ap+29)

To set file time, os.utime() has 4 implementations:
 - SetFileTime() for Windows
 - utimes() using struct timeval
 - utime() using time_t
 - utime() using struct utimbuf

I don't know which one is used (except that it is not supposed to be a Windows host :-)).

----------
components: Library (Lib), Tests
keywords: buildbot
messages: 119890
nosy: haypo, loewis
priority: normal
severity: normal
status: open
title: test_tarfile failure (test_extractall) on AMD64 debian parallel 3.x: os.utime(float) issue
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10230>
_______________________________________

From report at bugs.python.org  Fri Oct 29 14:18:00 2010
From: report at bugs.python.org (Baptiste Carvello)
Date: Fri, 29 Oct 2010 12:18:00 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <1288323546.96.0.499338589016.issue6011@psf.upfronthosting.co.za>
Message-ID: <4CCABB59.9090506@free.fr>


Baptiste Carvello <baptiste13z at free.fr> added the comment:

Hello,

I can reproduce the exact same error as ?ric. The end of the output is a 
little bit more informative here:

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
SystemError: NULL result without error in PyObject_Call
/bin/sh: line 1: 13513 Aborted                 CC='gcc -pthread' 
LDSHARED='gcc -pthread -shared  ' OPT='-DNDEBUG -g -fwrapv -O3 -Wall 
-Wstrict-prototypes' ./python -E ./setup.py build
make: *** [sharedmods] Error 134

I only kept the part of the log that is output if I rerun "make". The 
number 13513 must be a PID number. It is not stable across invocations.

Running just "./python -E ./setup.py build", or just "./python setup.py 
build" does also abort with

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
SystemError: NULL result without error in PyObject_Call
Aborted

The instructions to reproduce, used in my home directory (which has a 
ASCII path), are:

svn co http://svn.python.org/projects/python/branches/py3k
cd py3k/
export LC_ALL=C
export LANG=C
./configure --prefix=/home/baptiste/Desktop/T?l?chargements/PyInstall
make
make
./python -E ./setup.py build
./python setup.py build

The svn revision pulled was 85926.

Hope this helps,

Baptiste

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri Oct 29 14:26:06 2010
From: report at bugs.python.org (Piotr Matuszewski)
Date: Fri, 29 Oct 2010 12:26:06 +0000
Subject: [issue10208] add mazovia.py to encodings/
In-Reply-To: <1288137946.29.0.185771065626.issue10208@psf.upfronthosting.co.za>
Message-ID: <1288355166.06.0.374356584406.issue10208@psf.upfronthosting.co.za>


Piotr Matuszewski <pythlea4 at farmatex.com.pl> added the comment:

it's still used by some business in Poland, who have DOS based systems, but I don't think any new deployments are using it

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10208>
_______________________________________

From report at bugs.python.org  Fri Oct 29 14:30:25 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 Oct 2010 12:30:25 +0000
Subject: [issue10230] test_tarfile failure (test_extractall) on AMD64 debian
	parallel 3.x: os.utime(float) issue
In-Reply-To: <1288354101.14.0.267054038013.issue10230@psf.upfronthosting.co.za>
Message-ID: <1288355425.15.0.572576391771.issue10230@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is a duplicate of http://bugs.python.org/issue10184

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10230>
_______________________________________

From report at bugs.python.org  Fri Oct 29 14:52:28 2010
From: report at bugs.python.org (Baptiste Carvello)
Date: Fri, 29 Oct 2010 12:52:28 +0000
Subject: [issue6011] python doesn't build if prefix contains non-ascii
	characters
In-Reply-To: <4CCABB59.9090506@free.fr>
Message-ID: <4CCAC36E.1040904@free.fr>


Baptiste Carvello <baptiste13z at free.fr> added the comment:

A little bit more information:

the error message comes from Python/pythonrun.c, line 736, in function 
initfsencoding.

This part of the code is protected with a preprocessor #if:

#if defined(HAVE_LANGINFO_H) && defined(CODESET)

so I tried replacing that with #if 0. However, the function then fails 
on line 750. The comment on line 749 states:

/* Such error can only occurs in critical situations: no more
 * memory, import a module of the standard library failed,
 * etc. */

It looks like it is not the case, and that Py_FileSystemDefaultEncoding 
has no reasonable default when "python" is called from the build 
directory with the "C" locale.

For the record, when running the system "python" with the "C" locale, 
the filesystemencoding is gets set to 'ANSI_X3.4-1968'.

Last thing, in case it is of any use, all my testing is done on an amd64 
Debian stable system.

Cheers,
Baptiste

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6011>
_______________________________________

From report at bugs.python.org  Fri Oct 29 14:55:50 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 12:55:50 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1288353153.3565.66.camel@localhost.localdomain>
Message-ID: <4CCAC451.9030703@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> Whether you write an application with automatic closing of
>> the file/socket at garbage collection time in mind, or you explicitly
>> close the file/socket, the timing is the same.
> 
> No, because objects can be kept alive through tracebacks (or reference
> cycles).

If you get a traceback, the explicitly file.close() won't help
you either; but that usually doesn't matter, since program
execution will stop, the traceback will get GCed and the file
closed. This is a very normal and reasonable expectation of a
Python programmer.

>> I don't follow you. Where's the difference between writing:
>>
>> s.close()
>> or
>> s = None
>>
>> for an open socket s ?
> 
> The difference is when s is still referenced elsewhere.
> Also, the intent of the former is clear while the latter is deliberately
> obscure (while not saving any significant amount of typing).

Sure, but that's not the point. It is not a mistake to write
such code and neither is this obscure, otherwise we'd also
require explicit garbage collection for other parts of Python.

If the application keeps references to the objects in other
places, the programmer would, of course, add an explicit .close().
Ditto for the files.

>> The for-loop file iterator support was explicitly added to make
>> writing:
>>
>> for line in open(filename):
>>     print line
>>
>> possible.
> 
> So what?

The warning will trigger without any reason.

>> At least for Linux, that's not hard and I doubt it is for other OSes.
>>
>> 4
>>
>> On other Unixes, you can simply use fcntl() to scan all possible FDs
>> for open FDs.
>>
>> On Windows you can use one of these functions for the same effect:
>> http://msdn.microsoft.com/en-us/library/kdfaxaay(v=VS.90).aspx
> 
> Until you post some code I won't understand what you are talking about.

RoundUp's email interface ate the code. I'll post it again via the
web interface.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 14:57:53 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 12:57:53 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1288357073.39.0.880406714911.issue10093@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Reposted via the web interface:

>> If you want to monitor resource usage in your application it
>> would be a lot more useful to provide access to the number of
>> currently open FDs
> Agreed it would be useful as well, but please tell that to operating
> system vendors. Python has no way to calculate such a statistic.

At least for Linux, that's not hard and I doubt it is for other OSes.

>>> import os
>>> nfds = len(os.listdir('/proc/%i/fd' % os.getpid()))
>>> print nfds
4

On other Unixes, you can simply use fcntl() to scan all possible FDs
for open FDs.

On Windows you can use one of these functions for the same effect:
http://msdn.microsoft.com/en-us/library/kdfaxaay(v=VS.90).aspx

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 14:59:47 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 12:59:47 +0000
Subject: [issue10208] add mazovia.py to encodings/
In-Reply-To: <1288355166.06.0.374356584406.issue10208@psf.upfronthosting.co.za>
Message-ID: <4CCAC540.1070304@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Piotr Matuszewski wrote:
> 
> Piotr Matuszewski <pythlea4 at farmatex.com.pl> added the comment:
> 
> it's still used by some business in Poland, who have DOS based systems, but I don't think any new deployments are using it

Then I think it's better maintained outside the stdlib.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10208>
_______________________________________

From report at bugs.python.org  Fri Oct 29 15:00:27 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 13:00:27 +0000
Subject: [issue10208] add mazovia.py to encodings/
In-Reply-To: <1288137946.29.0.185771065626.issue10208@psf.upfronthosting.co.za>
Message-ID: <1288357227.99.0.754886252456.issue10208@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


----------
resolution:  -> rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10208>
_______________________________________

From report at bugs.python.org  Fri Oct 29 15:07:01 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 13:07:01 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <4CCAC451.9030703@egenix.com>
Message-ID: <1288357616.3565.76.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> The warning will trigger without any reason.

Well, by now you should have understood the reason, so I conclude that
you are either 1) deaf 2) stupid 3) deliberately obnoxious.

This is my last answer to you on this topic. Goodbye.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 15:10:35 2010
From: report at bugs.python.org (Hallvard B Furuseth)
Date: Fri, 29 Oct 2010 13:10:35 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>
Message-ID: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>


New submission from Hallvard B Furuseth <h.b.furuseth at usit.uio.no>:

SimpleHTTPRequestHandler directory bugs

Running 3.2a3 http/server.py or 2.7 SimpleHTTPServer.py as a script:

* Redirection appends "/" to the unparsed URL instead of to the
  pathname component of the parsed URL: "foo/dir?baz" => "foo/dir?baz/".

* The unparsed URL is also used to check if the URL ends with "/".
  Thus "foo/dir?baz/" gives a directory listing instead of redirecting,
  which makes the files relative to "foo/" instead of to "foo/dir/".

* translate_path("directory/") produces filenames without a final "/".
  Not sure if that is correct for CGI env['PATH_TRANSLATED'].  Anyway:
  This means a non-directory file with a final slash is accepted, but
  again relative URLs in that file will refer to the wrong absolute URL.
  ".../foo.html/" + relative URL "bar.html" -> ".../foo.html/bar.html".

  However if translate_path("...foo/") is changed and you use stat() on
  the result, I do not know if all relevant directory operations work
  with the final directory separator on all OSes.  I seem to remember
  getting errors in some OS for stat("dirname/", &st) in C.

* translate_path() does not handle initial "."/".." on non-Posix systems.
  If that's wrong, it can (ignoring other issues listed here) do this:
      drop = frozenset((os.curdir, os.pardir, '', '.', '..'))
      for ...:
          if word not in drop: os.path.join(path, word)
  Though it looks a bit quicker to do
      words, drop = [], frozenset((os.curdir, os.pardir, '', '.', '..'))
      for word in filter(None, path.split('/')):
          word = os.path.split(os.path.splitdrive(word)[1])[1]
          if word not in drop: words.append(word)
      return os.path.join(os.getcwd(), *words)
  unless that can somehow produce a different result.

----------
components: Library (Lib)
messages: 119899
nosy: hfuru
priority: normal
severity: normal
status: open
title: SimpleHTTPRequestHandler directory bugs
type: behavior
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Fri Oct 29 15:15:52 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 29 Oct 2010 13:15:52 +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: <1288358152.55.0.192835158037.issue10206@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I think Benjamin fixed this in r85904. I'm going to verify and add some tests.

----------
priority: critical -> normal
stage: patch review -> unit test needed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Fri Oct 29 15:16:57 2010
From: report at bugs.python.org (Eric Smith)
Date: Fri, 29 Oct 2010 13:16:57 +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: <1288358217.78.0.821516464067.issue10206@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


Removed file: http://bugs.python.org/file19396/issue10206.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10206>
_______________________________________

From report at bugs.python.org  Fri Oct 29 15:26:02 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 13:26:02 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1288357616.3565.76.camel@localhost.localdomain>
Message-ID: <4CCACB65.5060603@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou at free.fr> added the comment:
> 
>> The warning will trigger without any reason.
> 
> Well, by now you should have understood the reason, so I conclude that
> you are either 1) deaf 2) stupid 3) deliberately obnoxious.
> 
> This is my last answer to you on this topic. Goodbye.

Ignoring your insults, I think the problem is that you fail to see
point or address it:

Warnings in Python are meant to tell programmers that something
should be fixed. The warnings in the examples I gave do not point
to cases that need to be fixed, in fact, they are very common
idioms used in Python books, examples and tutorials.

Note that you've just added warning filters to the test suite
to ignore the warning again. I find that a good argument
for not having it in this form in the first place.

A truely useful ResourceWarning would trigger if resources gets
close to some limit, e.g. if the number of open file descriptors
reaches a certain limit. This could easily be tested when
opening them, since they are plain integers.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 15:53:45 2010
From: report at bugs.python.org (R. David Murray)
Date: Fri, 29 Oct 2010 13:53:45 +0000
Subject: [issue10231] SimpleHTTPRequestHandler directory bugs
In-Reply-To: <1288357835.63.0.535261040588.issue10231@psf.upfronthosting.co.za>
Message-ID: <1288360425.3.0.646341678387.issue10231@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +orsenthil

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10231>
_______________________________________

From report at bugs.python.org  Fri Oct 29 16:08:05 2010
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 29 Oct 2010 14:08:05 +0000
Subject: [issue10214] Misc/python-mode.el is out of date.
In-Reply-To: <1288185188.37.0.749151956354.issue10214@psf.upfronthosting.co.za>
Message-ID: <1288361285.08.0.649890822295.issue10214@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

r85927 in py3k
r85928 in release31-maint
r85929 in release27-maint

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10214>
_______________________________________

From report at bugs.python.org  Fri Oct 29 16:09:25 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 14:09:25 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1288361365.92.0.827072367667.issue10093@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The buildbots showed no major issue, so this issue is now resolved. The warnings expose a lot of issues in the stdlib that deserve addressing, though ;)

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 16:09:32 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Oct 2010 14:09:32 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <4CCACB65.5060603@egenix.com>
Message-ID: <AANLkTi=37k_gCs0iDtM9OOogsyxaOp8T0XjCJN351Og5@mail.gmail.com>


Benjamin Peterson <benjamin at python.org> added the comment:

2010/10/29 Marc-Andre Lemburg <report at bugs.python.org>:
>
> Marc-Andre Lemburg <mal at egenix.com> added the comment:
>
> Antoine Pitrou wrote:
>>
>> Antoine Pitrou <pitrou at free.fr> added the comment:
>>
>>> The warning will trigger without any reason.
>>
>> Well, by now you should have understood the reason, so I conclude that
>> you are either 1) deaf 2) stupid 3) deliberately obnoxious.
>>
>> This is my last answer to you on this topic. Goodbye.
>
> Ignoring your insults, I think the problem is that you fail to see
> point or address it:
>
> Warnings in Python are meant to tell programmers that something
> should be fixed. The warnings in the examples I gave do not point
> to cases that need to be fixed, in fact, they are very common
> idioms used in Python books, examples and tutorials.

They're not particularly good idioms then. Leaving files open
haphazardly leads to subtle bugs as our test suite has shown.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Fri Oct 29 16:59:23 2010
From: report at bugs.python.org (David Joy)
Date: Fri, 29 Oct 2010 14:59:23 +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: <1288364363.38.0.986573316518.issue4431@psf.upfronthosting.co.za>


David Joy <videan42 at gmail.com> added the comment:

Hi All,

I just built mysql-python against CPython2.7 MSVC2008 Express Edition and Server 2003 R2.  All were freshly built on a clean Server 2003 install.  This exact issue occurred building with pip 0.8.1 on top of distribute 0.6.14:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe -nologo -manifest build\temp.win32-2.7\Release\_mysql.pyd.manifest -outputresource:build\lib.win32-2.7\_mysql.pyd;2

build\temp.win32-2.7\Release\_mysql.pyd.manifest : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified.

error: command 'mt.exe' failed with exit status 31

----------------------------------------
Command C:\Python27\python.exe -c "import  setuptools;__file__='C:\\Documents and  Settings\\Administrator\\build\\mysql-python\\setup.py';execfile(__file__)" install --single-version-externally-managed --record c:\docume~1\admini~1\locals~1\temp\pip-qqb1ax-record\install-record.txt failed with error code 1
Storing complete log in C:\Documents and Settings\Administrator\Application Data\pip\pip.log

Pavel's patch fixes my build.  Does this patch break something else?  I can reproduce this on 2.7 and 2.6.6.

----------
nosy: +David.Joy
versions: +Python 2.7 -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Fri Oct 29 17:09:58 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 15:09:58 +0000
Subject: [issue4431] Distutils MSVC doesn't create manifest file (with fix)
In-Reply-To: <1288364363.38.0.986573316518.issue4431@psf.upfronthosting.co.za>
Message-ID: <4CCAE3BE.4050306@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Hi David,

since both you and Pavel are building mysql-python and using
setuptools (which applies a lot of hacks on stock distutils),
could you please also try some other package from PyPI in that
same configuration and preferably one which doesn't rely on
setuptools ?

Adding the switch per default will probably not cause much harm,
except when you explicitly don't want the manifest to be created
and added to the DLL (which is needed in some situations as as well).

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Fri Oct 29 17:14:00 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 15:14:00 +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: <1288365240.44.0.12520154177.issue4431@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


Removed file: http://bugs.python.org/file13126/unnamed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue4431>
_______________________________________

From report at bugs.python.org  Fri Oct 29 17:39:48 2010
From: report at bugs.python.org (Robert Lerche)
Date: Fri, 29 Oct 2010 15:39:48 +0000
Subject: [issue10232] Tkinter issues with Scrollbar and custom widget list
In-Reply-To: <1288366788.46.0.695886030233.issue10232@psf.upfronthosting.co.za>
Message-ID: <1288366788.46.0.695886030233.issue10232@psf.upfronthosting.co.za>


New submission from Robert Lerche <ral at msbit.com>:

I have run across several issues (one serious one, showing up only on Windows) when implementing a scroll bar with a list of custom widgets.

I suspect these may really be Tk issues but I thought I'd try posting here first.  I sent this to the tkinter-discuss list and saw no replies.

Please have a look and advise me on the right way to proceed.  Thanks.

----------
components: Tkinter
files: testcase.py
messages: 119907
nosy: Robert.Lerche
priority: normal
severity: normal
status: open
title: Tkinter issues with Scrollbar and custom widget list
type: behavior
versions: Python 2.7
Added file: http://bugs.python.org/file19412/testcase.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10232>
_______________________________________

From report at bugs.python.org  Fri Oct 29 17:40:56 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 15:40:56 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1288366856.48.0.449064438819.issue10225@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am attaching a new patch which fixes all but two doctest examples.

I suspect that the remaining failures are due to a bug in sphinx. (The examples are executed even though marked up with ::).

----------
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19413/issue10225a-r27.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Fri Oct 29 17:44:41 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 15:44:41 +0000
Subject: [issue10233] fix test_tarfile ResourceWarnings
In-Reply-To: <1288367081.73.0.870098966091.issue10233@psf.upfronthosting.co.za>
Message-ID: <1288367081.73.0.870098966091.issue10233@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This fixes all the warnings because of files not closed explicitly in test_tarfile.

----------
components: Library (Lib)
files: tarfileclose.patch
keywords: patch
messages: 119909
nosy: lars.gustaebel, pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: fix test_tarfile ResourceWarnings
type: resource usage
versions: Python 3.2
Added file: http://bugs.python.org/file19414/tarfileclose.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10233>
_______________________________________

From report at bugs.python.org  Fri Oct 29 17:50:46 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 15:50:46 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288367446.91.0.327296532344.issue10224@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> The usual build process via Makefile still uses Python 2,
> and that won't change for 3.2.

Would you consider changing "doctest" make target to check out sphinx trunk (or 3.x compatible release) and run it with the py3k python?

This should not affect regular doc builds and running doctest under anything other than the current version of python makes very little sense.

Note that I am still targeting documentation fixes for 3.2.  See issue 10225.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 17:54:48 2010
From: report at bugs.python.org (Sridhar Ratnakumar)
Date: Fri, 29 Oct 2010 15:54:48 +0000
Subject: [issue6645] multiprocessing build fails on AIX - /dev/urandom (or
	equivalent) not found
In-Reply-To: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
Message-ID: <1288367688.53.0.0927006207698.issue6645@psf.upfronthosting.co.za>


Sridhar Ratnakumar <sridharr at activestate.com> added the comment:

No, this is not an issue for me on Python 3.2 and AIX 5.1.

----------
versions:  -Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6645>
_______________________________________

From report at bugs.python.org  Fri Oct 29 18:01:16 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Oct 2010 16:01:16 +0000
Subject: [issue10229] Refleak run of test_gettext fails
In-Reply-To: <1288348294.62.0.0907397506052.issue10229@psf.upfronthosting.co.za>
Message-ID: <1288368076.3.0.117463929966.issue10229@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

Thanks for catching this.  Attached patch fixes the error with -R and works without -R too, please review.

----------
keywords: +needs review, patch
nosy: +loewis, v_peter
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19415/fix-10229.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10229>
_______________________________________

From report at bugs.python.org  Fri Oct 29 18:04:07 2010
From: report at bugs.python.org (Jesse Noller)
Date: Fri, 29 Oct 2010 16:04:07 +0000
Subject: [issue6645] multiprocessing build fails on AIX - /dev/urandom (or
	equivalent) not found
In-Reply-To: <1249414053.16.0.904107656211.issue6645@psf.upfronthosting.co.za>
Message-ID: <1288368247.28.0.538816050794.issue6645@psf.upfronthosting.co.za>


Jesse Noller <jnoller at gmail.com> added the comment:

Closing per Sridhar

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6645>
_______________________________________

From report at bugs.python.org  Fri Oct 29 18:10:31 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Fri, 29 Oct 2010 16:10:31 +0000
Subject: [issue10226] urlparse example is wrong
In-Reply-To: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>
Message-ID: <1288368631.22.0.624896315116.issue10226@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

// is not part of the netloc in RFC terms, it?s a delimiter between components

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10226>
_______________________________________

From report at bugs.python.org  Fri Oct 29 18:10:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 16:10:35 +0000
Subject: [issue10229] Refleak run of test_gettext fails
In-Reply-To: <1288368076.3.0.117463929966.issue10229@psf.upfronthosting.co.za>
Message-ID: <1288368628.3565.81.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> Thanks for catching this.  Attached patch fixes the error with -R and
> works without -R too, please review.

It looks good to me.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10229>
_______________________________________

From report at bugs.python.org  Fri Oct 29 18:27:31 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 16:27:31 +0000
Subject: [issue10234] ResourceWarnings in test_subprocess
In-Reply-To: <1288369651.8.0.988581354556.issue10234@psf.upfronthosting.co.za>
Message-ID: <1288369651.8.0.988581354556.issue10234@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Since r85920, test_subprocess has been showing a bunch of ResourceWarnings.
It seems that the pipe objects don't get explicitly closed in wait() or __del__, while they do in communicate().

----------
components: Library (Lib), Tests
messages: 119916
nosy: gregory.p.smith, pitrou
priority: normal
severity: normal
status: open
title: ResourceWarnings in test_subprocess
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10234>
_______________________________________

From report at bugs.python.org  Fri Oct 29 18:28:06 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 16:28:06 +0000
Subject: [issue10225] Fix doctest runable examples in python manual
In-Reply-To: <1288318735.45.0.959857258913.issue10225@psf.upfronthosting.co.za>
Message-ID: <1288369686.4.0.690054193901.issue10225@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I started porting the patch to 3.x and it looks like I've uncovered another bug in sphinx:

$ sphinx-build -b doctest -d build/doctrees  . build/doctest library/traceback.rst
..
**********************************************************************
File "library/traceback.rst", line 327, in default
..

Differences (ndiff with -expected +actual):
      *** print_tb:
    -   File "<doctest...>", line 10, in <module>
    ?                 ^^^
    +   File "<doctest default[0]>", line 10, in <module>
    ?                 ^^^^^^^^^^^
          lumberjack()

(I added +REPORT_NDIFF to testoutput options for clarity.)

I even tried adding +ELLIPSIS to options, but this did not help.  The same example works in 2.7.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10225>
_______________________________________

From report at bugs.python.org  Fri Oct 29 18:50:14 2010
From: report at bugs.python.org (Daniel Urban)
Date: Fri, 29 Oct 2010 16:50:14 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288371014.52.0.88974442522.issue10224@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/issue10224>
_______________________________________

From report at bugs.python.org  Fri Oct 29 19:03:32 2010
From: report at bugs.python.org (Guandalino)
Date: Fri, 29 Oct 2010 17:03:32 +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: <1288371812.44.0.564097614651.issue9340@psf.upfronthosting.co.za>


Changes by Guandalino <guandalino at gmail.com>:


----------
nosy: +guandalino

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9340>
_______________________________________

From report at bugs.python.org  Fri Oct 29 19:44:52 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 Oct 2010 17:44:52 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <1288374292.6.0.962506247133.issue9377@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I just did an experiment on Windows 7. I used SetComputerNameEx to set the NetBIOS name (4) to "e2718", and the DNS name (5) to "?3141"; then I rebooted. This is on a system with windows-1252 as its ANSI code page (i.e. u"?"==u"\N{GREEK SMALL LETTER PI}" is not in the ANSI charset.  After the reboot, I found

- COMPUTERNAME is "P3141", and so is the result of GetComputerNameEx(4)
- GetComputerNameEx(5) is "?3141"
- socket.gethostname of Python 2.5 returns "p3141".

So my theory of how this all fits together is this:

1. it's not really possible to completely decouple the DNS name and the NetBIOS name. Setting the DNS name also modifies the NetBIOS name; I suspect that the reverse is also true.

2. gethostname returns the ANSI version of the DNS name (which happens to convert the GREEK SMALL LETTER PI to a LATIN SMALL LETTER P).

3. the NetBIOS name is an generally an uppercase version of the gethostname result. There may be rules in case the gethostname result contains characters illegal in NetBIOS.

In summary, I (now) think it's fine to return the Unicode version of the DNS name from gethostname on Windows.

Re msg119271: the name "?3141" really has nothing to do with the DNS on my system. It doesn't occur in DNS any zone, nor could it possibly. It's unclear to me why Microsoft calls it the "DNS name".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Fri Oct 29 19:57:42 2010
From: report at bugs.python.org (Sandro Tosi)
Date: Fri, 29 Oct 2010 17:57:42 +0000
Subject: [issue7547] test_timeout should skip, not fail,
	when the remote host is not available
In-Reply-To: <1261241104.77.0.599570179128.issue7547@psf.upfronthosting.co.za>
Message-ID: <1288375062.97.0.203822324888.issue7547@psf.upfronthosting.co.za>


Sandro Tosi <sandro.tosi at gmail.com> added the comment:

Hello,
as discussed on irc, I'm proposing a patch that:

- wraps the test with support.transient_internet
- limits the assert to only socket.timeout (what we want to test)

test_smptnet.py is already fixed, since it already uses support.transient_internet

Regards,
Sandro

----------
keywords: +patch
nosy: +sandro.tosi
stage: needs patch -> patch review
Added file: http://bugs.python.org/file19416/issue7547-py3k.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7547>
_______________________________________

From report at bugs.python.org  Fri Oct 29 19:58:56 2010
From: report at bugs.python.org (Tomas Hoger)
Date: Fri, 29 Oct 2010 17:58:56 +0000
Subject: [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1288375136.0.0.0119420146978.issue8678@psf.upfronthosting.co.za>


Tomas Hoger <thoger at redhat.com> added the comment:

You seem to be right that r65878 should block the "xsize = ysize = 0x8000" integer overflow.  I was testing on the python version with r60793, but not with r65878.  Note that the check added in r65878 should still cause crash on divide-by-zero for some files.

Attaching my test files. 1 is for excessive ZSIZE, 2 and 3 for the integer overflow, RLE and non-RLE code path, 4 and 5 for RLE decoding issues.  6 should trigger sigfpe in the r65878 check as noted above, but I've not really tested that one.

----------
Added file: http://bugs.python.org/file19417/rgbimg-issue8678.tgz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8678>
_______________________________________

From report at bugs.python.org  Fri Oct 29 20:03:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 18:03:41 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288375421.78.0.577976316799.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Committed issue7061a.diff r85930.  This is probably a backport candidate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Fri Oct 29 20:14:53 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 18:14:53 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288376093.65.0.39345844345.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

While working on issue 10225, I have found several mistakes in turtle.rst examples.  It probably makes sense to review these separately and commit as part of this issue rather than bunching with the other issue 10225 changes.

There are still two remaining failures that I attribute to sphinx bugs.  One is due to an already reported ellipsis bug, and the other is a rather strange failure in the shapetransform example.

Georg, can you take a look?

File "library/turtle.rst", line 1272, in default
Failed example:
    turtle.shapetransform()
Expected:
    (4.0, -1.0, -0.0, 2.0)
Got:
    (2.82842712474619, -2.121320343559643, 2.8284271247461907, 0.7071067811865472)


Note that this test succeeds when it is the only test in a file.

----------
Added file: http://bugs.python.org/file19418/issue7061b.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Fri Oct 29 20:16:41 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 18:16:41 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288376201.28.0.767606783598.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Gregor,

I suspect that there are doctest mistakes in the turtle.py docstrings, but I cannot figure out how to run it through doctest.  Can you help?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Fri Oct 29 20:17:47 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 18:17:47 +0000
Subject: [issue7547] test_timeout should skip, not fail,
	when the remote host is not available
In-Reply-To: <1261241104.77.0.599570179128.issue7547@psf.upfronthosting.co.za>
Message-ID: <1288376267.37.0.366098565398.issue7547@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85931 (3.2), r85932 (3.1) and r85933 (2.7).

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7547>
_______________________________________

From report at bugs.python.org  Fri Oct 29 20:22:42 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 Oct 2010 18:22:42 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <1288376562.86.0.210441247954.issue9377@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

r85934 now uses GetComputerNameExW on Windows.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Fri Oct 29 20:29:30 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Oct 2010 18:29:30 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288376970.68.0.96421020893.issue7061@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As I suspected, the turtle.shapetransform() stems from sphinx' failure to reinitialize the turtle variable as testsetup dictates.  I can work around this by adding 

      >>> turtle = Turtle()

above

      >>> turtle.shape("square")
      >>> turtle.shapesize(4,2)
      >>> turtle.shearfactor(-0.5)
      >>> turtle.shapetransform()
      (4.0, -1.0, -0.0, 2.0)

but I don't think it is a good idea to pollute the documentation this way.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Fri Oct 29 20:33:17 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 18:33:17 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1288374292.6.0.962506247133.issue9377@psf.upfronthosting.co.za>
Message-ID: <4CCB1368.30608@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> 
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> I just did an experiment on Windows 7. I used SetComputerNameEx to set the NetBIOS name (4) to "e2718", and the DNS name (5) to "?3141"; then I rebooted. This is on a system with windows-1252 as its ANSI code page (i.e. u"?"==u"\N{GREEK SMALL LETTER PI}" is not in the ANSI charset.  After the reboot, I found
> 
> - COMPUTERNAME is "P3141", and so is the result of GetComputerNameEx(4)
> - GetComputerNameEx(5) is "?3141"
> - socket.gethostname of Python 2.5 returns "p3141".
> 
> So my theory of how this all fits together is this:
> 
> 1. it's not really possible to completely decouple the DNS name and the NetBIOS name. Setting the DNS name also modifies the NetBIOS name; I suspect that the reverse is also true.

The MS docs mention that setting the DNS name will adjust the NetBIO name
as well (with the NetBIOS name being converted to upper case and truncated,
if the DNS name is too long).

They don't mention anything about the NetBIOS name encoding.

> 2. gethostname returns the ANSI version of the DNS name (which happens to convert the GREEK SMALL LETTER PI to a LATIN SMALL LETTER P).
> 
> 3. the NetBIOS name is an generally an uppercase version of the gethostname result. There may be rules in case the gethostname result contains characters illegal in NetBIOS.
> 
> In summary, I (now) think it's fine to return the Unicode version of the DNS name from gethostname on Windows.
> 
> Re msg119271: the name "?3141" really has nothing to do with the DNS on my system. It doesn't occur in DNS any zone, nor could it possibly. It's unclear to me why Microsoft calls it the "DNS name".

The DNS name of the Windows machine is the combination of the DNS host
name and the DNS domain that you setup on the machine. I think the
misunderstanding is that you assume this combination will
somehow appear as known DNS name of the machine via some
DNS server on the network - that's not the case.

Of course, it's not particularly useful to set the DNS name to
something that other machines cannot find out via an DNS query.

FWIW, you can do the same on a Linux box, i.e. setup the host name
and domain to some completely bogus values. And as David pointed out,
without also updating the /etc/hosts on the Linux, you always get the
resolver error with hostname -f I mentioned earlier on (which does
a DNS lookup), so there's no real connection to the DNS system on
Linux either.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Fri Oct 29 21:04:46 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 19:04:46 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1288376562.86.0.210441247954.issue9377@psf.upfronthosting.co.za>
Message-ID: <4CCB1AC9.1080802@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:
> 
> r85934 now uses GetComputerNameExW on Windows.

Thanks, Martin.

Here's a similar discussion of the Windows approach (used in bzr):

https://bugs.launchpad.net/bzr/+bug/256550/comments/6

This is what Solaris uses:

http://developers.sun.com/dev/gadc/faq/locale.html#get-set

(they require conversion to ASCII and using IDNA for non-ASCII
names)

I found this RFC draft on the topic:
http://tools.ietf.org/html/draft-josefsson-getaddrinfo-idn-00
which suggests that there is no standard for the encoding
used by the socket host name APIs yet.

ASCII, UTF-8 and IDNA are happily mixed and matched.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Fri Oct 29 21:17:41 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Oct 2010 19:17:41 +0000
Subject: [issue8678] crashers in rgbimg
In-Reply-To: <1273526642.93.0.89259252042.issue8678@psf.upfronthosting.co.za>
Message-ID: <1288379861.41.0.06734157694.issue8678@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
nosy:  -brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue8678>
_______________________________________

From report at bugs.python.org  Fri Oct 29 21:31:49 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 Oct 2010 19:31:49 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <1288380709.74.0.466886933256.issue9377@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The Solaris case then is already supported, with no change required: if Solaris bans non-ASCII in the network configuration (or, rather, recommends to use IDNA), then this will work fine with the current code.

The Josefsson AI_IDN flag is irrelevant to Python, IMO: it treats byte names as locale-encoded, and converts them with IDNA. Python 3 users really should use Unicode strings in the first place for non-ASCII data, in which case the socket.getaddrinfo uses IDNA, anyway. However, it can't hurt to expose this flag if the underlying C library supports it. AI_CANONIDN might be interesting to implement, but I'd rather wait whether this finds RFC approval. In any case, undoing IDNA is orthogonal to this issue (which is about non-ASCII data returned from the socket API).

If anything needs to be done on Unix, I think that the gethostname result should be decoded using the file system encoding; I then don't mind using surrogate escape there for good measure. This won't hurt systems that restrict host names to ASCII, and may do some good for systems that don't.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Fri Oct 29 21:34:16 2010
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Oct 2010 19:34:16 +0000
Subject: [issue10230] test_tarfile failure (test_extractall) on AMD64 debian
	parallel 3.x: os.utime(float) issue
In-Reply-To: <1288354101.14.0.267054038013.issue10230@psf.upfronthosting.co.za>
Message-ID: <1288380856.85.0.207892298155.issue10230@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> tarfile touches directories twice

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10230>
_______________________________________

From report at bugs.python.org  Fri Oct 29 21:36:47 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 29 Oct 2010 19:36: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: <1288381007.7.0.0247105820283.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

That's a bug. I'll fix it as soon has I've reinstalled the SDK. <sigh/>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Fri Oct 29 21:43:35 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 19:43:35 +0000
Subject: [issue10235] test_argparse depends on the COLUMNS environment variable
In-Reply-To: <1288381415.18.0.712134871651.issue10235@psf.upfronthosting.co.za>
Message-ID: <1288381415.18.0.712134871651.issue10235@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

Changing it can produce failures, e.g.:

$ COLUMNS=178 ./python -m test.regrtest -v test_argparse

This can be seen on one of the buildbots:
http://www.python.org/dev/buildbot/all/builders/PPC%20Leopard%203.x/builds/685/steps/test/logs/stdio

----------
assignee: bethard
components: Tests
messages: 119931
nosy: bethard, janssen, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: test_argparse depends on the COLUMNS environment variable
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10235>
_______________________________________

From report at bugs.python.org  Fri Oct 29 21:46:55 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Fri, 29 Oct 2010 19:46:55 +0000
Subject: [issue10236] Sporadic failures of test_ssl
In-Reply-To: <1288381615.12.0.769531001166.issue10236@psf.upfronthosting.co.za>
Message-ID: <1288381615.12.0.769531001166.issue10236@psf.upfronthosting.co.za>


New submission from Stephen Hansen <me+python at ixokai.io>:

Another sporadic failure I've noticed since setting up my buildbot; test_ssl keeps going down. This one I have a hard time analyzing with the tests output, but the latest is: 
http://www.python.org/dev/buildbot/all/builders/x86%20Snow%20Leopard%203.x/builds/250

There's this part in the log:

test_get_server_certificate (test.test_ssl.NetworkedTests) ... [Errno 1] _ssl.c:390: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Verified certificate for svn.python.org:443 is
[...pem...]
ok

There's an errno printed there, but then more debugging for that same test-- and an 'ok'-- so I don't see the FAIL message I'm expecting. So to my naive reading, it seems that it is running once and failing, then re-running in verbose and /not/ failing (and that the error-like message there may not be an error). So, the original problem is a mystery.

Or I'm totally reading it wrong. Either way, I've seen this several times and am not sure how to further debug it. Any suggestions or pointers are welcome. Or fixes :)

----------
messages: 119932
nosy: ixokai
priority: normal
severity: normal
status: open
title: Sporadic failures of test_ssl
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10236>
_______________________________________

From report at bugs.python.org  Fri Oct 29 21:49:52 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Fri, 29 Oct 2010 19:49:52 +0000
Subject: [issue10236] Sporadic failures of test_ssl
In-Reply-To: <1288381615.12.0.769531001166.issue10236@psf.upfronthosting.co.za>
Message-ID: <1288381792.39.0.634431197916.issue10236@psf.upfronthosting.co.za>


Changes by Stephen Hansen <me+python at ixokai.io>:


----------
components: +Library (Lib), Tests
type:  -> behavior

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10236>
_______________________________________

From report at bugs.python.org  Fri Oct 29 21:53:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 19:53:40 +0000
Subject: [issue10235] test_argparse depends on the COLUMNS environment variable
In-Reply-To: <1288381415.18.0.712134871651.issue10235@psf.upfronthosting.co.za>
Message-ID: <1288382020.14.0.882710830372.issue10235@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Already reported actually.

----------
resolution:  -> duplicate
status: open -> closed
superseder:  -> test_argparse.py: 80 failures if COLUMNS env var set to a value other than 80

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10235>
_______________________________________

From report at bugs.python.org  Fri Oct 29 21:54:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 19:54:05 +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: <1288382045.48.0.395328074418.issue9553@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As noted in issue10235, this is responsible for buildbot failures:
http://www.python.org/dev/buildbot/all/builders/PPC%20Leopard%203.x/builds/685/steps/test/logs/stdio

----------
nosy: +janssen, pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9553>
_______________________________________

From report at bugs.python.org  Fri Oct 29 22:09:05 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 29 Oct 2010 20:09:05 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1288380709.74.0.466886933256.issue9377@psf.upfronthosting.co.za>
Message-ID: <4CCB29DD.6090502@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:
> 
> The Solaris case then is already supported, with no change required: if Solaris bans non-ASCII in the network configuration (or, rather, recommends to use IDNA), then this will work fine with the current code.
> 
> The Josefsson AI_IDN flag is irrelevant to Python, IMO: it treats byte names as locale-encoded, and converts them with IDNA. Python 3 users really should use Unicode strings in the first place for non-ASCII data, in which case the socket.getaddrinfo uses IDNA, anyway. However, it can't hurt to expose this flag if the underlying C library supports it. AI_CANONIDN might be interesting to implement, but I'd rather wait whether this finds RFC approval. In any case, undoing IDNA is orthogonal to this issue (which is about non-ASCII data returned from the socket API).
> 
> If anything needs to be done on Unix, I think that the gethostname result should be decoded using the file system encoding; I then don't mind using surrogate escape there for good measure. This won't hurt systems that restrict host names to ASCII, and may do some good for systems that don't.

Wouldn't it be better to also attempt to decode the name using IDNA
in case the name starts with the IDNA prefix ?

This would then also cover the Solaris case.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Fri Oct 29 22:48:46 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Oct 2010 20:48:46 +0000
Subject: [issue10177] PyUnicode_AsWideCharString and PyMem_Free
In-Reply-To: <1287836498.58.0.900203329868.issue10177@psf.upfronthosting.co.za>
Message-ID: <1288385326.33.0.636472155107.issue10177@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I think questions like this are better answered on python-list or even pydev.

In the absence of an observed problem, I would presume it is ok.

This question should be answered in the C-API doc. If it is not, you could reopen this as a doc issue.

----------
nosy: +terry.reedy
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10177>
_______________________________________

From report at bugs.python.org  Fri Oct 29 23:02:26 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Oct 2010 21:02:26 +0000
Subject: [issue10188] tempfile.TemporaryDirectory may throw errors at shutdown
In-Reply-To: <1287917580.57.0.982180579105.issue10188@psf.upfronthosting.co.za>
Message-ID: <1288386146.15.0.717939259679.issue10188@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Shutdown has been a 'forever' problem ;-). It would seem sensible to me to have a fixed end-of-shutdown sequence for essential modules.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10188>
_______________________________________

From report at bugs.python.org  Fri Oct 29 23:34:39 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Oct 2010 21:34:39 +0000
Subject: [issue6105] json.dumps doesn't respect OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1288388079.97.0.0656930205068.issue6105@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

Upon further consideration, I think this could be backported.

----------
assignee: benjamin.peterson -> rhettinger
resolution: wont fix -> 
status: closed -> open

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

From report at bugs.python.org  Sat Oct 30 00:03:36 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Oct 2010 22:03:36 +0000
Subject: [issue10212] struct.unpack and cStringIO.StringIO don't support new
	buffer
In-Reply-To: <1288175813.33.0.0310491559114.issue10212@psf.upfronthosting.co.za>
Message-ID: <1288389816.45.0.793996067045.issue10212@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

In the absence of doc references in this and #10211 that would *clearly* settle the bug vs. feature issue, it strikes me as a bit murky. So I am inclined to agree with MAL that failure to achieve the stated, documented purpose is a bug. I strongly suspect that if these issues had been filed during the 2.7 beta phase, a fix would have been deemed permissible without much controversy.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10212>
_______________________________________

From report at bugs.python.org  Sat Oct 30 00:10:44 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 29 Oct 2010 22:10:44 +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: <1288390244.33.0.216017495664.issue10232@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I have not tried your testcase yet, but agree that issue 4 sounds pretty bad. I guess what you are looking for is either a patch to tkinter that solves at least one of the listed problems (even if only a workaround for a TK bug) or a determination that nothing can be done.

----------
nosy: +terry.reedy

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10232>
_______________________________________

From report at bugs.python.org  Sat Oct 30 00:25:24 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 Oct 2010 22:25:24 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <4CCB1368.30608@egenix.com>
Message-ID: <4CCB49D1.9010204@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> The DNS name of the Windows machine is the combination of the DNS host
> name and the DNS domain that you setup on the machine. I think the
> misunderstanding is that you assume this combination will
> somehow appear as known DNS name of the machine via some
> DNS server on the network - that's not the case.

I don't assume that - I merely point it that it clearly has no
relationship to the DNS (unless you explicitly make it that way).
So, I wonder why they call it the DNS name - they could have just
as well called the "LDAP name", or the "NIS name". In either case,
setting the name would have no impact on the respective naming
infrastructure.

> FWIW, you can do the same on a Linux box, i.e. setup the host name
> and domain to some completely bogus values. And as David pointed out,
> without also updating the /etc/hosts on the Linux, you always get the
> resolver error with hostname -f I mentioned earlier on (which does
> a DNS lookup), so there's no real connection to the DNS system on
> Linux either.

Yes, but Linux (rightly) calls it the "hostname", not the "DNS name".

----------
title: socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Sat Oct 30 00:25:43 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 22:25:43 +0000
Subject: [issue10237] failure in Barrier tests
In-Reply-To: <1288391142.98.0.44997335021.issue10237@psf.upfronthosting.co.za>
Message-ID: <1288391142.98.0.44997335021.issue10237@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

A buildbot has shows occasional failures in the Barrier tests:

[299/349] test_threading
[39130 refs]
[39501 refs]
[39501 refs]
[39491 refs]
[39499 refs]
Unhandled exception in thread started by <function task at 0x45e4df54>
Traceback (most recent call last):
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 37, in task
    f()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 704, in f
    i = self.barrier.wait()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 441, in wait
    self._enter() # Block while the barrier drains.
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 465, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
Unhandled exception in thread started by <function task at 0x45e4df54>
Traceback (most recent call last):
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 37, in task
    f()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 704, in f
    i = self.barrier.wait()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 441, in wait
    self._enter() # Block while the barrier drains.
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 465, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
Unhandled exception in thread started by <function task at 0x45e4df54>
Traceback (most recent call last):
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 37, in task
    f()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 704, in f
    i = self.barrier.wait()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 441, in wait
    self._enter() # Block while the barrier drains.
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 465, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
Unhandled exception in thread started by <function task at 0x45e4df54>
Traceback (most recent call last):
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 37, in task
    f()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 704, in f
    i = self.barrier.wait()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 441, in wait
    self._enter() # Block while the barrier drains.
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 465, in _enter
    raise BrokenBarrierError
threading.BrokenBarrierError
test test_threading failed -- Traceback (most recent call last):
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 720, in test_reset
    self.run_threads(f)
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 615, in run_threads
    f()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/test/lock_tests.py", line 704, in f
    i = self.barrier.wait()
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 450, in wait
    self._wait(timeout)
  File "/home/buildslave/python-trunk/3.x.norwitz-x86/build/Lib/threading.py", line 489, in _wait
    raise BrokenBarrierError
threading.BrokenBarrierError

----------
assignee: krisvale
components: Library (Lib), Tests
messages: 119942
nosy: krisvale, pitrou
priority: normal
severity: normal
stage: needs patch
status: open
title: failure in Barrier tests
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10237>
_______________________________________

From report at bugs.python.org  Sat Oct 30 00:26:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Fri, 29 Oct 2010 22:26:54 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <4CCB29DD.6090502@egenix.com>
Message-ID: <4CCB4A2B.7080800@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Wouldn't it be better to also attempt to decode the name using IDNA
> in case the name starts with the IDNA prefix ?

Perhaps better - but incompatible. I don't see a way to have the
resolver functions automatically decode IDNA, without potentially
breaking existing applications that specifically look for the
IDNA prefix (say).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Sat Oct 30 00:27:12 2010
From: report at bugs.python.org (Robert Lerche)
Date: Fri, 29 Oct 2010 22:27:12 +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: <1288391232.76.0.294987789339.issue10232@psf.upfronthosting.co.za>


Robert Lerche <ral at msbit.com> added the comment:

Hi and thanks for the quick response.

I'm happy to follow up with the Tk folks if it turns out that's where
the problem lies -- it has been a long time since I wrote a Tcl script
so before trying to reproduce the behavior that way I thought I'd try
posting what I have so far.

If you can just confirm that the behavior is reproducible that would
be a good start.  As I wrote, I have built everything from sources on
Windows so there's always a chance I've done something wrong, although
so much is working correctly that I don't expect that to be the case.

I'm trying to introduce Python as a development tool at a consulting
client (a large company) so I have to pursue stuff like this.

Thanks again.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10232>
_______________________________________

From report at bugs.python.org  Sat Oct 30 00:27:55 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Oct 2010 22:27:55 +0000
Subject: [issue10238] ctypes not building under OS X 10.6 with LLVM/Clang 2.8
In-Reply-To: <1288391275.39.0.918201255477.issue10238@psf.upfronthosting.co.za>
Message-ID: <1288391275.39.0.918201255477.issue10238@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

I get the following output related to the build failure:


/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:153:2: error: unrecognized instruction
 cmovnz %rax, %rdx
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:154:2: error: unrecognized instruction
 cmovnz %r10, %rax
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:156:2: error: unrecognized instruction
 cmovnz %r10, %rdx
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:158:2: error: unrecognized instruction
 cmovnz %r10, %rax
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:159:2: error: unrecognized instruction
 cmovnz %r11, %rdx
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:166:2: error: unrecognized instruction
 rep movsb
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:281:2: error: unrecognized instruction
 cmovnz %rdx, %rcx
 ^
/var/folders/MN/MN-E3HgoFXSKDXb9le7FQ++++TI/-Tmp-/cc-MxvLE7.s:285:2: error: unrecognized instruction
 cmovnz %rdx, %rax
 ^

----------
components: Build
messages: 119945
nosy: brett.cannon
priority: deferred blocker
severity: normal
status: open
title: ctypes not building under OS X 10.6 with LLVM/Clang 2.8
type: compile error
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10238>
_______________________________________

From report at bugs.python.org  Sat Oct 30 00:29:04 2010
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 29 Oct 2010 22:29:04 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <1280082784.57.0.628810673592.issue9377@psf.upfronthosting.co.za>
Message-ID: <1288391344.91.0.455071093168.issue9377@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The code in socketmodule.c currently compile with suspect warnings:

socketmodule.c(3108) : warning C4047: 'function' : 'LPSTR' differs in levels of indirection from 'int'
socketmodule.c(3108) : warning C4024: 'GetComputerNameA' : different types for formal and actual parameter 1
socketmodule.c(3109) : warning C4133: 'function' : incompatible types - from 'Py_UNICODE *' to 'LPDWORD'
socketmodule.c(3110) : warning C4020: 'GetComputerNameA' : too many actual parameters

was GetComputerName() used instead of GetComputerNameExW()?

----------
nosy: +amaury.forgeotdarc

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Sat Oct 30 00:33:09 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Fri, 29 Oct 2010 22:33:09 +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: <1288391589.65.0.60028908957.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101029.zip is a new version of the regex module.

I've also added to the unit tests.

----------
Added file: http://bugs.python.org/file19419/issue2636-20101029.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Oct 30 01:10:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 23:10:51 +0000
Subject: [issue10233] fix test_tarfile ResourceWarnings
In-Reply-To: <1288367081.73.0.870098966091.issue10233@psf.upfronthosting.co.za>
Message-ID: <1288393851.55.0.558191209201.issue10233@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10233>
_______________________________________

From report at bugs.python.org  Sat Oct 30 01:16:55 2010
From: report at bugs.python.org (Neal Becker)
Date: Fri, 29 Oct 2010 23:16:55 +0000
Subject: [issue10239] multiprocessing signal defect
In-Reply-To: <1288394215.77.0.548546453829.issue10239@psf.upfronthosting.co.za>
Message-ID: <1288394215.77.0.548546453829.issue10239@psf.upfronthosting.co.za>


New submission from Neal Becker <ndbecker2 at gmail.com>:

multiprocessing signal defect
From:
Neal Becker <ndbecker2 at gmail.com>
  Date:
Friday 29 October 2010 8:12:19 am
  To:
python-list at python.org
  Groups:
gmane.comp.python.general

Tested on:
python-2.6.4-27.fc13.x86_64
linux fedora 13 x86_64

Seems multiprocessing doesn't behave well with signals:

-----------
from multiprocessing import Pool
import time

def sleep (dummy):
????time.sleep (10)
????
if __name__ == '__main__':
????pool = Pool (processes=2)
????result = pool.map (sleep, range (4))
????
-------------

start it up
$ python test_multip.py?

----------------------
ps auxf | grep python
nbecker???6605??1.6??0.1 338192??6952 pts/1????Sl+??08:03???0:00??|???????\_?
python test_multip.py
nbecker???6606??0.0??0.1 186368??4760 pts/1????S+???08:03???0:00??|???????????
\_ python test_multip.py
nbecker???6607??0.0??0.1 186372??4740 pts/1????S+???08:03???0:00??|???????????
\_ python test_multip.py

kill 6607
?ps auxf | grep python
nbecker???6605??0.5??0.1 338192??6952 pts/1????Sl+??08:03???0:00??|???????\_?
python test_multip.py
nbecker???6606??0.0??0.1 186368??4760 pts/1????S+???08:03???0:00??|???????????
\_ python test_multip.py
nbecker???6607??0.0??0.0??????0?????0 pts/1????Z+???08:03???0:00??|???????????
\_ [python] <defunct>

?kill 6606
ps auxf | grep python
nbecker???6605??0.3??0.1 338192??6952 pts/1????Sl+??08:03???0:00??|???????\_?
python test_multip.py
nbecker???6606??0.0??0.0??????0?????0 pts/1????Z+???08:03???0:00??|???????????
\_ [python] <defunct>
nbecker???6607??0.0??0.0??????0?????0 pts/1????Z+???08:03???0:00??|???????????
\_ [python] <defunct>

Now we have 2 dead children and the parent is hung forever.

Isn't this a serious defect?

----------
components: Library (Lib)
messages: 119948
nosy: Neal.Becker
priority: normal
severity: normal
status: open
title: multiprocessing signal defect
type: behavior
versions: Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10239>
_______________________________________

From report at bugs.python.org  Sat Oct 30 01:39:10 2010
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 29 Oct 2010 23:39:10 +0000
Subject: [issue10233] fix test_tarfile ResourceWarnings
In-Reply-To: <1288367081.73.0.870098966091.issue10233@psf.upfronthosting.co.za>
Message-ID: <1288395550.61.0.389189526063.issue10233@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Reviewed at http://codereview.appspot.com/2759042/

----------
assignee:  -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10233>
_______________________________________

From report at bugs.python.org  Sat Oct 30 01:50:32 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 29 Oct 2010 23:50:32 +0000
Subject: [issue10233] fix test_tarfile ResourceWarnings
In-Reply-To: <1288367081.73.0.870098966091.issue10233@psf.upfronthosting.co.za>
Message-ID: <1288396232.91.0.00254084044478.issue10233@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Thanks for the review. I've committed a modified patch in r85955.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10233>
_______________________________________

From report at bugs.python.org  Sat Oct 30 02:01:47 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Oct 2010 00:01:47 +0000
Subject: [issue6105] json.dumps doesn't respect OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1288396907.67.0.333683243675.issue6105@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
priority: normal -> high

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

From report at bugs.python.org  Sat Oct 30 02:28:45 2010
From: report at bugs.python.org (Rafe Kettler)
Date: Sat, 30 Oct 2010 00:28:45 +0000
Subject: [issue9702] Python violates most users expectations via the
	modification differences of immutable and mutable objects in methods
In-Reply-To: <1282917207.25.0.718078039013.issue9702@psf.upfronthosting.co.za>
Message-ID: <1288398525.84.0.572112217568.issue9702@psf.upfronthosting.co.za>


Changes by Rafe Kettler <rafe.kettler at gmail.com>:


----------
nosy: +rafe.kettler

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9702>
_______________________________________

From report at bugs.python.org  Sat Oct 30 02:48:17 2010
From: report at bugs.python.org (Jacques Grove)
Date: Sat, 30 Oct 2010 00:48:17 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1288399697.42.0.325281509628.issue2636@psf.upfronthosting.co.za>


Jacques Grove <jacques at tripitinc.com> added the comment:

Here's another inconsistency (same setup as before, running issue2636-20101029.zip code):

$ cat test.py
import re, regex

text = "\n  S"

regexp = '[^a]{2}[A-Z]'
print re.findall(regexp, text)
print regex.findall(regexp, text)

$ python test.py
['  S']
[]


I might flush out some more as I excercise this over the next few days.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Oct 30 03:50:57 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Oct 2010 01:50:57 +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: <1288403457.18.0.672713866892.issue10232@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I ran testcase.py with stock 3.1.2 on winxp (under IDLE).
Changes needed (one place each) were
Tkinter -> tkinter
print x -> print(x)
<>      -> !=    # <> is long since deprecated!

I get 3 line box windowing 10 lines. If I enlarge window, there are still only 3 lines displayed.

With triangle arrows at top and bottom of scroll bar box, I can scroll up and down a line at a time, with lines 1 to 8 at top. Nothing prints. There is a slight flash with redisplay.

With click and move on scroll bar itself, I can get down to where line 4 is at the top. Motion is not really jerky, rather it jumps one line at a time, just as with triangles. Going farther, box goes crazy flashing. When I unclick mouse, it settles all the way down with line 8 on box. Repetitious print looks like
0.4 0.4 4
0.7001 0.7001 7
0.4334 0.4334 4
0.7 0.7 7
0.4333 0.4333 4
0.7 0.7 7
...
So confirmed behavior is, if anything, worse. Just to make sure that print was not causing a problem, I commented it out and got same behavior.

I do not know enough tkinter (tk) to know if there is a bug in your code. I recommend posting to python-list, subject: Problem with tkinter box, with this link and short explanation. There are some people there who know tkinter much better than me who might comment.

----------
versions: +Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10232>
_______________________________________

From report at bugs.python.org  Sat Oct 30 03:52:55 2010
From: report at bugs.python.org (Michael Foord)
Date: Sat, 30 Oct 2010 01:52:55 +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: <1288403575.22.0.422813625298.issue7911@psf.upfronthosting.co.za>


Michael Foord <michael at voidspace.org.uk> added the comment:

I intend to.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7911>
_______________________________________

From report at bugs.python.org  Sat Oct 30 04:00:19 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Oct 2010 02:00:19 +0000
Subject: [issue10239] multiprocessing signal defect
In-Reply-To: <1288394215.77.0.548546453829.issue10239@psf.upfronthosting.co.za>
Message-ID: <1288404019.93.0.679500184479.issue10239@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/issue10239>
_______________________________________

From report at bugs.python.org  Sat Oct 30 04:34:08 2010
From: report at bugs.python.org (ivank)
Date: Sat, 30 Oct 2010 02:34:08 +0000
Subject: [issue10240] dict.update.__doc__ is misleading
In-Reply-To: <1288406048.13.0.615215732385.issue10240@psf.upfronthosting.co.za>
Message-ID: <1288406048.13.0.615215732385.issue10240@psf.upfronthosting.co.za>


New submission from ivank <bugs at ludios.org>:

It would be nice if dict.update.__doc__ conveyed some of the subtleties of the update algorithm.  See the patch.  I changed __doc__ to mention the fast path for dicts, and changed one instance of E: -> E.keys():

----------
components: Interpreter Core
files: dict.update.__doc__.patch
keywords: patch
messages: 119954
nosy: ivank
priority: normal
severity: normal
status: open
title: dict.update.__doc__ is misleading
versions: Python 2.5, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file19420/dict.update.__doc__.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10240>
_______________________________________

From report at bugs.python.org  Sat Oct 30 04:43:25 2010
From: report at bugs.python.org (Dev Player)
Date: Sat, 30 Oct 2010 02:43:25 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1288406605.94.0.342961048356.issue10060@psf.upfronthosting.co.za>


Dev Player <devplayer at gmail.com> added the comment:

Another thing I've noticed that makes the issue more complicated (or perhaps less complicated depending on your view).

When running the python.exe at the DOS prompt (in a window on WinXP), then issuing the help() then modules commands, python.exe seems to hang at times, when it doesn't crash. However this apparent hang sometimes seems to be related to the attached "help" child window/dialog popup instantating with "focus" behind the DOS window. This popup with the focus (and behind it's parent window and being modal) prevents the mouse from moving the DOS window (holding the running python.exe) from being moved.  The -sometimes- solution to this "apparent" hang is ALT-TAB back to the DOS window which will put the help-modal-dialog on top of said DOS window (which is running Python).

----------
Added file: http://bugs.python.org/file19421/python_help_modules_help_dialog.png

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Sat Oct 30 05:39:08 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 30 Oct 2010 03:39:08 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1288409948.27.0.394689414901.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101030.zip is a new version of the regex module.

I've also added yet more to the unit tests.

----------
Added file: http://bugs.python.org/file19422/issue2636-20101030.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Oct 30 05:48:50 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Sat, 30 Oct 2010 03:48:50 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

I'm trying implement some saner module shutdown procedure (similar to issue 812369).  One of the many problems I've run into is that the GC doesn't know about the m_copy attribute of modules. 

I think the attached patch is correct.  tp_tranverse exposes m_copy if it is non-NULL.  tp_clear calls Py_CLEAR on it.

----------
assignee: loewis
components: Interpreter Core
files: module_m_copy.txt
messages: 119957
nosy: benjamin.peterson, loewis, nascheme
priority: normal
severity: normal
status: open
title: gc fixes for module m_copy attribute
type: behavior
Added file: http://bugs.python.org/file19423/module_m_copy.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10241>
_______________________________________

From report at bugs.python.org  Sat Oct 30 06:40:21 2010
From: report at bugs.python.org (Jacques Grove)
Date: Sat, 30 Oct 2010 04:40:21 +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: <1288413621.76.0.149968163747.issue2636@psf.upfronthosting.co.za>


Jacques Grove <jacques at tripitinc.com> added the comment:

And another (with issue2636-20101030.zip):

$ cat test.py 
import re, regex
text = "XYABCYPPQ\nQ DEF"
regexp = 'X(Y[^Y]+?){1,2}(\ |Q)+DEF'
print re.findall(regexp, text)
print regex.findall(regexp, text)

$ python test.py 
[('YPPQ\n', ' ')]
[]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Oct 30 07:18:00 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sat, 30 Oct 2010 05:18:00 +0000
Subject: [issue10237] failure in Barrier tests
In-Reply-To: <1288391142.98.0.44997335021.issue10237@psf.upfronthosting.co.za>
Message-ID: <1288415880.13.0.652532244374.issue10237@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

This is a timeout issue, probably encountered on a slow machine.
Checked in revision 85964 increasing the default timeout to cater to slower machines.

However, I also see that the timeout mechanism used by barrier isn't very robust.  I'll submit a patch with a suggested change soon.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10237>
_______________________________________

From report at bugs.python.org  Sat Oct 30 07:26:12 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Oct 2010 05:26:12 +0000
Subject: [issue10242] unittest's assertItemsEqual() method makes too many
	assumptions about its input
In-Reply-To: <1288416372.65.0.387803067469.issue10242@psf.upfronthosting.co.za>
Message-ID: <1288416372.65.0.387803067469.issue10242@psf.upfronthosting.co.za>


New submission from Raymond Hettinger <rhettinger at users.sourceforge.net>:

class T(unittest.TestCase):
    def test_items_equal(self):
        # this test fails, but should succeed
        a = [{2,4}, {1,2}]
        b = a[::-1]
        self.assertItemsEqual(a, b)

This method has a fast-path using sorted() and a slow-path that doesn't care about cross-type comparisons.  The fast-path is incorrect though and gets the wrong answer in the above test case.

----------
assignee: michael.foord
messages: 119960
nosy: michael.foord, rhettinger
priority: high
severity: normal
status: open
title: unittest's assertItemsEqual() method makes too many assumptions about its input
versions: Python 2.7, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10242>
_______________________________________

From report at bugs.python.org  Sat Oct 30 08:07:25 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Oct 2010 06:07:25 +0000
Subject: [issue10240] dict.update.__doc__ is misleading
In-Reply-To: <1288406048.13.0.615215732385.issue10240@psf.upfronthosting.co.za>
Message-ID: <1288418845.77.0.561784591427.issue10240@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I'm not sure that we should mention the fast path for dicts.  That is an implementation detail and may not be present in IronPython, PyPy, Jython, etc.

The current version includes:

  D.updated(E, **F) --> None.  Updated D for dict/iterable E and F.

ISTM that covers the semantics of what it does.  Your proposed modification gets into how it does it.

----------
nosy: +rhettinger

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10240>
_______________________________________

From report at bugs.python.org  Sat Oct 30 08:32:34 2010
From: report at bugs.python.org (ivank)
Date: Sat, 30 Oct 2010 06:32:34 +0000
Subject: [issue10240] dict.update.__doc__ is misleading
In-Reply-To: <1288406048.13.0.615215732385.issue10240@psf.upfronthosting.co.za>
Message-ID: <1288420354.41.0.410432357777.issue10240@psf.upfronthosting.co.za>


ivank <bugs at ludios.org> added the comment:

CPython's dict(obj) ignores `keys` and `__iter__` if obj is a subclass of dict.  I thought this was an important language detail, not just an implementation quirk.  But, I just tested pypy 1.3, and it is calling .keys() on dicts.  Oh well.

I think the __doc__ can still be slightly improved; ignore my patch and just change the first E: to E.keys(): - that would be more accurate.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10240>
_______________________________________

From report at bugs.python.org  Sat Oct 30 08:46:30 2010
From: report at bugs.python.org (Max Skaller)
Date: Sat, 30 Oct 2010 06:46:30 +0000
Subject: [issue10243] Packaged Pythons
In-Reply-To: <1288421190.78.0.406160800778.issue10243@psf.upfronthosting.co.za>
Message-ID: <1288421190.78.0.406160800778.issue10243@psf.upfronthosting.co.za>


New submission from Max Skaller <max.skaller at gmail.com>:

Not sure if this is a bug or not. I am unable to find libpython.so for Python3 on either my Mac or Ubuntu. Perhaps this is a packaging fault, however some documentation in the Wiki suggests otherwise. It appears the builders have reverted to an archaic linkage pattern which I helped to get rid of (lets see, perhaps a decade ago?). Python 2.6, for example, does ship a shared library.

Python must be shipped with code linked as follows, I will explain below why, but first the list:

1) The mainline (C main() function) must be a stub which calls the real mainline, which is located in libpython.

2) The mainline MUST be compiled with C++ not C.

3) All extension libraries and add-ons to Python provided as shared libraries must be explicitly linked against libpython.

In particular it is NOT acceptable for any extension or shared library component to expect to find its symbols in the host application executable as the Wiki documentation seems to suggest (in a section which explains a bit of a workaround for OSX frameworks).

Now the reason it MUST be this way. First, any C++ code which is to be linked into an application, either statically, dynamically at load time, or under program control at run time, may require certain stuff to be in place (RTTI, streams, exception handling stuff, or whatever) which can only be put in place in the initialisation of the main application. Although the details are platform specific, it is simply not safe to permit C++ extension modules unless this step is taken.

Legacy or embedded systems may have to make do with a C mainline, and systems which don't support dynamic loading can also do without C++ compilation provided the pre-loaded extensions are all C.

On most major platforms, however, a C++ driver stub is required.

The second issue is also quite simple. It is quite incorrect in a modern computing environment to assume an *application* will be hosting the python interpreter directly. It is not only possible, it is in fact the case for my project, that were the Python interpreter to be called, it would from a shared library loaded under program control at run time.

Such an interpreter cannot be loaded at all if it isn't present in a library: it either has to be statically linked into the shared library making the call, with some ugly linker switches to make sure no symbols are dropped, or it has to be loaded dynamically. The latter case is the only viable option if the run time linker is unable to share symbols to a loaded application, and even if that is possible and can be arranged it is not likely to work so well if multiple shared libraries try to do it.

Similarly, even if you managed to load it somehow, any dynamically loaded extensions may or may not be able to find the symbols.

The ONLY reliable way to ensure extensions can find libpython symbols is to link them against libpython.

In fact, the mainline application should not only contain NO libpython symbols specifically to disable this wrong practice and break any bad extensions that rely on it, it should also, as explained, contain exactly one reference to libpython, which calls Python with argv, argc[] as if it were the mainline.

Just as motivation here: my product is an ultra-high performance programming language with a special construction to allow Python C-extension modules to be built. Its target is usually a shared library and that library is produced by first generating C++ and then compiling it with your native C++ compiler.

For a generated program to call Python interpreter, it HAS to be available in a shared library, and for any extension modules that interpreter loads, they HAVE to get their symbols from that shared library, and, if the generated program is itself a Python module, then if that module is to be loaded from any C extension, including itself or some other extension, it HAS to be linked against libpython which HAS to be loaded dynamically by the loaded.

The unfortunate downside of this is that it is NOT POSSIBLE to have a huge statically linked Python executable which just loads C extensions and nothing else happens. If you're loading any C extensions dynamically libpython must be loaded dynamically too.

Just to be clear: I can easily build it the way I want it but this will not solve my problem, which is to support clients who wish to use my product to generate high performance Python callable modules which will just work "out of the box" with existing Python code. In particular, replacing some slow modules with optimised ones would be more or less entirely transparent .. except that at the moment it could only work with Python 2.x since Python 3.x shipments don't seem to have any shared libpython included (and I just changed my compiler to support Python 3 modules instead of Python 2).

----------
components: Installation
messages: 119963
nosy: Max.Skaller
priority: normal
severity: normal
status: open
title: Packaged Pythons
type: resource usage
versions: Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10243>
_______________________________________

From report at bugs.python.org  Sat Oct 30 09:30:34 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Oct 2010 07:30:34 +0000
Subject: [issue6105] json.dumps doesn't respect OrderedDict's iteration order
In-Reply-To: <1243243366.01.0.202838739816.issue6105@psf.upfronthosting.co.za>
Message-ID: <1288423834.33.0.938464078842.issue6105@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Backported to 2.7
See r85966

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6105>
_______________________________________

From report at bugs.python.org  Sat Oct 30 09:40:55 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 30 Oct 2010 07:40:55 +0000
Subject: [issue10243] Packaged Pythons
In-Reply-To: <1288421190.78.0.406160800778.issue10243@psf.upfronthosting.co.za>
Message-ID: <4CCBCC03.8020200@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Python 2.6, for example, does ship a shared library.

That is not really the case. Python 2.6 ships in source form. It
builds with a libpython shared library only if you configure
with --enable-shared.

> In particular it is NOT acceptable for any extension or shared
> library component to expect to find its symbols in the host
> application executable as the Wiki documentation seems to suggest (in
> a section which explains a bit of a workaround for OSX frameworks).

I completely disagree with this evaluation. These statements are not
true in general, although they might be partially true for specific
operating systems and compilers.

> Although the details are platform specific, it is simply
> not safe to permit C++ extension modules unless this step is taken.

It certainly is safe on all platforms where Python does that,
i.e. primarily Linux, Windows, and OS X. Only archaic C++
implementations fail to support applications where main()
was not compiled with a C++ compiler.

> On most major platforms, however, a C++ driver stub is required.

That is not true.

> It is not only possible, it
> is in fact the case for my project, that were the Python interpreter
> to be called, it would from a shared library loaded under program
> control at run time.

Python supports embedding of the interpreter quite well. You can
choose between linking Python as a static (.a) or dynamic library.
If you use a static library, extension modules would still pick
up Python symbols from the executable.

> Such an interpreter cannot be loaded at all if it isn't present in a
> library: it either has to be statically linked into the shared
> library making the call, with some ugly linker switches to make sure
> no symbols are dropped, or it has to be loaded dynamically.

The Python build process will *always* create a library that embedding
applications can link against.

> For a generated program to call Python interpreter, it HAS to be
> available in a shared library, and for any extension modules that
> interpreter loads, they HAVE to get their symbols from that shared
> library, and, if the generated program is itself a Python module,
> then if that module is to be loaded from any C extension, including
> itself or some other extension, it HAS to be linked against libpython
> which HAS to be loaded dynamically by the loaded.

If that's your requirement, make sure you build against a Python
installation that was itself built with --enable-shared.

> The unfortunate downside of this is that it is NOT POSSIBLE to have a
> huge statically linked Python executable which just loads C
> extensions and nothing else happens. If you're loading any C
> extensions dynamically libpython must be loaded dynamically too.

That depends on the operating system. On Linux, it would be possible
to link the entire Python interpreter in your language's shared library,
and extension modules would still find their symbols.

> Just to be clear: I can easily build it the way I want it but this
> will not solve my problem, which is to support clients who wish to
> use my product to generate high performance Python callable modules
> which will just work "out of the box" with existing Python code. In
> particular, replacing some slow modules with optimised ones would be
> more or less entirely transparent .. except that at the moment it
> could only work with Python 2.x since Python 3.x shipments don't seem
> to have any shared libpython included (and I just changed my compiler
> to support Python 3 modules instead of Python 2).

One solution could be to ship libpythonXY.so yourself, along with your
the rest of the binaries that you provide. Or else do as I propose
above: link the Python interpreter statically into your shared library.

I fail to see the bug in this report.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10243>
_______________________________________

From report at bugs.python.org  Sat Oct 30 10:18:03 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Oct 2010 08:18:03 +0000
Subject: [issue10221] {}.pop('a') raises non-standard KeyError exception
In-Reply-To: <1288272402.21.0.117850725041.issue10221@psf.upfronthosting.co.za>
Message-ID: <1288426683.64.0.901776789954.issue10221@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See r85967, r85968 and r85969.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10221>
_______________________________________

From report at bugs.python.org  Sat Oct 30 11:37:21 2010
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 30 Oct 2010 09:37:21 +0000
Subject: [issue10224] Build 3.x documentation using python3.x
In-Reply-To: <1288304199.49.0.7053863257.issue10224@psf.upfronthosting.co.za>
Message-ID: <1288431441.37.0.580963951748.issue10224@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek <zbyszek at in.waw.pl>:


----------
nosy: +zbysz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10224>
_______________________________________

From report at bugs.python.org  Sat Oct 30 11:37:46 2010
From: report at bugs.python.org (Zbyszek Szmek)
Date: Sat, 30 Oct 2010 09:37:46 +0000
Subject: [issue10220] Make generator state easier to introspect
In-Reply-To: <1288269773.83.0.431465195808.issue10220@psf.upfronthosting.co.za>
Message-ID: <1288431466.66.0.420747117993.issue10220@psf.upfronthosting.co.za>


Changes by Zbyszek Szmek <zbyszek at in.waw.pl>:


----------
nosy: +zbysz

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10220>
_______________________________________

From report at bugs.python.org  Sat Oct 30 12:20:02 2010
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Sat, 30 Oct 2010 10:20:02 +0000
Subject: [issue10244] PEP100 has broken links
In-Reply-To: <1288434002.3.0.460558889846.issue10244@psf.upfronthosting.co.za>
Message-ID: <1288434002.3.0.460558889846.issue10244@psf.upfronthosting.co.za>


New submission from Maciej Fijalkowski <fijall at gmail.com>:

PEP100 (http://www.python.org/dev/peps/pep-0100/) links to python starship. Should it just link to python.org for the newest version of this doc?

----------
assignee: docs at python
components: Documentation
messages: 119967
nosy: docs at python, fijall
priority: normal
severity: normal
status: open
title: PEP100 has broken links

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10244>
_______________________________________

From report at bugs.python.org  Sat Oct 30 13:09:56 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 30 Oct 2010 11:09:56 +0000
Subject: [issue10244] PEP100 has broken links
In-Reply-To: <1288434002.3.0.460558889846.issue10244@psf.upfronthosting.co.za>
Message-ID: <1288436996.49.0.970156897537.issue10244@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Why do you say that the link is broken?

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10244>
_______________________________________

From report at bugs.python.org  Sat Oct 30 13:27:18 2010
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Sat, 30 Oct 2010 11:27:18 +0000
Subject: [issue10244] PEP100 has broken links
In-Reply-To: <1288434002.3.0.460558889846.issue10244@psf.upfronthosting.co.za>
Message-ID: <1288438038.01.0.512559626789.issue10244@psf.upfronthosting.co.za>


Maciej Fijalkowski <fijall at gmail.com> added the comment:

Python starship is down, I thought it's permanently down, isn't it?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10244>
_______________________________________

From report at bugs.python.org  Sat Oct 30 13:30:54 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 30 Oct 2010 11:30:54 +0000
Subject: [issue10244] PEP100 has broken links
In-Reply-To: <1288434002.3.0.460558889846.issue10244@psf.upfronthosting.co.za>
Message-ID: <1288438254.88.0.254266580257.issue10244@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The link works fine for me right now, and the starship is alive and well.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10244>
_______________________________________

From report at bugs.python.org  Sat Oct 30 13:37:20 2010
From: report at bugs.python.org (Maciej Fijalkowski)
Date: Sat, 30 Oct 2010 11:37:20 +0000
Subject: [issue10244] PEP100 has broken links
In-Reply-To: <1288434002.3.0.460558889846.issue10244@psf.upfronthosting.co.za>
Message-ID: <1288438640.76.0.928367953213.issue10244@psf.upfronthosting.co.za>


Maciej Fijalkowski <fijall at gmail.com> added the comment:

That is really weird, it definitely doesn't for me. Anyway, closing the ticket then.

----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10244>
_______________________________________

From report at bugs.python.org  Sat Oct 30 13:54:08 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Oct 2010 11:54:08 +0000
Subject: [issue10244] PEP100 has broken links
In-Reply-To: <1288434002.3.0.460558889846.issue10244@psf.upfronthosting.co.za>
Message-ID: <1288439648.52.0.298129894069.issue10244@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Well, obviously only the first link works (does for me too), the second needs to have a version filled in :)

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10244>
_______________________________________

From report at bugs.python.org  Sat Oct 30 13:54:38 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 30 Oct 2010 11:54:38 +0000
Subject: [issue10244] PEP100 has broken links
In-Reply-To: <1288434002.3.0.460558889846.issue10244@psf.upfronthosting.co.za>
Message-ID: <4CCC077B.3030405@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Maciej Fijalkowski wrote:
> 
> New submission from Maciej Fijalkowski <fijall at gmail.com>:
> 
> PEP100 (http://www.python.org/dev/peps/pep-0100/) links to python starship. Should it just link to python.org for the newest version of this doc?

The starship link works for me (starship just moved to a new server,
so it'll take a while before the DNS changes propogate).

Note that the proposal was moved into the PEP list after we introduced
PEPs - the proposal itself predates PEPs as we have them now. The link
to the older versions are just there for historic reasons.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10244>
_______________________________________

From report at bugs.python.org  Sat Oct 30 14:17:57 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 12:17:57 +0000
Subject: [issue10245] Fix resource warnings in test_telnetlib
In-Reply-To: <1288441077.58.0.74967624488.issue10245@psf.upfronthosting.co.za>
Message-ID: <1288441077.58.0.74967624488.issue10245@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached patch and "closing files and sockets in a timely manner in the stdlib" on python-dev.

----------
components: Tests
files: test_telnetlib_fd_leak.patch
keywords: patch
messages: 119974
nosy: bbrazil, brett.cannon
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_telnetlib
versions: Python 3.3
Added file: http://bugs.python.org/file19424/test_telnetlib_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10245>
_______________________________________

From report at bugs.python.org  Sat Oct 30 14:43:59 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 12:43:59 +0000
Subject: [issue10246] uu.encode fd leak if arguments are filenames
In-Reply-To: <1288442639.64.0.225506910081.issue10246@psf.upfronthosting.co.za>
Message-ID: <1288442639.64.0.225506910081.issue10246@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached patch, I'm not sure if this is the cleanest way to fix this. This also fixes the resource warnings in the test.

----------
components: Library (Lib)
files: uu_fd_leak.patch
keywords: patch
messages: 119975
nosy: bbrazil, brett.cannon
priority: normal
severity: normal
status: open
title: uu.encode fd leak if arguments are filenames
versions: Python 3.3
Added file: http://bugs.python.org/file19425/uu_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10246>
_______________________________________

From report at bugs.python.org  Sat Oct 30 14:46:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 12:46:57 +0000
Subject: [issue10246] uu.encode fd leak if arguments are filenames
In-Reply-To: <1288442639.64.0.225506910081.issue10246@psf.upfronthosting.co.za>
Message-ID: <1288442817.54.0.0842456160638.issue10246@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I think there should be a try..finally block so that those files get closed even when there's an error in-between.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10246>
_______________________________________

From report at bugs.python.org  Sat Oct 30 14:51:52 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 12:51:52 +0000
Subject: [issue10246] uu.encode fd leak if arguments are filenames
In-Reply-To: <1288442639.64.0.225506910081.issue10246@psf.upfronthosting.co.za>
Message-ID: <1288443112.68.0.35472922219.issue10246@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

How does v2 look?

----------
Added file: http://bugs.python.org/file19426/uu_fd_leak_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10246>
_______________________________________

From report at bugs.python.org  Sat Oct 30 14:59:49 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Oct 2010 12:59:49 +0000
Subject: [issue10240] dict.update.__doc__ is misleading
In-Reply-To: <1288406048.13.0.615215732385.issue10240@psf.upfronthosting.co.za>
Message-ID: <1288443589.42.0.986827525375.issue10240@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

Maybe the fastpath should do a strict check and not be used for subclasses of dict?

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10240>
_______________________________________

From report at bugs.python.org  Sat Oct 30 15:00:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 13:00:42 +0000
Subject: [issue10246] uu.encode fd leak if arguments are filenames
In-Reply-To: <1288443112.68.0.35472922219.issue10246@psf.upfronthosting.co.za>
Message-ID: <1288443636.3627.0.camel@localhost.localdomain>


Antoine Pitrou <pitrou at free.fr> added the comment:

> How does v2 look?

Nice, thank you!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10246>
_______________________________________

From report at bugs.python.org  Sat Oct 30 15:03:48 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 13:03:48 +0000
Subject: [issue10237] failure in Barrier tests
In-Reply-To: <1288391142.98.0.44997335021.issue10237@psf.upfronthosting.co.za>
Message-ID: <1288443828.33.0.266726009467.issue10237@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I also get a failure here:

======================================================================
FAIL: test_default_timeout (test.test_threading.BarrierTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/antoine/py3k/__svn__/Lib/test/lock_tests.py", line 784, in test_default_timeout
    self.run_threads(f)
  File "/home/antoine/py3k/__svn__/Lib/test/lock_tests.py", line 615, in run_threads
    f()
  File "/home/antoine/py3k/__svn__/Lib/test/lock_tests.py", line 783, in f
    self.assertRaises(threading.BrokenBarrierError, self.barrier.wait)
AssertionError: BrokenBarrierError not raised by wait

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10237>
_______________________________________

From report at bugs.python.org  Sat Oct 30 15:04:00 2010
From: report at bugs.python.org (Lorenz Quack)
Date: Sat, 30 Oct 2010 13:04:00 +0000
Subject: [issue10247] mold builder
In-Reply-To: <20101030130356.13C177820C@psf.upfronthosting.co.za>
Message-ID: <20101030130356.13C177820C@psf.upfronthosting.co.za>


New submission from Lorenz Quack <don at amberfisharts.com>:

RV Plastics is your end to end partner for all your moulds and Injection Moulding requirements. 

Founded in 2003, RV Plastics dedicates itself to the plastic industry, exporting 
Plastic injection moulds and molded Components to customers spread over 20 countries. 
We offer mould design & development services for plastic house ware, electrical, automobile and industrial products. 
We produce high quality moulds at attractive prices.

Tel: 86-769-8997 5802
Fax: 86-769-8458 5238
Web: www(dot)rvmold(dot)com
E-mail: rvmold(at)hotmail(dot)com / sales(at)rvmold(dot)com

----------
messages: 119981
nosy: donlorenzo
priority: normal
severity: normal
status: open
title: mold builder

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10247>
_______________________________________

From report at bugs.python.org  Sat Oct 30 15:04:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 13:04:40 +0000
Subject: [issue10246] uu.encode fd leak if arguments are filenames
In-Reply-To: <1288442639.64.0.225506910081.issue10246@psf.upfronthosting.co.za>
Message-ID: <1288443880.97.0.48541703257.issue10246@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85975 (3.2). I guess we'll do a big svnmerge to other branches later.

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10246>
_______________________________________

From report at bugs.python.org  Sat Oct 30 15:17:28 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 13:17:28 +0000
Subject: [issue10248] Fix resource warnings in test_xmlrpclib
In-Reply-To: <1288444648.27.0.0542551809175.issue10248@psf.upfronthosting.co.za>
Message-ID: <1288444648.27.0.0542551809175.issue10248@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

I'm not 100% comfortable with this patch as my knowledge of the xmlrpc interface is very limited, a simple p.close() would seem cleaner - but that doesn't work.

----------
files: test_xmlrpclib_fd_leak.patch
keywords: patch
messages: 119983
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_xmlrpclib
Added file: http://bugs.python.org/file19427/test_xmlrpclib_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10248>
_______________________________________

From report at bugs.python.org  Sat Oct 30 15:18:05 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 13:18:05 +0000
Subject: [issue10249] Fix resource warnings in test_unicodedata
In-Reply-To: <1288444685.04.0.0407449427319.issue10249@psf.upfronthosting.co.za>
Message-ID: <1288444685.04.0.0407449427319.issue10249@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Library (Lib)
files: test_unicodedata_fd_leak.patch
keywords: patch
messages: 119984
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_unicodedata
versions: Python 3.3
Added file: http://bugs.python.org/file19428/test_unicodedata_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10249>
_______________________________________

From report at bugs.python.org  Sat Oct 30 15:18:47 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 13:18:47 +0000
Subject: [issue10250] Fix resource warnings in test_urllib2_localnet
In-Reply-To: <1288444727.09.0.95705539029.issue10250@psf.upfronthosting.co.za>
Message-ID: <1288444727.09.0.95705539029.issue10250@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached, not sure this is quite right.

----------
components: Tests
files: test_urllib2_localnet_fd_leak.patch
keywords: patch
messages: 119985
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_urllib2_localnet
versions: Python 3.3
Added file: http://bugs.python.org/file19429/test_urllib2_localnet_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10250>
_______________________________________

From report at bugs.python.org  Sat Oct 30 15:19:29 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 13:19:29 +0000
Subject: [issue10248] Fix resource warnings in test_xmlrpclib
In-Reply-To: <1288444648.27.0.0542551809175.issue10248@psf.upfronthosting.co.za>
Message-ID: <1288444769.71.0.850885898876.issue10248@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +loewis
stage:  -> patch review
type:  -> resource usage
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10248>
_______________________________________

From report at bugs.python.org  Sat Oct 30 15:19:59 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 13:19:59 +0000
Subject: [issue10250] Fix resource warnings in test_urllib2_localnet
In-Reply-To: <1288444727.09.0.95705539029.issue10250@psf.upfronthosting.co.za>
Message-ID: <1288444799.92.0.774653485976.issue10250@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +orsenthil
stage:  -> patch review
type:  -> resource usage
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10250>
_______________________________________

From report at bugs.python.org  Sat Oct 30 15:22:00 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 13:22:00 +0000
Subject: [issue10247] mold builder
Message-ID: <1288444920.19.0.909150466553.issue10247@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
Removed message: http://bugs.python.org/msg119981

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10247>
_______________________________________

From report at bugs.python.org  Sat Oct 30 15:22:18 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 13:22:18 +0000
Subject: [issue10247] mold builder
Message-ID: <1288444938.05.0.526536776639.issue10247@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy:  -donlorenzo
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10247>
_______________________________________

From report at bugs.python.org  Sat Oct 30 16:03:53 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Oct 2010 14:03:53 +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: <1288447433.09.0.416446345121.issue9340@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

I've looked over this patch, and it seems to me that there is no compelling reason to create two new functions.  I think it would be clearer to just inline that code in the places it is used.  If it turns out later that the code needs to be reused elsewhere, it can be factored out at that time.  (Also, as it stands the methods are being made part of the public API, and that doesn't look right to me.)

Catherine, if you'd like to update the patch that would be great.  Otherwise we will hopefully get to it during the upcoming bug weekend.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9340>
_______________________________________

From report at bugs.python.org  Sat Oct 30 16:04:35 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Oct 2010 14:04:35 +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: <1288447475.24.0.861180022977.issue9340@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
stage: needs patch -> patch review
versions: +Python 3.1 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9340>
_______________________________________

From report at bugs.python.org  Sat Oct 30 16:08:06 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 14:08:06 +0000
Subject: [issue10251] Fix resource warnings in test_file
In-Reply-To: <1288447686.86.0.275228284078.issue10251@psf.upfronthosting.co.za>
Message-ID: <1288447686.86.0.275228284078.issue10251@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Tests
files: test_file_fd_leak.patch
keywords: patch
messages: 119987
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_file
versions: Python 3.3
Added file: http://bugs.python.org/file19430/test_file_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10251>
_______________________________________

From report at bugs.python.org  Sat Oct 30 16:22:54 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 14:22:54 +0000
Subject: [issue10252] Fix resource warnings in distutil tests
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
assignee: tarek
components: Distutils
files: distutils_fd_leak.patch
keywords: patch
messages: 119988
nosy: bbrazil, eric.araujo, tarek
priority: normal
severity: normal
status: open
title: Fix resource warnings in distutil tests
versions: Python 3.3
Added file: http://bugs.python.org/file19431/distutils_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Sat Oct 30 16:23:04 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 14:23:04 +0000
Subject: [issue10251] Fix resource warnings in test_file
In-Reply-To: <1288447686.86.0.275228284078.issue10251@psf.upfronthosting.co.za>
Message-ID: <1288448584.8.0.416512008235.issue10251@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85977, thanks.

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10251>
_______________________________________

From report at bugs.python.org  Sat Oct 30 16:25:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 14:25:05 +0000
Subject: [issue10249] Fix resource warnings in test_unicodedata
In-Reply-To: <1288444685.04.0.0407449427319.issue10249@psf.upfronthosting.co.za>
Message-ID: <1288448705.15.0.671109338856.issue10249@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Fixed in r85978, thank you.

----------
nosy: +pitrou
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10249>
_______________________________________

From report at bugs.python.org  Sat Oct 30 16:25:40 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 14:25:40 +0000
Subject: [issue10252] Fix resource warnings in distutil tests
In-Reply-To: <1288448574.25.0.83148173886.issue10252@psf.upfronthosting.co.za>
Message-ID: <1288448740.09.0.114944442159.issue10252@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
stage:  -> patch review
type:  -> resource usage
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10252>
_______________________________________

From report at bugs.python.org  Sat Oct 30 16:51:22 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Oct 2010 14:51:22 +0000
Subject: [issue10226] urlparse example is wrong
In-Reply-To: <1288329966.05.0.0344146922962.issue10226@psf.upfronthosting.co.za>
Message-ID: <1288450282.22.0.736195691365.issue10226@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

How about this:

-  If the scheme value is not specified, urlparse following the syntax
-  specifications from RFC 1808, expects the netloc value to start with '//',
-  Otherwise, it is not possible to distinguish between net_loc and path
-  component and would classify the indistinguishable component as path as in
-  a relative url.

+  Following the syntax specifications in RFC 1808, urlparse recognizes
+  a netloc only if it is properly introduced by '//'.  Otherwise the
+  input must be presumed to be a relative URL and thus to start with
+  a path component.


However, it seems to me there is a bug here:

>>> urlparse.urlparse('www.k.com:80/path')
ParseResult(scheme='', netloc='', path='www.k.com:80/path', params='',
query='', fragment='')
>>> urlparse.urlparse('www.k.com:path')
ParseResult(scheme='www.k.com', netloc='', path='path', params='',
query='', fragment='')

I think the second one is correct and that the first one should produce

ParseResult(scheme='www.k.com', netloc='', path='80/path', params='',
query='', fragment='')

I haven't read all the way through the RFC again, though.  But *one*
of the above is wrong.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10226>
_______________________________________

From report at bugs.python.org  Sat Oct 30 16:59:08 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 14:59:08 +0000
Subject: [issue10253] Fix fd leak in fileio.c and test resource warnings
In-Reply-To: <1288450748.11.0.919591582507.issue10253@psf.upfronthosting.co.za>
Message-ID: <1288450748.11.0.919591582507.issue10253@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

fileio_init will leak a fd if you open a file for append that isn't seekable. We should close this fd before returning the failure.

The attached patch fixes this and a resource warning in the tests, but I'm unsure if it'd be better to use internal_close. I'd want the error from the seek rather than any potential error from the close, so I think this is okay.

Regrtest is happy.

----------
components: IO
files: fileio_fd_leak.patch
keywords: patch
messages: 119992
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix fd leak in fileio.c and test resource warnings
versions: Python 3.3
Added file: http://bugs.python.org/file19432/fileio_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10253>
_______________________________________

From report at bugs.python.org  Sat Oct 30 17:02:57 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 15:02:57 +0000
Subject: [issue10253] Fix fd leak in fileio.c and test resource warnings
In-Reply-To: <1288450748.11.0.919591582507.issue10253@psf.upfronthosting.co.za>
Message-ID: <1288450977.29.0.360869734095.issue10253@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +amaury.forgeotdarc, benjamin.peterson
stage:  -> patch review
type:  -> resource usage
versions: +Python 2.7, Python 3.1, Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10253>
_______________________________________

From report at bugs.python.org  Sat Oct 30 17:06:56 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 15:06:56 +0000
Subject: [issue10253] Fix fd leak in fileio.c and test resource warnings
In-Reply-To: <1288450748.11.0.919591582507.issue10253@psf.upfronthosting.co.za>
Message-ID: <1288451216.92.0.168708636123.issue10253@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

It should be closed only if closefd is true.
Does it fix a warning in the test suite? Otherwise I think it would need its own test.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10253>
_______________________________________

From report at bugs.python.org  Sat Oct 30 17:12:15 2010
From: report at bugs.python.org (Dave Malcolm)
Date: Sat, 30 Oct 2010 15:12:15 +0000
Subject: [issue1346238] A constant folding optimization pass for the AST
Message-ID: <1288451535.34.0.491552084996.issue1346238@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/issue1346238>
_______________________________________

From report at bugs.python.org  Sat Oct 30 17:28:11 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 15:28:11 +0000
Subject: [issue10253] Fix fd leak in fileio.c and test resource warnings
In-Reply-To: <1288450748.11.0.919591582507.issue10253@psf.upfronthosting.co.za>
Message-ID: <1288452491.46.0.929930277688.issue10253@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

Version 2 of the patch is attached.

This fixes a warning at line 256 in test_fileio.py:
    f = _FileIO("/dev/tty", "a")
on my Hardy machine.

----------
Added file: http://bugs.python.org/file19433/fileio_fd_leak_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10253>
_______________________________________

From report at bugs.python.org  Sat Oct 30 17:42:14 2010
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 30 Oct 2010 15:42:14 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>


New submission from Merlijn van Deen <valhallasw at gmail.com>:

Summary: Somewhere between 2.6.5 r79063 and 3.1 r79147 a regression in the unicode NFC normalization has been introduces. This regression leads to bot edit wars on wikipedia [1]. It is reproducable with a simple script [2]. Mediawiki/PHP [3] and C# [4] test scripts both show the old behaviour, which leads me to believe this is a python bug.
A search for older bugs shows bug #1054943 [5] which has commits in the suspected region.

The regression causes certain NFC-normalized strings to become mangled. Because of the wide range of unicode strings on wikipedia, this causes several problems. Details of those can be found at [1].

Example strings include: (these strings have been NFC-normalized by mediawiki)
 * u'Li\u030dt-s\u1e73\u0301'
 * u'\u092e\u093e\u0930\u094d\u0915 \u091c\u093c\u0941\u0915\u0947\u0930\u092c\u0930\u094d\u0917'
 * u'\u0915\u093f\u0930\u094d\u0917\u093f\u091c\u093c\u0938\u094d\u0924\u093e\u0928'

The bug can be shown simply with
unicodedata.normalize('NFC', s) == s
where s is one of the strings above. This will return True on older python versions, False on newer versions. There is a script available that does this [2].

The bug has been tested on the following machines and python versions. OK indicates the bug is not present, FAIL indicates the bug is present.

Host: SunOS willow 5.10 Generic_142910-17 i86pc i386 i86pc Solaris
'2.3.3 (#1, Dec 16 2004, 14:38:56) [C]' OK
'2.6.5 (r265:79063, Jul 10 2010, 17:50:38) [C]' OK
'2.7 (r27:82500, Aug  5 2010, 04:28:45) [C]' FAIL
'3.1.2 (r312:79147, Sep 24 2010, 05:34:04) [C]' FAIL

Host: Linux nightshade 2.6.26-2-amd64 #1 SMP Thu Sep 16 15:56:38 UTC 2010 x86_64 GNU/Linux
'2.4.6 (#2, Jan 24 2010, 12:20:41) \n[GCC 4.3.2]' OK
'2.5.2 (r252:60911, Jan 24 2010, 17:44:40) \n[GCC 4.3.2]' OK
'2.6.4+ (r264:75706, Feb 16 2010, 05:11:28) \n[GCC 4.4.3]' OK

Host: Linux dorthonion 2.6.22.18-co-0.7.4 #1 PREEMPT Wed Apr 15 18:57:39 UTC 2009 i686 GNU/Linux
'2.5.4 (r254:67916, Jan 20 2010, 21:44:03) \n[GCC 4.3.3]' OK
'2.6.2 (release26-maint, Apr 19 2009, 01:56:41) \n[GCC 4.3.3]' OK
'3.0.1+ (r301:69556, Apr 15 2009, 15:59:22) \n[GCC 4.3.3]' OK

[1] https://sourceforge.net/tracker/index.php?func=detail&aid=3081100&group_id=93107&atid=603138# ; http://fr.wikipedia.org/w/index.php?title=Mark_Zuckerberg&action=historysubmit&diff=57753004&oldid=57751674
[2] http://pastebin.ca/1977285 (py2.x), http://pastebin.ca/1977287 (py3.x)
[3] http://pastebin.ca/1977292 (PHP, placed in http://svn.wikimedia.org/svnroot/mediawiki/trunk/phase3/normal/), 
[4] http://pastebin.ca/1977261 (C#)
[5] http://bugs.python.org/issue1054943#

----------
components: Unicode
messages: 119995
nosy: valhallasw
priority: normal
severity: normal
status: open
title: unicodedata.normalize('NFC', s) regression
type: behavior
versions: Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Sat Oct 30 17:44:36 2010
From: report at bugs.python.org (Merlijn van Deen)
Date: Sat, 30 Oct 2010 15:44:36 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1288453476.7.0.572199714333.issue10254@psf.upfronthosting.co.za>


Merlijn van Deen <valhallasw at gmail.com> added the comment:

Please note: The bug might very well be present in python 3.2 and 3.3. However, I do not have these versions installed, so I cannot confirm this.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Sat Oct 30 17:46:48 2010
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 30 Oct 2010 15:46:48 +0000
Subject: [issue10157] Refleaks in pythonrun.c
In-Reply-To: <1287596001.72.0.908968504513.issue10157@psf.upfronthosting.co.za>
Message-ID: <1288453608.15.0.230297719269.issue10157@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at m2.ccsnet.ne.jp> added the comment:

Thank you, I committed your patch in r85980(py3k) and
r85981(release31-maint).

----------
assignee: ocean-city -> 
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/issue10157>
_______________________________________

From report at bugs.python.org  Sat Oct 30 17:52:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 15:52:45 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1288453965.26.0.315188876227.issue10254@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Confirmed on Python 3.2.

----------
nosy: +haypo, loewis, pitrou
versions: +Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Sat Oct 30 18:17:06 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 30 Oct 2010 16:17:06 +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: <1288455426.35.0.0140788178077.issue10164@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10164>
_______________________________________

From report at bugs.python.org  Sat Oct 30 18:19:01 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Oct 2010 16:19:01 +0000
Subject: [issue1346238] A constant folding optimization pass for the AST
Message-ID: <1288455541.76.0.42809852587.issue1346238@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
nosy:  -georg.brandl, georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1346238>
_______________________________________

From report at bugs.python.org  Sat Oct 30 18:19:37 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 16:19:37 +0000
Subject: [issue10253] Fix fd leak in fileio.c and test resource warnings
In-Reply-To: <1288450748.11.0.919591582507.issue10253@psf.upfronthosting.co.za>
Message-ID: <1288455577.99.0.440607564396.issue10253@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85982, thank you. I will backport later.

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10253>
_______________________________________

From report at bugs.python.org  Sat Oct 30 18:29:38 2010
From: report at bugs.python.org (R. David Murray)
Date: Sat, 30 Oct 2010 16:29:38 +0000
Subject: [issue10093] Warn when files are not explicitly closed
In-Reply-To: <1287000989.52.0.725529628819.issue10093@psf.upfronthosting.co.za>
Message-ID: <1288456178.46.0.450370924378.issue10093@psf.upfronthosting.co.za>


R. David Murray <rdmurray at bitdance.com> added the comment:

MAL wrote:
> Antoine wrote:
>> MAL wrote:
>>> I don't follow you. Where's the difference between writing:
>>>
>>> s.close()
>>> or
>>> s = None
>>>
>>> for an open socket s ?
>> 
>> The difference is when s is still referenced elsewhere.
>> Also, the intent of the former is clear while the latter is deliberately
>> obscure (while not saving any significant amount of typing).
>
>Sure, but that's not the point. It is not a mistake to write
>such code and neither is this obscure, otherwise we'd also
>require explicit garbage collection for other parts of Python.

Yes it is a mistake:

In an earlier message MAL wrote:
> The only difference is with Python implementations that don't
> use synchronous garbage collection, e.g. Jython, but not with
> CPython.

This by definition makes it non-equivalent and a bad *Python* idiom,
since it depends on an acknowledged CPython *implementation detail*.
As far as I know, there is no language requirement that mandates having
garbage collection at all.

----------
nosy: +r.david.murray

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10093>
_______________________________________

From report at bugs.python.org  Sat Oct 30 18:38:46 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 16:38:46 +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: <1288456726.08.0.696270051297.issue10238@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Not sure this is a blocker. There are various assembler syntaxes for x86 and chances are LLVM uses a different one from gcc.

----------
assignee:  -> theller
nosy: +georg.brandl, pitrou, theller

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10238>
_______________________________________

From report at bugs.python.org  Sat Oct 30 18:40:31 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 30 Oct 2010 16:40:31 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1288456831.26.0.334172899409.issue6706@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Sat Oct 30 18:41:55 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 16:41:55 +0000
Subject: [issue10236] Sporadic failures of test_ssl
In-Reply-To: <1288381615.12.0.769531001166.issue10236@psf.upfronthosting.co.za>
Message-ID: <1288456915.39.0.301724944351.issue10236@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The errno printed here is just an error which is expected and tested for. The verbose run was ok, it's the silent run just before which produced an error (or several), but unfortunately:

test test_ssl failed -- multiple errors occurred; run in verbose mode for details

That said, it is likely to be related to a transient failure of a remote host used for testing.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10236>
_______________________________________

From report at bugs.python.org  Sat Oct 30 18:44:27 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sat, 30 Oct 2010 16:44:27 +0000
Subject: [issue6706] asyncore's accept() is broken
In-Reply-To: <1250291017.2.0.719693187742.issue6706@psf.upfronthosting.co.za>
Message-ID: <1288457067.93.0.517210937556.issue6706@psf.upfronthosting.co.za>


Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com> added the comment:

CVE-2010-3492 references this issue.
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2010-3492

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6706>
_______________________________________

From report at bugs.python.org  Sat Oct 30 19:00:35 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Oct 2010 17:00:35 +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: <1288458035.63.0.617960290112.issue10238@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I agree, this shouldn't be a blocker.

----------
priority: deferred blocker -> critical

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10238>
_______________________________________

From report at bugs.python.org  Sat Oct 30 19:33:45 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 17:33:45 +0000
Subject: [issue10250] Fix resource warnings in test_urllib2_localnet
In-Reply-To: <1288444727.09.0.95705539029.issue10250@psf.upfronthosting.co.za>
Message-ID: <1288460025.52.0.933084553369.issue10250@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r85983, thank you.

----------
nosy: +pitrou
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10250>
_______________________________________

From report at bugs.python.org  Sat Oct 30 20:00:37 2010
From: report at bugs.python.org (Jack Diederich)
Date: Sat, 30 Oct 2010 18:00:37 +0000
Subject: [issue10245] Fix resource warnings in test_telnetlib
In-Reply-To: <1288441077.58.0.74967624488.issue10245@psf.upfronthosting.co.za>
Message-ID: <1288461637.21.0.258163185369.issue10245@psf.upfronthosting.co.za>


Changes by Jack Diederich <jackdied at gmail.com>:


----------
assignee:  -> jackdied
nosy: +jackdied
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10245>
_______________________________________

From report at bugs.python.org  Sat Oct 30 20:11:05 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 30 Oct 2010 18:11:05 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1288462265.89.0.0378422153394.issue10160@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Some comments about the patch:
- this seems to be some dead code:

     if (nattrs <= 1) {
         if (!PyArg_UnpackTuple(args, "attrgetter", 1, 1, &attr))
             return NULL;

- you can't call PyUnicode_GET_SIZE or PyUnicode_AS_UNICODE before you have called PyUnicode_Check. If the object is not an unicode object, it triggers an assertion in debug mode:
python: ./Modules/operator.c:404: attrgetter_new: Assertion `((((((PyObject*)(item))->ob_type))->tp_flags & ((1L<<28))) != 0)' failed.

- you should also call PyUnicode_InternInPlace() on the last dotless name (after the for loop)

- this comment looks false:
  /* attrgetter_new code should ensure we never come here */

- in dotted_getattr, when attr is a tuple, you leak references to intermediate objects (because you don't decref obj before doing "newobj = obj")


Other than that, looks quite worthwhile.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Sat Oct 30 20:45:38 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Oct 2010 18:45:38 +0000
Subject: [issue10060] python.exe crashes or hangs on help() modules when bad
	modules found
In-Reply-To: <1286676227.2.0.62342583611.issue10060@psf.upfronthosting.co.za>
Message-ID: <1288464338.63.0.75644208271.issue10060@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

?ric, go ahead and consolidate to one issue if you can get to it.
Do the other issues shows problems with 3.1 or 3.2 also? I wonder because I have never seen the box in the posted .png and wonder if that is a new 'feature' with 2.7 and possibly 3.2 that was not in 3.1 and possibly the cause. Has anyone posted a 'corrupt module' that reliably reproduces the problem? It is hard to investigate when 'help> modules' works just fine, as it does on my 3.1.2 install.

'Dev': your original post is way too long. The welcome message and module lists could have been snipped to one line plus ellipsis. Example:

>>> help()

Welcome ....
[snip]

help> modules

Please wait....
[snip]

and continue with traceback.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10060>
_______________________________________

From report at bugs.python.org  Sat Oct 30 21:44:33 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Sat, 30 Oct 2010 19:44:33 +0000
Subject: [issue10255] refleak in initstdio
In-Reply-To: <1288467873.78.0.806058844227.issue10255@psf.upfronthosting.co.za>
Message-ID: <1288467873.78.0.806058844227.issue10255@psf.upfronthosting.co.za>


New submission from Neil Schemenauer <nas-python at arctrix.com>:

It looks to me like initstdio leaks a reference to "open".  AFAIK, PyObject_SetAttrString() does not steal a reference.

----------
assignee: pitrou
components: Interpreter Core
files: initstdio_refleak.txt
messages: 120008
nosy: nascheme, pitrou
priority: normal
severity: normal
status: open
title: refleak in initstdio
type: resource usage
Added file: http://bugs.python.org/file19434/initstdio_refleak.txt

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10255>
_______________________________________

From report at bugs.python.org  Sat Oct 30 21:47:11 2010
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 30 Oct 2010 19:47:11 +0000
Subject: [issue10255] refleak in initstdio
In-Reply-To: <1288467873.78.0.806058844227.issue10255@psf.upfronthosting.co.za>
Message-ID: <1288468031.78.0.353551670441.issue10255@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

LGTM.

----------
nosy: +georg.brandl

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10255>
_______________________________________

From report at bugs.python.org  Sat Oct 30 21:56:41 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Oct 2010 19:56:41 +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: <1288468601.43.0.453532832346.issue9981@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Is there a reason this removes the Release x64 configuration?

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9981>
_______________________________________

From report at bugs.python.org  Sat Oct 30 21:58:12 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Oct 2010 19:58:12 +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: <1288468692.53.0.748227567046.issue9981@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Let me rephrase that: What makes the Release x64 configuration unnecessary, thus removed?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9981>
_______________________________________

From report at bugs.python.org  Sat Oct 30 22:10:01 2010
From: report at bugs.python.org (Stephen Hansen)
Date: Sat, 30 Oct 2010 20:10:01 +0000
Subject: [issue10237] failure in Barrier tests
In-Reply-To: <1288391142.98.0.44997335021.issue10237@psf.upfronthosting.co.za>
Message-ID: <1288469401.59.0.982344169422.issue10237@psf.upfronthosting.co.za>


Stephen Hansen <me+python at ixokai.io> added the comment:

FWIW, my snow leopard slave isn't slow at all so I doubt there's a timeout related to machine speed going on here, as its failing thus:

test test_threading failed -- Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/lock_tests.py", line 784, in test_default_timeout
    self.run_threads(f)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/lock_tests.py", line 615, in run_threads
    f()
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86/build/Lib/test/lock_tests.py", line 783, in f
    self.assertRaises(threading.BrokenBarrierError, self.barrier.wait)
AssertionError: BrokenBarrierError not raised by wait

Its actually a really spammy sort of failure with a lot of errors before it, which may or may not shed more light on the situation: http://www.python.org/dev//buildbot/3.x.stable/builders/x86%20Snow%20Leopard%203.x/builds/267/steps/test/logs/stdio

This was r85883, so after the increase in the timeout.

----------
nosy: +ixokai

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10237>
_______________________________________

From report at bugs.python.org  Sat Oct 30 22:15:42 2010
From: report at bugs.python.org (Matthew Barnett)
Date: Sat, 30 Oct 2010 20:15:42 +0000
Subject: [issue2636] Regexp 2.7 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1288469742.83.0.765542248018.issue2636@psf.upfronthosting.co.za>


Matthew Barnett <python at mrabarnett.plus.com> added the comment:

issue2636-20101030a.zip is a new version of the regex module.

This bug was a bit more difficult to fix, but I think it's OK now!

----------
Added file: http://bugs.python.org/file19435/issue2636-20101030a.zip

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sat Oct 30 22:26:23 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 20:26:23 +0000
Subject: [issue10256] Fix resource warnings in test_pkgimport
In-Reply-To: <1288470383.48.0.0497448669979.issue10256@psf.upfronthosting.co.za>
Message-ID: <1288470383.48.0.0497448669979.issue10256@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached patch.

----------
components: Tests
files: test_pkgimport_fd_leak.patch
keywords: patch
messages: 120014
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_pkgimport
versions: Python 3.3
Added file: http://bugs.python.org/file19436/test_pkgimport_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10256>
_______________________________________

From report at bugs.python.org  Sat Oct 30 22:31:24 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 20:31:24 +0000
Subject: [issue10257] Fix resource warnings in test_os
In-Reply-To: <1288470684.7.0.213634483079.issue10257@psf.upfronthosting.co.za>
Message-ID: <1288470684.7.0.213634483079.issue10257@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Tests
files: test_os_fd_leak.patch
keywords: patch
messages: 120015
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_os
versions: Python 3.3
Added file: http://bugs.python.org/file19437/test_os_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10257>
_______________________________________

From report at bugs.python.org  Sat Oct 30 22:35:53 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 20:35:53 +0000
Subject: [issue10257] Fix resource warnings in test_os
In-Reply-To: <1288470684.7.0.213634483079.issue10257@psf.upfronthosting.co.za>
Message-ID: <1288470953.15.0.339077340162.issue10257@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

I'm used to a slightly different style guide, v2 has the right indentation.

----------
Added file: http://bugs.python.org/file19438/test_os_fd_leak_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10257>
_______________________________________

From report at bugs.python.org  Sat Oct 30 22:37:48 2010
From: report at bugs.python.org (=?utf-8?q?=C3=89ric_Araujo?=)
Date: Sat, 30 Oct 2010 20:37:48 +0000
Subject: [issue10257] Fix resource warnings in test_os
In-Reply-To: <1288470684.7.0.213634483079.issue10257@psf.upfronthosting.co.za>
Message-ID: <1288471068.88.0.52262807358.issue10257@psf.upfronthosting.co.za>


?ric Araujo <merwok at netwok.org> added the comment:

I don?t see any difference :)

----------
nosy: +eric.araujo

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10257>
_______________________________________

From report at bugs.python.org  Sat Oct 30 23:01:20 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 30 Oct 2010 21:01:20 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1288472480.54.0.280490517821.issue10254@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The change from issue1054943 is indeed bogus. As written, the code will happily run over starters, even though a blocked start means that subsequent characters can't possibly be combinable. That way, the code manages to combine, in 'Li\u030dt-s\u1e73\u0301', the final U+0301 with the i - even though there are several starters in-between.

I think the code should work like this:

if comb!=0 and comb1==0:
  #starter after character with higher class:
  # not combinable, and all subsequent characters will be blocked
  # as well
  break
if comb!=0 and comb1==comb:
  # blocked combining character, continue searching
  i1++
  continue
# candidate pair, check whether *i and *i1 are combinable

It's unfortunate that the patch had been backported to 2.6.6; we can't fix it there anymore.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Sat Oct 30 23:01:56 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sat, 30 Oct 2010 21:01:56 +0000
Subject: [issue10258] Fix resource warnings in distutil test_tokenize
In-Reply-To: <1288472516.9.0.895455205535.issue10258@psf.upfronthosting.co.za>
Message-ID: <1288472516.9.0.895455205535.issue10258@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached patch.

----------
components: Tests
files: test_tokenize_fd_leak.patch
keywords: patch
messages: 120019
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in distutil test_tokenize
versions: Python 3.3
Added file: http://bugs.python.org/file19439/test_tokenize_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10258>
_______________________________________

From report at bugs.python.org  Sat Oct 30 23:04:06 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Oct 2010 21:04:06 +0000
Subject: [issue10256] Fix resource warnings in test_pkgimport
In-Reply-To: <1288470383.48.0.0497448669979.issue10256@psf.upfronthosting.co.za>
Message-ID: <1288472646.12.0.565014955618.issue10256@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in r85984. Thanks.

----------
assignee:  -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> resource usage
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10256>
_______________________________________

From report at bugs.python.org  Sat Oct 30 23:06:23 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 30 Oct 2010 21:06:23 +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: <1288472783.97.0.779236976964.issue9981@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

make_buildinfo is always built and run as a 32-bit binary, so I think this part of the change is fine (though unrelated to the objective of the change).

I think the patch is fine.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9981>
_______________________________________

From report at bugs.python.org  Sat Oct 30 23:25:17 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Oct 2010 21:25:17 +0000
Subject: [issue10257] Fix resource warnings in test_os
In-Reply-To: <1288470684.7.0.213634483079.issue10257@psf.upfronthosting.co.za>
Message-ID: <1288473917.73.0.469969519154.issue10257@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in r85987. Made both places hunks of the patch use the context manager.

----------
assignee:  -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
type:  -> resource usage
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10257>
_______________________________________

From report at bugs.python.org  Sat Oct 30 23:30:31 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Oct 2010 21:30:31 +0000
Subject: [issue10257] Fix resource warnings in test_os
In-Reply-To: <1288470684.7.0.213634483079.issue10257@psf.upfronthosting.co.za>
Message-ID: <1288474231.16.0.212498032335.issue10257@psf.upfronthosting.co.za>


Changes by Brian Curtin <curtin at acm.org>:


----------
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10257>
_______________________________________

From report at bugs.python.org  Sat Oct 30 23:31:08 2010
From: report at bugs.python.org (=?utf-8?b?zqfPgc6uz4PPhM6/z4IgzpPOtc+Jz4HOs86vzr/PhSAoQ2hyaXN0b3MgR2Vvcmdp?= =?utf-8?b?b3Up?=)
Date: Sat, 30 Oct 2010 21:31:08 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1288474268.89.0.133993610655.issue10160@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) <tzot at users.sourceforge.net> added the comment:

Thank you very much, Antoine, for your review. My comments in reply:

- the dead code: it's not dead, IIRC it ensures that at least one argument is given, otherwise it raises an exception.

- PyUnicode_GET_SIZE: you're right. The previous patch didn't have this problem, because there were two loops: the first one made sure in advance that all arguments are PyUnicode.

- the false comment: right again. A remain from the first patch.

- dotted_getattr and references: right! I should have noted better what Raymond's initial loop did.

Attached a corrected version of the patch according to Antoine's comments.

----------
Added file: http://bugs.python.org/file19440/issue10160.diff

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Sat Oct 30 23:36:02 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sat, 30 Oct 2010 21:36:02 +0000
Subject: [issue10258] Fix resource warnings in distutil test_tokenize
In-Reply-To: <1288472516.9.0.895455205535.issue10258@psf.upfronthosting.co.za>
Message-ID: <1288474562.22.0.184359899733.issue10258@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Fixed in r85990. Thanks.

----------
assignee:  -> brian.curtin
nosy: +brian.curtin
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> resource usage
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10258>
_______________________________________

From report at bugs.python.org  Sun Oct 31 00:01:59 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 30 Oct 2010 22:01:59 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288476119.48.0.394724333211.issue7061@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

On initialization: the json doc has 6 examples. Each starts with 'import json' so each is independent. However, I agree that doing the same for turtle examples would be a bit much. On the other hand, I think
24.5.3. *Methods of RawTurtle/Turtle and corresponding functions*
should explicitly give the needed code. So I would change "Most of the examples in this section refer to a Turtle instance called turtle." to

"The examples below that refer to a Turtle instance called turtle require something like the following to be run first:

>>> from turtle import turtle; turtle = Turtle()
"

The three examples above turtle.shapetransform start with
>>> turtle.reset()
I presume they need that to run reliably. If it is also needed for the shapetransform example to run correctly, then I would just added it there too.

I will post more after I compare my original post to your revision.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Sun Oct 31 00:35:34 2010
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 30 Oct 2010 22:35:34 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288472480.54.0.280490517821.issue10254@psf.upfronthosting.co.za>
Message-ID: <4CCC9DB2.1060406@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Martin v. L?wis wrote:
> It's unfortunate that the patch had been backported to 2.6.6; we can't fix it there anymore.

Why not ? It looks a lot like a security fix.

----------
nosy: +lemburg

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Sun Oct 31 01:14:57 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sat, 30 Oct 2010 23:14:57 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <4CCC9DB2.1060406@egenix.com>
Message-ID: <4CCCA6EB.8090102@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

>> It's unfortunate that the patch had been backported to 2.6.6; we can't fix it there anymore.
> 
> Why not ? It looks a lot like a security fix.

Indeed, you could argue that. It's up to the 2.6 release manager, I guess.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Sun Oct 31 02:27:42 2010
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 31 Oct 2010 00:27:42 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1254717274.49.0.570691979968.issue7061@psf.upfronthosting.co.za>
Message-ID: <1288484862.33.0.884408929185.issue7061@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

GREGOR, I think we need your help to answer a few of these.

Subissues from my opening post not resolved in rev85732
--------------------

"version of python installed with Tk support.": cap 'python' to 'Python'

Is there any standard on capitalizing 'Python'?
-----------

24.5.3.1. Turtle motion

?? distance units? pixel or world, depending on mode?
presume yes, but should say something here.
--------------

I said
'''
"turtle.onclick(fun, btn=1, add=None) 
It seems that 'add=False' would be same as 'add=None' and more
consistent with below.
"add ? True or False ? if True, a new binding will be added, otherwise
it will replace a former binding "
'''

In declining to make a change, you said
"
The add argument is passed unchanged to canvas' bind method which is documented as taking either '' or '+' string:"

However, naive users are not supposed to know that, which is why you moved turtle doc out of tk chapter. Anyway, one has to know or guess to look for the doc on the generic widget bind method.

There still remains a discrepancy between signature and following doc. If you do not want to change the signature, change the doc. Anyway, the sentence needs to be expanded so it makes sense without reading the generic tkinter bind doc. 

""add ? True, False, or None - if True, add the new binding to any that already exist, otherwise replace all former bindings with the new one."

Same change is needed for onrelease and ondrag
----------------------

You changed the title "Excursus about the use of compound shapes" to "Compound shapes" but did not, as far as I can see, make the same change in the reference in *24.5.5. The public classes of the module turtle* after
"addcomponent(poly, fill, outline=None)"

Also, the above should actually be
"class turtle.addcomponent(poly, fill, outline=None)"
to be consistent with the other entries
----------------------------
'''
24.5.4. Methods of TurtleScreen/Screen and corresponding functions
"Most of the examples in this section refer to a TurtleScreen instance
called screen."

However, 
24.5.4.1. Window control
turtle.bgcolor(*args) "

and so on throughout the section.
??  I presume that should be 
"screen.bgcolor(*args)" and so on throughout the section.
'''
Not addressed as far as I can see.
------------------------

.delay vs. speed is #10170
------------
'''
"Remark: in order to be able to register key-events, TurtleScreen must
have the focus. (See method listen().
>>> def f():
...     fd(50)
...     lt(60)
...
>>> screen.onkey(f, "Up")
>>> screen.listen()"

>From the Remark, I expected the two calls to be in the opposite order.
Ditto for .onkeypress()
'''
Since the .listen doc says "Set focus on TurtleScreen (in order to collect key-events). ", I strongly suspect that 'register' in the remark should be changed to 'collect', 'capture', or 'respond to' for both onkeypress and onkeyrelease. Then the example is correct.
---------------

The last 3 sub-issues are still open
'''
24.5.4.5. Settings and special methods

?? .mode: 'world' like standard or logo w/r/t angles?
'''
'''
"24.5.4.6. Methods specific to Screen, not inherited from TurtleScreen
turtle.exitonclick() 
Bind bye() method to mouse clicks on the Screen."

"If the value ?using_IDLE? in the configuration dictionary is False
(default value), also enter mainloop. Remark: If IDLE with the -n switch
(no subprocess) is used, this value should be set to True in turtle.cfg.
In this case IDLE?s own mainloop is active also for the client script."

>From Windows shortcut, I cannot tell how IDLE is started, but seems to
work. Anything need to be said re IDLE/turtle on windows?

My guess is that IDLE is running normally (without -n), so that there is
a subprocess, so that 'using_IDLE' is False even though I am using it,
just not in the same process.  Correct?
'''
'''
24.5.8. Changes since Python 2.6

Sections about 2.x changes should not be in 3.x docs.
'''
-----------------------
Thanks for the other half that are fixed!

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Sun Oct 31 02:29:20 2010
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 31 Oct 2010 01:29:20 +0000
Subject: [issue7061] Improve 24.5. turtle doc
In-Reply-To: <1288484862.33.0.884408929185.issue7061@psf.upfronthosting.co.za>
Message-ID: <AANLkTiksfPCPVGbzfgAD-7U6P0mETtUO_-_HNjvqscSF@mail.gmail.com>


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:
..
> "version of python installed with Tk support.": cap 'python' to 'Python'
>
> Is there any standard on capitalizing 'Python'?

It looks like it is consistently capitalized in the Python manual.

> -----------
>
> 24.5.3.1. Turtle motion
>
> ?? distance units? pixel or world, depending on mode?
> presume yes, but should say something here.
> --------------

I would just use "distance units" and "angle units" throughout the
documentation and explain somewhere how the settings determine the
units.

..
> There still remains a discrepancy between signature and following doc. If you do not want to change the signature, change the doc. Anyway, the sentence needs to be expanded so it makes sense without reading the generic tkinter bind doc.
>
> ""add ? True, False, or None - if True, add the new binding to any that already exist, otherwise replace all former bindings with the new one."

I would rather change the default to False in both documentation and
the code, but let's hear from Gregor first.

>
> Same change is needed for onrelease and ondrag
> ----------------------
>
> You changed the title "Excursus about the use of compound shapes" to "Compound shapes" but did not, as far as I can see, make the same change in the reference in *24.5.5. The public classes of the module turtle* after
> "addcomponent(poly, fill, outline=None)"

I missed that.  I'll rename that section to "Public classes".

>
> Also, the above should actually be
> "class turtle.addcomponent(poly, fill, outline=None)"
> to be consistent with the other entries

I am not sure what you mean.  AFAICT, addcomponent is a method and
correctly marked as such.

..
> and so on throughout the section.
> ?? ?I presume that should be
> "screen.bgcolor(*args)" and so on throughout the section.
> '''
> Not addressed as far as I can see.

I cannot find "turtle.bgcolor".  Can you post a patch with what you
want to change?

[skipped issues for which I would appreciate Gregor's input]

> -----------------------
> Thanks for the other half that are fixed!

I thought I did better than that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7061>
_______________________________________

From report at bugs.python.org  Sun Oct 31 03:10:57 2010
From: report at bugs.python.org (Ivan Razumov)
Date: Sun, 31 Oct 2010 02:10:57 +0000
Subject: [issue10259] Entry text not set if both 'Font' and 'fg' are set
In-Reply-To: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>
Message-ID: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>


New submission from Ivan Razumov <iarspider at gmail.com>:

OS: Windows 7 x86
Python: 2.6.4

An Entry with both Font and Foreground properties changed (i.e. not OS-default) does not display text set with textvariable.set method. 

Attached an example of such behavior.

----------
components: Tkinter
files: Project5.py
messages: 120030
nosy: iarspider
priority: normal
severity: normal
status: open
title: Entry text not set if both 'Font' and 'fg' are set
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file19441/Project5.py

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10259>
_______________________________________

From report at bugs.python.org  Sun Oct 31 03:33:00 2010
From: report at bugs.python.org (Ivan Razumov)
Date: Sun, 31 Oct 2010 02:33:00 +0000
Subject: [issue10259] Entry text not set if all of 'Font',
	'Foreground' and 'Align' are set
In-Reply-To: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>
Message-ID: <1288492380.38.0.5562067118.issue10259@psf.upfronthosting.co.za>


Changes by Ivan Razumov <iarspider at gmail.com>:


----------
title: Entry text not set if both 'Font' and 'fg' are set -> Entry text not set if all of 'Font', 'Foreground' and 'Align' are set

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10259>
_______________________________________

From report at bugs.python.org  Sun Oct 31 03:34:09 2010
From: report at bugs.python.org (Ivan Razumov)
Date: Sun, 31 Oct 2010 02:34:09 +0000
Subject: [issue10259] Entry text not set if all of 'Font',
	'Foreground' and 'Align' are set
In-Reply-To: <1288491057.47.0.0560000338786.issue10259@psf.upfronthosting.co.za>
Message-ID: <1288492449.95.0.206752897055.issue10259@psf.upfronthosting.co.za>


Ivan Razumov <iarspider at gmail.com> added the comment:

The bug only appears if "Align" is not "Left".

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10259>
_______________________________________

From report at bugs.python.org  Sun Oct 31 03:34:30 2010
From: report at bugs.python.org (Ivan Razumov)
Date: Sun, 31 Oct 2010 02:34:30 +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: <1288492470.34.0.86759488906.issue10259@psf.upfronthosting.co.za>


Changes by Ivan Razumov <iarspider at gmail.com>:


----------
title: Entry text not set if all of 'Font', 'Foreground' and 'Align' are set -> Entry text not set if all of 'Font', 'Foreground' and 'Justify' are set

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10259>
_______________________________________

From report at bugs.python.org  Sun Oct 31 03:34:42 2010
From: report at bugs.python.org (Ivan Razumov)
Date: Sun, 31 Oct 2010 02:34:42 +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: <1288492482.56.0.17905191457.issue10259@psf.upfronthosting.co.za>


Ivan Razumov <iarspider at gmail.com> added the comment:

Typo: align -> Justify

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10259>
_______________________________________

From report at bugs.python.org  Sun Oct 31 04:01:46 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 31 Oct 2010 03:01:46 +0000
Subject: [issue10237] failure in Barrier tests
In-Reply-To: <1288391142.98.0.44997335021.issue10237@psf.upfronthosting.co.za>
Message-ID: <1288494106.65.0.854137280364.issue10237@psf.upfronthosting.co.za>


Kristj?n Valur J?nsson <kristjan at ccpgames.com> added the comment:

Silly me, changing the default timeout invalidated the unittest for it.
Fixed in revision 86018

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10237>
_______________________________________

From report at bugs.python.org  Sun Oct 31 04:45:09 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 03:45:09 +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: <1288496709.19.0.372730400569.issue10164@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Am discussing this with the OP on IRC and tabling it for a while so we can better think out the API.

The goal is to let assertEqual(a, b) do straight-comparions of raw bytes, but to give a nice looking diff (possibly translated with line breaks or somesuch) when the test fails.  This will be helpful in testing the email module. 

The current patch requires that assertBytesEqual be exposed and called directly so that a user can specify a split-at argument.  The purpose of that argument is to approximate the line breaking that occurs naturally in text.  The OP does not want to decode the bytes prior to the equality test, but does want a readable diff whenever the bytes represent ascii text.

----------
resolution:  -> later

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10164>
_______________________________________

From report at bugs.python.org  Sun Oct 31 04:50:02 2010
From: report at bugs.python.org (R. David Murray)
Date: Sun, 31 Oct 2010 03:50:02 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1288497002.71.0.70451209472.issue10254@psf.upfronthosting.co.za>


Changes by R. David Murray <rdmurray at bitdance.com>:


----------
nosy: +barry

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Sun Oct 31 05:19:25 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 04:19:25 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1288498765.74.0.378873612312.issue10160@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The patch looks fine.

You're overview of the process presented here in the tracker would make a nice comment in the code. 

If Antoine is happy with the latest patch, then it's ready to apply.

----------
assignee: rhettinger -> pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Sun Oct 31 05:46:49 2010
From: report at bugs.python.org (=?utf-8?q?Kristj=C3=A1n_Valur_J=C3=B3nsson?=)
Date: Sun, 31 Oct 2010 04:46:49 +0000
Subject: [issue10260] Add a thrading.Condition.wait_for() method
In-Reply-To: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>
Message-ID: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>


New submission from Kristj?n Valur J?nsson <kristjan at ccpgames.com>:

The attached patch adds a wait_for method to condition objects.
It can simplify code that uses condition variables since it relieves the user from writing a condition loop.  In addition it simplifies timeout logic which otherwise has to correctly deal with non-successful wakeups.

We also modify the barrier to use it, giving more robust timeout behaviour.

(btw, the use of time.time() in threading is unfortunate, since it has low resolution and is affected by a user adjusting the clock. On Windows one would want time.clock(), but that function measures CPU time on unix.  Do we need a proper time.wallclock() function available on all platforms?)

----------
components: Library (Lib)
files: wait_for.patch
keywords: patch
messages: 120036
nosy: georg.brandl, krisvale
priority: normal
severity: normal
status: open
title: Add a thrading.Condition.wait_for() method
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19442/wait_for.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10260>
_______________________________________

From report at bugs.python.org  Sun Oct 31 06:27:49 2010
From: report at bugs.python.org (Jacques Grove)
Date: Sun, 31 Oct 2010 05:27:49 +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: <1288502869.34.0.474946634924.issue2636@psf.upfronthosting.co.za>


Jacques Grove <jacques at tripitinc.com> added the comment:

Here's one that really falls in the category of "don't do that";  but I found this because I was limiting the system recursion level to somewhat less than the standard 1000 (for other reasons), and I had some shorter duplicate patterns in a big regex.  Here is the simplest case to make it blow up with the standard recursion settings:

$ cat test.py
import re, regex
regexp = '(abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ|abcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ)'
re.compile(regexp)
regex.compile(regexp)

$ python test.py
<snip big traceback except for last few lines>

File "/tmp/test/src/lib/_regex_core.py", line 2024, in optimise
    subpattern = subpattern.optimise(info)
  File "/tmp/test/src/lib/_regex_core.py", line 1552, in optimise
    branches = [_Branch(branches)]
RuntimeError: maximum recursion depth exceeded

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Oct 31 07:09:30 2010
From: report at bugs.python.org (Jacques Grove)
Date: Sun, 31 Oct 2010 06:09:30 +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: <1288505370.09.0.175977604485.issue2636@psf.upfronthosting.co.za>


Jacques Grove <jacques at tripitinc.com> added the comment:

And another, bit less pathological, testcase.  Sorry for the ugly testcase;  it was much worse before I boiled it down :-)

$ cat test.py 
import re, regex

text = "\nTest\nxyz\nxyz\nEnd"

regexp = '(\nTest(\n+.+?){0,2}?)?\n+End'
print re.findall(regexp, text)
print regex.findall(regexp, text)

$ python test.py
[('\nTest\nxyz\nxyz', '\nxyz')]
[('', '')]

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
_______________________________________

From report at bugs.python.org  Sun Oct 31 09:00:58 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 08:00:58 +0000
Subject: [issue5729] Allows tabs for indenting JSON output
In-Reply-To: <1239297330.19.0.24635332127.issue5729@psf.upfronthosting.co.za>
Message-ID: <1288512058.82.0.530993777813.issue5729@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Updated and applied in r86022.

----------
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue5729>
_______________________________________

From report at bugs.python.org  Sun Oct 31 09:02:05 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 08:02:05 +0000
Subject: [issue10260] Add a threading.Condition.wait_for() method
In-Reply-To: <1288500409.32.0.639501337625.issue10260@psf.upfronthosting.co.za>
Message-ID: <1288512125.85.0.0754285590453.issue10260@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
title: Add a thrading.Condition.wait_for() method -> Add a threading.Condition.wait_for() method

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10260>
_______________________________________

From report at bugs.python.org  Sun Oct 31 09:21:51 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 08:21:51 +0000
Subject: [issue9974] tokenizer.untokenize not invariant with line continuations
In-Reply-To: <1285695065.99.0.439423855227.issue9974@psf.upfronthosting.co.za>
Message-ID: <1288513311.77.0.0734382989224.issue9974@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

> My patch handles the described situation, albeit a bit poorly ...

Let us know when you've got a cleaned-up patch and have run the round-trip tests on a broad selection of files.

For your test case, don't feel compelled to use doctest.  It's okay to write a regular unittest and add that to the test suite.

----------
assignee: rhettinger -> 
priority: normal -> low

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9974>
_______________________________________

From report at bugs.python.org  Sun Oct 31 12:19:58 2010
From: report at bugs.python.org (Karsten Wolf)
Date: Sun, 31 Oct 2010 11:19:58 +0000
Subject: [issue10261] tarfile iterator without members caching
In-Reply-To: <1288523998.25.0.554801648749.issue10261@psf.upfronthosting.co.za>
Message-ID: <1288523998.25.0.554801648749.issue10261@psf.upfronthosting.co.za>


New submission from Karsten Wolf <karstenwo at web.de>:

It would be helpful to have a tarfile iterator that does not cache every archive member encountered.

This makes it nearly impossible to iterate over an archive with millions of files.

----------
components: Library (Lib)
messages: 120041
nosy: karstenw
priority: normal
severity: normal
status: open
title: tarfile iterator without members caching
type: feature request

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10261>
_______________________________________

From report at bugs.python.org  Sun Oct 31 12:34:41 2010
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 31 Oct 2010 11:34:41 +0000
Subject: [issue10261] tarfile iterator without members caching
In-Reply-To: <1288523998.25.0.554801648749.issue10261@psf.upfronthosting.co.za>
Message-ID: <1288524881.03.0.115188247883.issue10261@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

I assume you're using Python 2.x. because tarfile's memory footprint was significantly reduced in Python 3.0, see the patch in issue2058 and r62337. This patch was not backported to the 2.x branch back then. As the 2.x branch has been closed for new features, this is not going to happen in the future.

----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10261>
_______________________________________

From report at bugs.python.org  Sun Oct 31 12:58:46 2010
From: report at bugs.python.org (Karsten Wolf)
Date: Sun, 31 Oct 2010 11:58:46 +0000
Subject: [issue10261] tarfile iterator without members caching
In-Reply-To: <1288523998.25.0.554801648749.issue10261@psf.upfronthosting.co.za>
Message-ID: <1288526326.0.0.599745921491.issue10261@psf.upfronthosting.co.za>


Karsten Wolf <karstenwo at web.de> added the comment:

Yes, I'm on 2.6. I checked the Python 3.x tarfile just for this one line in TarFile.next():

self.members.append(tarinfo)

to conclude it would have the same problem.

Reducing 2.5gb memory usage as measured in my particular case by 60%, still leaves 1.5gb ram burned which is too much on a 32-bit 2gb ram machine.

My solution was to comment out that line which worked perfectly for my case but may not be the solution for the module.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10261>
_______________________________________

From report at bugs.python.org  Sun Oct 31 13:01:03 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 31 Oct 2010 12:01:03 +0000
Subject: [issue10254] unicodedata.normalize('NFC', s) regression
In-Reply-To: <1288453334.74.0.770473212932.issue10254@psf.upfronthosting.co.za>
Message-ID: <1288526463.27.0.782922958831.issue10254@psf.upfronthosting.co.za>


Changes by Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:


----------
nosy: +Arfrever

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10254>
_______________________________________

From report at bugs.python.org  Sun Oct 31 13:05:49 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 12:05:49 +0000
Subject: [issue10261] tarfile iterator without members caching
In-Reply-To: <1288523998.25.0.554801648749.issue10261@psf.upfronthosting.co.za>
Message-ID: <1288526749.54.0.450190489674.issue10261@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
type: feature request -> resource usage
versions: +Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10261>
_______________________________________

From report at bugs.python.org  Sun Oct 31 13:07:23 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 31 Oct 2010 12:07:23 +0000
Subject: [issue10262] Add --disable-abi-flags option to `configure`
In-Reply-To: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>
Message-ID: <1288526843.14.0.55690735161.issue10262@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

Some packagers might want to disable ABI flags. The attached patch adds --disable-abi-flags option to `configure`.

----------
components: Build
files: python-abi-flags.patch
keywords: patch
messages: 120044
nosy: Arfrever, barry
priority: normal
severity: normal
status: open
title: Add --disable-abi-flags option to `configure`
versions: Python 3.2
Added file: http://bugs.python.org/file19443/python-abi-flags.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10262>
_______________________________________

From report at bugs.python.org  Sun Oct 31 14:18:43 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 31 Oct 2010 13:18:43 +0000
Subject: [issue10263] "python -m site" does not print path details
In-Reply-To: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>
Message-ID: <1288531123.45.0.881083161674.issue10263@psf.upfronthosting.co.za>


New submission from Doug Hellmann <doug.hellmann at gmail.com>:

Running "python -m site" is supposed to print a report about the current import path and its components (like USER_BASE and USER_SITE).

This works under 2.6 and 3.1, but not 2.7.  No output is produced under 2.7 at all.  

When I add a print statement to the end of the module, I see that __name__ is set to "site" instead of "__main__", so the _script() function isn't being invoked at all.

----------
components: Library (Lib)
messages: 120045
nosy: doughellmann
priority: normal
severity: normal
status: open
title: "python -m site" does not print path details
versions: Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 14:56:59 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 13:56:59 +0000
Subject: [issue10258] Fix resource warnings in test_tokenize
In-Reply-To: <1288472516.9.0.895455205535.issue10258@psf.upfronthosting.co.za>
Message-ID: <1288533419.73.0.868487348183.issue10258@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

Fixing title.

----------
title: Fix resource warnings in distutil test_tokenize -> Fix resource warnings in test_tokenize

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10258>
_______________________________________

From report at bugs.python.org  Sun Oct 31 14:59:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 13:59:42 +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: <1288533582.94.0.369692082569.issue10263@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +eric.araujo, ncoghlan

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 15:09:54 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 14:09:54 +0000
Subject: [issue10264] Fix resource warnings in test_smtplib
In-Reply-To: <1288534194.29.0.658250394155.issue10264@psf.upfronthosting.co.za>
Message-ID: <1288534194.29.0.658250394155.issue10264@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Tests
files: test_smtplib_fd_leak.patch
keywords: patch
messages: 120047
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_smtplib
versions: Python 3.3
Added file: http://bugs.python.org/file19444/test_smtplib_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10264>
_______________________________________

From report at bugs.python.org  Sun Oct 31 15:12:07 2010
From: report at bugs.python.org (Mike Auty)
Date: Sun, 31 Oct 2010 14:12:07 +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: <1288534327.93.0.827169580443.issue9561@psf.upfronthosting.co.za>


Changes by Mike Auty <mike.auty at gmail.com>:


----------
nosy: +ikelos

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9561>
_______________________________________

From report at bugs.python.org  Sun Oct 31 15:53:33 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 31 Oct 2010 14:53:33 +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: <1288536813.45.0.535823522285.issue10263@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Since it works for me (I tried both r84120, my old 2.7 build from August or so, and r86033, which is the 2.7 head), we'll need more information. The starting blurb from the interactive prompt would be a good place to start.

(-m was slightly broken from April-June or so during 2.7 development, so custom builds in that window may exhibit occasional weirdness)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:03:33 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 15:03:33 +0000
Subject: [issue10265] Fix fd leak in sunau
In-Reply-To: <1288537413.19.0.268070514121.issue10265@psf.upfronthosting.co.za>
Message-ID: <1288537413.19.0.268070514121.issue10265@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

It's possible that this change will lead to fds leaking if someone is passing in a fd, however a) this is consistent with how other modules (e.g. uu) do it and b) of the 2 (!) uses of this module I found on Google Codesearch, both pass in filenames.

----------
components: Library (Lib)
messages: 120049
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix fd leak in sunau
versions: Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10265>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:04:28 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Sun, 31 Oct 2010 15:04:28 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288537468.57.0.712767274854.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

I've uploaded a new version of the patch to http://codereview.appspot.com/2724043/ now.

I'd be okay on doing maintenance directly against the CPython repository btw. :)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:07:20 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 31 Oct 2010 15:07:20 +0000
Subject: [issue10265] Fix fd leak in sunau
In-Reply-To: <1288537413.19.0.268070514121.issue10265@psf.upfronthosting.co.za>
Message-ID: <1288537640.33.0.468543723845.issue10265@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

Forget the attachment?

----------
nosy: +brian.curtin
type:  -> resource usage
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10265>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:10:55 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 31 Oct 2010 15:10:55 +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: <1288537855.25.0.867123242758.issue10263@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

I downloaded an OS X installer from python.org, but I don't remember the date I did that.

Here's the output when I start the interpreter:

$ which python
/Library/Frameworks/Python.framework/Versions/2.7/bin/python
$ python
Python 2.7 (r27:82508, Jul  3 2010, 21:12:11) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:15:16 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 31 Oct 2010 15:15: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: <1288538116.72.0.874687485494.issue10263@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Note also that site.py runs twice when used with -m: once implicitly during interpreter startup, and a second time as the main module. Due to the way the interpreter starts up and figures out sys.path, it is possible for the implicit import to pick up the correct version, but for the explicit invocation to find an old version.

With my site.py patched to include a "print __name__" line, I get the following:

$ ./python -m site
site
__main__
sys.path = [
  <details cut>
]
USER_BASE: <details cut> (exists)
USER_SITE: <details cut> (exists)
ENABLE_USER_SITE: True

The fact that you're only seeing one printout suggests to me that this is exactly the problem you're running into. The easiest way to confirm that is to run "python Lib/site.py" explicitly rather than via -m. That way you aren't relying on the second import working correctly (and I'm assuming you want to run this because you have doubts as to the correctness of the contents of your sys.path)

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:16:08 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 15:16:08 +0000
Subject: [issue10266] uu.decode fd leak if in_file is a filename
In-Reply-To: <1288538168.63.0.84193162166.issue10266@psf.upfronthosting.co.za>
Message-ID: <1288538168.63.0.84193162166.issue10266@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

I missed this when fixing issue 10246. The attached patch fixes this and adds a test that produces a resource warning with the old code.

----------
components: Library (Lib)
files: uu_decode_fd_leak.patch
keywords: patch
messages: 120054
nosy: bbrazil
priority: normal
severity: normal
status: open
title: uu.decode fd leak if in_file is a filename
versions: Python 3.3
Added file: http://bugs.python.org/file19445/uu_decode_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10266>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:16:25 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 31 Oct 2010 15:16:25 +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: <1288538185.0.0.326953411795.issue10263@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
nosy: +ronaldoussoren

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:18:22 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 31 Oct 2010 15:18:22 +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: <1288538302.76.0.696858366591.issue10263@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

Actually I'm trying to update the PyMOTW article about site, and I discovered that the output from the old examples that showed using --user-base and --user-site were no longer producing any output.  It looks like the build of 2.7 I downloaded is fairly old, so I'll try updating that.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:19:20 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 15:19:20 +0000
Subject: [issue10265] Fix fd leak in sunau
In-Reply-To: <1288537413.19.0.268070514121.issue10265@psf.upfronthosting.co.za>
Message-ID: <1288538360.93.0.536589285622.issue10265@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

That'd help alright.

----------
keywords: +patch
Added file: http://bugs.python.org/file19446/sunau_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10265>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:20:15 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 31 Oct 2010 15:20:15 +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: <1288538415.11.0.713503230027.issue10263@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

r82508 is the correct release binary (created after the error I mentioned above was fixed).

I've CC'ed Ronald to see if he can shed any light - it may be a platform specific issue with the way sys.path is calculated.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:24:55 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 31 Oct 2010 15:24:55 +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: <1288538695.48.0.663054234868.issue10263@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

Ah, I assumed that since the revision number was older there might be a newer build available now.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:27:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 15:27:42 +0000
Subject: [issue10160] operator.attrgetter slower than lambda after adding
	dotted names ability
In-Reply-To: <1287619821.22.0.706433716481.issue10160@psf.upfronthosting.co.za>
Message-ID: <1288538862.1.0.933849476471.issue10160@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

The PyUnicode_GET_SIZE issue was still there, but I've fixed it and committed in r86036. Thanks for your contribution!

----------
resolution:  -> fixed
stage: patch review -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10160>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:30:40 2010
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 31 Oct 2010 15:30:40 +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: <1288539040.85.0.989717570687.issue10263@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

No, there won't be another binary release until 2.7.1 comes out. The SVN revision number ratchets up pretty fast, since it is counting checkins on *all* branches, even experimental ones.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:36:11 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 15:36:11 +0000
Subject: [issue10265] Fix fd leak in sunau
In-Reply-To: <1288537413.19.0.268070514121.issue10265@psf.upfronthosting.co.za>
Message-ID: <1288539371.85.0.299921331134.issue10265@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

> It's possible that this change will lead to fds leaking if someone is
> passing in a fd

I don't think so, why do you say that?

That said, there's an indentation problem in your patch.

----------
nosy: +pitrou

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10265>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:37:14 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 15:37:14 +0000
Subject: [issue10264] Fix resource warnings in test_smtplib
In-Reply-To: <1288534194.29.0.658250394155.issue10264@psf.upfronthosting.co.za>
Message-ID: <1288539434.53.0.48898027351.issue10264@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +giampaolo.rodola, r.david.murray
stage:  -> patch review
type:  -> resource usage

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10264>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:38:51 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 15:38:51 +0000
Subject: [issue10266] uu.decode fd leak if in_file is a filename
In-Reply-To: <1288538168.63.0.84193162166.issue10266@psf.upfronthosting.co.za>
Message-ID: <1288539531.44.0.453719432264.issue10266@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Now that the previous patch has been committed, could you post a patch against current SVN?

----------
nosy: +pitrou
type:  -> resource usage
versions: +Python 3.2 -Python 3.3

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10266>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:55:52 2010
From: report at bugs.python.org (Neil Schemenauer)
Date: Sun, 31 Oct 2010 15:55:52 +0000
Subject: [issue10241] gc fixes for module m_copy attribute
In-Reply-To: <1288410530.83.0.095379048444.issue10241@psf.upfronthosting.co.za>
Message-ID: <1288540552.96.0.703409513032.issue10241@psf.upfronthosting.co.za>


Neil Schemenauer <nas-python at arctrix.com> added the comment:

Oops, my patch doesn't work since m_base can be shared by more than one module instance.  I guess a different solution would be to cleanup the m_copy references on interpreter shutdown.  Somehow they would have to be found though.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10241>
_______________________________________

From report at bugs.python.org  Sun Oct 31 16:59:06 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 15:59:06 +0000
Subject: [issue10266] uu.decode fd leak if in_file is a filename
In-Reply-To: <1288538168.63.0.84193162166.issue10266@psf.upfronthosting.co.za>
Message-ID: <1288540746.42.0.651436209477.issue10266@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

The patch is against current SVN.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10266>
_______________________________________

From report at bugs.python.org  Sun Oct 31 17:04:42 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 16:04:42 +0000
Subject: [issue10266] uu.decode fd leak if in_file is a filename
In-Reply-To: <1288538168.63.0.84193162166.issue10266@psf.upfronthosting.co.za>
Message-ID: <1288541082.96.0.949855529479.issue10266@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Oops, sorry. I hadn't seen that this was about a different function.
I've committed the patch in r86037.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10266>
_______________________________________

From report at bugs.python.org  Sun Oct 31 17:06:04 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 16:06:04 +0000
Subject: [issue10265] Fix fd leak in sunau
In-Reply-To: <1288537413.19.0.268070514121.issue10265@psf.upfronthosting.co.za>
Message-ID: <1288541164.04.0.162930376445.issue10265@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

Currently, if you pass in a fd it'll be closed by the __del__. My patch no longer does this so any use of the module depending on this behaviour could leak an fd. However, noone seems to use the module that way.

V2 attached.

----------
Added file: http://bugs.python.org/file19447/sunau_fd_leak_v2.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10265>
_______________________________________

From report at bugs.python.org  Sun Oct 31 17:25:06 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 16:25:06 +0000
Subject: [issue10267] test_ttk_guionly leaks many references
In-Reply-To: <1288542306.75.0.249495592657.issue10267@psf.upfronthosting.co.za>
Message-ID: <1288542306.75.0.249495592657.issue10267@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

This can be seen on all 3 branches:

$ ./python -m test.regrtest -uall -R 3:2 test_ttk_guionly
[306/349] test_ttk_guionly
beginning 5 repetitions
12345
.....
test_ttk_guionly leaked [590, 590] references, sum=1180

----------
components: Tkinter
messages: 120067
nosy: gpolo, pitrou
priority: high
severity: normal
status: open
title: test_ttk_guionly leaks many references
type: resource usage
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10267>
_______________________________________

From report at bugs.python.org  Sun Oct 31 17:28:58 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 16:28:58 +0000
Subject: [issue9685] tuples should remember their hash value
In-Reply-To: <1282764797.19.0.867524122951.issue9685@psf.upfronthosting.co.za>
Message-ID: <1288542538.88.0.504295492918.issue9685@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/issue9685>
_______________________________________

From report at bugs.python.org  Sun Oct 31 17:43:25 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 31 Oct 2010 16:43:25 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288543405.7.0.0144481310679.issue6715@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

After starting to review the code, I'm becoming skeptical whether this is the right approach. This does way to much action in C, and thus becomes complicated but also limited.

An alternative approach would be to just expose lzma_code to Python, and then integrate that into the io architecture, i.e. as a subclass of RawIOBase. I.e. LZMAFile would go; if you want to compress to a file, use FileIO instead, and wrap that with a LZMAIO (say). LZMACompressor and Decompressor could stay if desired, although it seems more liblzma-like to have a single object for both compression and decompression.

In addition, I find the options object too complicated. It seems to serve documentation purposes only, so I wonder whether it could be reduced in code size.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Oct 31 18:07:13 2010
From: report at bugs.python.org (Arfrever Frehtes Taifersar Arahesis)
Date: Sun, 31 Oct 2010 17:07:13 +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: <1288544831.28.0.692302384707.issue10268@psf.upfronthosting.co.za>


New submission from Arfrever Frehtes Taifersar Arahesis <Arfrever.FTA at GMail.Com>:

I would like to suggest introduction of --enable-loadable-sqlite-extensions option, so that packagers (and maybe other users) don't need to comment out 1 line in setup.py. I'm attaching the patch.

----------
components: Build
files: python-loadable-sqlite-extensions.patch
keywords: patch
messages: 120069
nosy: Arfrever, ghaering
priority: normal
severity: normal
status: open
title: Add --enable-loadable-sqlite-extensions option to `configure`
type: feature request
versions: Python 3.2
Added file: http://bugs.python.org/file19448/python-loadable-sqlite-extensions.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10268>
_______________________________________

From report at bugs.python.org  Sun Oct 31 18:14:01 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 Oct 2010 17:14:01 +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: <1288545241.84.0.256559697308.issue10268@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r86045

----------
nosy: +benjamin.peterson
resolution:  -> accepted
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10268>
_______________________________________

From report at bugs.python.org  Sun Oct 31 18:15:54 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 Oct 2010 17:15:54 +0000
Subject: [issue10264] Fix resource warnings in test_smtplib
In-Reply-To: <1288534194.29.0.658250394155.issue10264@psf.upfronthosting.co.za>
Message-ID: <1288545354.48.0.548298043449.issue10264@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r86046. Thanks

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10264>
_______________________________________

From report at bugs.python.org  Sun Oct 31 18:56:39 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 31 Oct 2010 17:56:39 +0000
Subject: [issue10246] uu.encode fd leak if arguments are filenames
In-Reply-To: <1288443880.97.0.48541703257.issue10246@psf.upfronthosting.co.za>
Message-ID: <AANLkTi=t-nbwuupMsi5r44qngXdEhan6kZcr2+nFsdtZ@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sat, Oct 30, 2010 at 06:04, Antoine Pitrou <report at bugs.python.org> wrote:
>
> Antoine Pitrou <pitrou at free.fr> added the comment:
>
> Committed in r85975 (3.2). I guess we'll do a big svnmerge to other branches later.

Or not at all. I honestly have not been worrying about backporting
since these are minor changes that are more stylistic cleanup than
fixes that have to get in. While it's good to be doing this for 3.2, I
don't view it as critical enough to worry about backporting (although
I have no issue if people do a backport).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10246>
_______________________________________

From report at bugs.python.org  Sun Oct 31 18:58:22 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 17:58:22 +0000
Subject: [issue10110] Queue doesn't recognize it is full after shrinking
	maxsize
In-Reply-To: <1287105905.32.0.568830983004.issue10110@psf.upfronthosting.co.za>
Message-ID: <1288547902.36.0.207140607885.issue10110@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Applied in r86049.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10110>
_______________________________________

From report at bugs.python.org  Sun Oct 31 19:02:10 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 18:02:10 +0000
Subject: [issue10246] uu.encode fd leak if arguments are filenames
In-Reply-To: <1288442639.64.0.225506910081.issue10246@psf.upfronthosting.co.za>
Message-ID: <1288548130.86.0.0667697832974.issue10246@psf.upfronthosting.co.za>


Brian Brazil <brian.brazil at gmail.com> added the comment:

The garbage collector should take care of the vast majority of these, it's only bugs in the C like issue 10253 that I'd worry about.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10246>
_______________________________________

From report at bugs.python.org  Sun Oct 31 19:05:47 2010
From: report at bugs.python.org (Brian Curtin)
Date: Sun, 31 Oct 2010 18:05:47 +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: <1288548347.34.0.0692538328523.issue9846@psf.upfronthosting.co.za>


Brian Curtin <curtin at acm.org> added the comment:

A fix to this would help silence a number of ResourceWarning messages coming out of the test suite.

----------
nosy: +brian.curtin

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9846>
_______________________________________

From report at bugs.python.org  Sun Oct 31 19:16:05 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 18:16:05 +0000
Subject: [issue10025] random.seed not initialized as advertised
In-Reply-To: <1286235186.65.0.07824350342.issue10025@psf.upfronthosting.co.za>
Message-ID: <1288548965.21.0.778916644035.issue10025@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Removed the inaccurate description.
See r86053.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10025>
_______________________________________

From report at bugs.python.org  Sun Oct 31 19:21:01 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 18:21:01 +0000
Subject: [issue10269] Fix some resource warnings in test_sax
In-Reply-To: <1288549261.81.0.692632435193.issue10269@psf.upfronthosting.co.za>
Message-ID: <1288549261.81.0.692632435193.issue10269@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Tests
files: test_sax_fd_leak.patch
keywords: patch
messages: 120077
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix some resource warnings in test_sax
versions: Python 3.3
Added file: http://bugs.python.org/file19449/test_sax_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10269>
_______________________________________

From report at bugs.python.org  Sun Oct 31 19:23:33 2010
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 31 Oct 2010 18:23:33 +0000
Subject: [issue10269] Fix some resource warnings in test_sax
In-Reply-To: <1288549261.81.0.692632435193.issue10269@psf.upfronthosting.co.za>
Message-ID: <1288549413.0.0.652416237736.issue10269@psf.upfronthosting.co.za>


Benjamin Peterson <benjamin at python.org> added the comment:

r86055

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10269>
_______________________________________

From report at bugs.python.org  Sun Oct 31 19:30:42 2010
From: report at bugs.python.org (Brian Brazil)
Date: Sun, 31 Oct 2010 18:30:42 +0000
Subject: [issue10270] Fix resource warnings in test_threading
In-Reply-To: <1288549842.1.0.819549161722.issue10270@psf.upfronthosting.co.za>
Message-ID: <1288549842.1.0.819549161722.issue10270@psf.upfronthosting.co.za>


New submission from Brian Brazil <brian.brazil at gmail.com>:

Please see attached.

----------
components: Tests
files: test_threading_fd_leak.patch
keywords: patch
messages: 120079
nosy: bbrazil
priority: normal
severity: normal
status: open
title: Fix resource warnings in test_threading
Added file: http://bugs.python.org/file19450/test_threading_fd_leak.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10270>
_______________________________________

From report at bugs.python.org  Sun Oct 31 19:53:35 2010
From: report at bugs.python.org (lekma)
Date: Sun, 31 Oct 2010 18:53:35 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>


New submission from lekma <lekmalek at gmail.com>:

Overriding warnings.showwarning() with a c/python module function (from a c/python module) doesn't work because warn_explicit() only allow PyFunction or PyMethod objects to be called (unfortunately c/python module functions are of type PyCFunction).

Suggested changes in _warnings.c (from py3k) - not tested at all:

from:
412            if (!PyMethod_Check(show_fxn) && !PyFunction_Check(show_fxn)) {
413                PyErr_SetString(PyExc_TypeError,
414                                "warnings.showwarning() must be set to a "
415                                "function or method");

to:
412            if (!PyCallable_Check(show_fxn)) {
413                PyErr_SetString(PyExc_TypeError,
414                                "warnings.showwarning() must be set to a "
415                                "callable");

----------
components: Library (Lib)
messages: 120080
nosy: lekma
priority: normal
severity: normal
status: open
title: warnings.showwarning should allow any callable object
type: feature request
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Sun Oct 31 20:03:15 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 31 Oct 2010 19:03:15 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1288551795.78.0.771254154577.issue10271@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Sun Oct 31 20:03:29 2010
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 31 Oct 2010 19:03:29 +0000
Subject: [issue10271] warnings.showwarning should allow any callable object
In-Reply-To: <1288551215.82.0.402250167562.issue10271@psf.upfronthosting.co.za>
Message-ID: <1288551809.02.0.673727746725.issue10271@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
versions:  -Python 2.6, Python 2.7, Python 3.1

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10271>
_______________________________________

From report at bugs.python.org  Sun Oct 31 20:34:32 2010
From: report at bugs.python.org (David Watson)
Date: Sun, 31 Oct 2010 19:34:32 +0000
Subject: [issue9377] socket,
	PEP 383: Mishandling of non-ASCII bytes in host/domain names
In-Reply-To: <4CCB1368.30608@egenix.com>
Message-ID: <20101031193421.GA4170@dbwatson.ukfsn.org>


David Watson <baikie at users.sourceforge.net> added the comment:

> FWIW, you can do the same on a Linux box, i.e. setup the host name
> and domain to some completely bogus values. And as David pointed out,
> without also updating the /etc/hosts on the Linux, you always get the
> resolver error with hostname -f I mentioned earlier on (which does
> a DNS lookup), so there's no real connection to the DNS system on
> Linux either.

Just to clarify here: there isn't anything special about
/etc/hosts; it's handled by a pluggable module which performs
hostname lookups in it alongside a similar module for the DNS.
glibc's Name Service Switch combines the views provided by the
various modules into a single byte-oriented namespace for
hostnames according to the settings in /etc/nssswitch.conf (this
namespace allows non-ASCII bytes, as the /etc/hosts examples
demonstrate).

http://www.kernel.org/doc/man-pages/online/pages/man5/nsswitch.conf.5.html
http://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html

It's an extensible system, so people can write their own modules
to handle whatever name services they have to deal with, and
configure hostname lookup to query them before, after or instead
of the DNS.  A hostname that is not resolvable in the DNS may be
resolvable in one of these.

----------
title: socket,	PEP 383: Mishandling of non-ASCII bytes in host/domain names -> socket, PEP 383: Mishandling of non-ASCII bytes in host/domain names

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9377>
_______________________________________

From report at bugs.python.org  Sun Oct 31 21:47:17 2010
From: report at bugs.python.org (Mathieu Bridon)
Date: Sun, 31 Oct 2010 20:47:17 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1288558037.17.0.50511878051.issue9584@psf.upfronthosting.co.za>


Mathieu Bridon <bochecha at fedoraproject.org> added the comment:

I finally found the time to follow up on this issue, sorry for the absence of response.

The thread on Python-Ideas didn't really lead to a consensus (nor did it generate a lot of discussion).

Some wanted to see this in fnmatch, others in glob and others in shutils. Most thought glob was the appropriate place though, and this is also my opinion.

>From the Python documentation, fnmatch is a ? Unix filename pattern matching ? while glob is a ? Unix style pathname pattern expansion ?.

This makes it clear to me that curly expansion has its place in glob, that would then use fnmatch to match the resulting list of expanded paths.

Here is a patch against the py3k branch.

The patch contains both the implementation, unit tests, and some changes to the documentation.

Note that could I only run the unit tests on Linux (Fedora 14 x86_64) which is the only system I have at hand.

----------
title: Allow curly braces in fnmatch -> Allow curly brace expansion
Added file: http://bugs.python.org/file19451/0001-Curly-brace-expansion-in-glob.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Sun Oct 31 21:47:39 2010
From: report at bugs.python.org (Mathieu Bridon)
Date: Sun, 31 Oct 2010 20:47:39 +0000
Subject: [issue9584] Allow curly brace expansion
In-Reply-To: <1281688613.27.0.00233773234268.issue9584@psf.upfronthosting.co.za>
Message-ID: <1288558059.01.0.575319616645.issue9584@psf.upfronthosting.co.za>


Changes by Mathieu Bridon <bochecha at fedoraproject.org>:


Removed file: http://bugs.python.org/file18497/curly-fnmatch.patch

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9584>
_______________________________________

From report at bugs.python.org  Sun Oct 31 21:47:56 2010
From: report at bugs.python.org (Ned Deily)
Date: Sun, 31 Oct 2010 20:47:56 +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: <1288558076.13.0.251432279277.issue10263@psf.upfronthosting.co.za>


Ned Deily <nad at acm.org> added the comment:

Unfortunately, the problem here is caused by having setuptools or Distribute installed. As released, both setuptools and Distribute install an easy-install.pth into site-packages to insert its "egg" into sys.path.  If you look inside the egg, you'll see it has its own site.py which gets executed first as a bootstrap to do sys.path manipulations after finding and importing the site module from the standard library.  So -m site actually runs the setuptools/distribute site module and not the expected standard library one.  To work as expected, the problem needs to be corrected in setuptools and Distribute so you may want to open issues with both projects if necessary.

BTW, I was unable to reproduce the problem with a current Debian Linux system with the Debian distribute package installed; it seems that the package there is patched to not install easy-install.pth.  I expect you would see the problem there if you installed either manually.

----------
nosy: +ned.deily
resolution:  -> invalid
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 21:57:34 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Sun, 31 Oct 2010 20:57:34 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288558654.91.0.332401754229.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

LZMAFile, LZMACompressor & LZMADecompressor are all inspired by and written to be as similar to bz2's for easier use & maintenance. I must admit that I haven't really put much thought into alternate ways to implement them beyond monkey see, monkey do.. ;)

LZMAOptions is a bit awkwardly written, but it doesn't serve documentation purposes only, it also exposes these values for max, min etc. to python (ie. as used by it's regression tests) and are also used when processing various compression options passed.

IMO it does serve a useful purpose, but certainly wouldn't hurt from being rewritten in some better way...

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Oct 31 22:15:30 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 21:15:30 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288559730.04.0.930767886252.issue6715@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I feel guilty of having said, some months ago, that "Well, I wouldn't say bz2module is the best module out there, but as you say it's probably good enough" (my words).

It's true that bz2module is not awful in terms of coding style or quality; the main issue with it is that uses outdated ways of doing I/O compared to what Python 3 recommends (that is, compose various building blocks together to allow for better re-use).

A point of reference is gzip, where the core compression routines (mostly wrappers) are in zlibmodule (in C), but the high-level file object is written in pure Python (and is composeable with other building blocks for fast buffered IO).

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Oct 31 22:24:27 2010
From: report at bugs.python.org (=?utf-8?q?Per_=C3=98yvind_Karlsen?=)
Date: Sun, 31 Oct 2010 21:24:27 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1250502444.31.0.107447392137.issue6715@psf.upfronthosting.co.za>
Message-ID: <1288560267.02.0.76925595899.issue6715@psf.upfronthosting.co.za>


Per ?yvind Karlsen <peroyvind at mandriva.org> added the comment:

Hehe, don't feel guily on my part at least, I had already implemented it like this long before. :p

I guess I could rewrite it following these suggestions, but I probably won't be able to finish it in time for 3.2 beta.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Oct 31 22:27:23 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 21:27:23 +0000
Subject: [issue10265] Fix fd leak in sunau
In-Reply-To: <1288537413.19.0.268070514121.issue10265@psf.upfronthosting.co.za>
Message-ID: <1288560443.26.0.729279128963.issue10265@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Committed in r86067. Thank you Brian!

----------
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10265>
_______________________________________

From report at bugs.python.org  Sun Oct 31 22:30:39 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 21:30:39 +0000
Subject: [issue7447] Sum() doc and behavior mismatch
In-Reply-To: <1260060640.85.0.12368990118.issue7447@psf.upfronthosting.co.za>
Message-ID: <1288560639.87.0.395198445231.issue7447@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r86066, r86068 and r86069.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7447>
_______________________________________

From report at bugs.python.org  Sun Oct 31 22:35:59 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 31 Oct 2010 21:35:59 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1288558654.91.0.332401754229.issue6715@psf.upfronthosting.co.za>
Message-ID: <4CCDE13B.4010807@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> LZMAFile, LZMACompressor & LZMADecompressor are all inspired by and
> written to be as similar to bz2's for easier use & maintenance. I
> must admit that I haven't really put much thought into alternate ways
> to implement them beyond monkey see, monkey do.. ;)

My concern really is with LZMAFile only. It uses stdio, and it really
shouldn't - we are trying to drop stdio in Python, as it's causing too
many problems. LZMACompressor/Decompressor may be fine.

> LZMAOptions is a bit awkwardly written, but it doesn't serve
> documentation purposes only, it also exposes these values for max,
> min etc. to python (ie. as used by it's regression tests) and are
> also used when processing various compression options passed.
> 
> IMO it does serve a useful purpose, but certainly wouldn't hurt from
> being rewritten in some better way...

If you are willing to do that, here is what I propose: rename the module
to _lzma, drop options and lzmafile from _lzma. Then write lzma.py,
which re-introduces this Options class in pure Python, as well as
reintroduces LZMAFile, wrapping io.FileIO. The various constants that
go into options should be exposed from _lzma using
PyModule_AddIntConstant (except perhaps for the ones that you define
yourself, such as LZMA_BEST_SPEED)

That assumes, of course, that there is a need to provide backwards
compatibility. I would personally be fine with *just* having the LZMA
symbolic constants exposed, leaving it to the user to determine which
constant serves which purpose (e.g. guessing what LZMA_DICT_SIZE_MIN
and LZMA_DICT_SIZE_MAX do when there is a dict_size keyword parameter
isn't too hard). But then, having the various options explained
in a consistent manner may be useful enough to preserve the Options
class.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Oct 31 22:43:53 2010
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 31 Oct 2010 21:43:53 +0000
Subject: [issue10272] SSL handshake timeouts not caught by transient_internet
In-Reply-To: <1288561433.38.0.641849376879.issue10272@psf.upfronthosting.co.za>
Message-ID: <1288561433.38.0.641849376879.issue10272@psf.upfronthosting.co.za>


New submission from Antoine Pitrou <pitrou at free.fr>:

The issue here is that ssl is using its own exception class rather than the socket module's "timeout" class:

test test_httplib failed -- Traceback (most recent call last):
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/test/test_httplib.py", line 408, in test_networked
    h.request('GET', '/')
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 943, in request
    self._send_request(method, url, body, headers)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 981, in _send_request
    self.endheaders(body)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 939, in endheaders
    self._send_output(message_body)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 791, in _send_output
    self.send(msg)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 737, in send
    self.connect()
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/http/client.py", line 1086, in connect
    server_hostname=server_hostname)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ssl.py", line 168, in wrap_socket
    _context=self)
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ssl.py", line 254, in __init__
    raise x
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ssl.py", line 250, in __init__
    self.do_handshake()
  File "/Users/pythonbuildbot/buildarea/3.x.hansen-osx-x86-2/build/Lib/ssl.py", line 429, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: _ssl.c:374: The handshake operation timed out

----------
components: Tests
messages: 120090
nosy: pitrou
priority: low
severity: normal
status: open
title: SSL handshake timeouts not caught by transient_internet
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10272>
_______________________________________

From report at bugs.python.org  Sun Oct 31 22:46:26 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 31 Oct 2010 21:46:26 +0000
Subject: [issue6715] xz compressor support
In-Reply-To: <1288560267.02.0.76925595899.issue6715@psf.upfronthosting.co.za>
Message-ID: <4CCDE3AF.90504@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I guess I could rewrite it following these suggestions, but I probably won't be able to 
> finish it in time for 3.2 beta.

The more I think about it, the more I feel like -1 about this code as
long as it uses stdio, and does buffering. We really don't need another
implementation of splitting a stream of bytes into lines.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6715>
_______________________________________

From report at bugs.python.org  Sun Oct 31 22:55:03 2010
From: report at bugs.python.org (=?utf-8?q?Martin_v=2E_L=C3=B6wis?=)
Date: Sun, 31 Oct 2010 21:55:03 +0000
Subject: [issue775964] fix test_grp failing when NIS entries present
Message-ID: <1288562103.71.0.543867771359.issue775964@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think this approach (of file19364) is reasonable.

----------
nosy: +loewis

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue775964>
_______________________________________

From report at bugs.python.org  Sun Oct 31 23:02:38 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 22:02:38 +0000
Subject: [issue7402] Improve reduce example in doanddont.rst
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1288562558.35.0.716518743799.issue7402@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed in r86070, r86071, and r86072.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7402>
_______________________________________

From report at bugs.python.org  Sun Oct 31 23:03:30 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 22:03:30 +0000
Subject: [issue7402] Improve reduce example in doanddont.rst
In-Reply-To: <1259318842.77.0.740725384087.issue7402@psf.upfronthosting.co.za>
Message-ID: <1288562610.8.0.172895209205.issue7402@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/issue7402>
_______________________________________

From report at bugs.python.org  Sun Oct 31 23:29:45 2010
From: report at bugs.python.org (Doug Hellmann)
Date: Sun, 31 Oct 2010 22:29:45 +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: <1288564185.49.0.261671571342.issue10263@psf.upfronthosting.co.za>


Doug Hellmann <doug.hellmann at gmail.com> added the comment:

That's strange.  I have Distribute 0.6.10, including an easy-install.pth file, installed under 2.6 and it doesn't exhibit the problem.  Is there some interaction between a change in Python 2.7 and Distribute?

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue10263>
_______________________________________

From report at bugs.python.org  Sun Oct 31 23:36:27 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 22:36:27 +0000
Subject: [issue9886] Make operator.itemgetter/attrgetter/methodcaller easier
	to discover
In-Reply-To: <1284725606.32.0.188356028787.issue9886@psf.upfronthosting.co.za>
Message-ID: <1288564587.02.0.316320913526.issue9886@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Fixed.  See r86073.

----------
resolution:  -> fixed
status: open -> closed

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9886>
_______________________________________

From report at bugs.python.org  Sun Oct 31 23:51:29 2010
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 31 Oct 2010 22:51:29 +0000
Subject: [issue9120] Reduce pickle size for an empty set
In-Reply-To: <1277839720.0.0.346517516652.issue9120@psf.upfronthosting.co.za>
Message-ID: <1288565489.9.0.26345352603.issue9120@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Have looked at this again and think I don't care what happens to it.  The gain is minimal but it doesn't take much extra core.  Like Fred, I'm not sure having another code path to test and maintain just to save 5 bytes.

Unassigning.  If anyone except the OP feels strongly either way, either close it or apply it.

----------
assignee: rhettinger -> 
type: feature request -> performance

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9120>
_______________________________________